Jump to content

Best way to encrypt a password


aeroswat

Recommended Posts

Basically what I've been reading into is that using md5 is not really a good idea anymore so I'm going to try to move away from that with my next project. What I'm thinking I want to do from what I've been reading is store an iterated encrypted string into the database. So my question is what would be my best option for a hash that would provide reasonable execution time and also what would you recommend as a way to create a random salt and figuring out how many times the encryption should be iterated.

Link to comment
Share on other sites

May I ask why you say md5 is a bad idea?

 

Maybe mix md5 and sha1? :P

 

From what I've been reading hashes like md5, sha1, etc were created for speed and not necessarily maximum security. It has been noted in the documents that I read also that md5 has been cracked numerous times in short periods of time.

 

EDIT: Will be back in an hour after lunch. I'll respond to any replies at that time. Thanks

Link to comment
Share on other sites

I have been wondering this myself I have some see use:

 

md5($password . 'chocolate') although I doubt this is really secure as the total length is lower then the MD5 output length and therefor more easy to crack? Personally I use sha1( sha1( $password ) . sha1( time() ) ) any advice?

Link to comment
Share on other sites

If you're concerned with speed, I would not recommend iterating.

 

MD5 is a weaker hashing algorithm, but that doesn't mean that all hashing algorithms are outdated.  You can try PHP's crypt function.  There are a few different adequate hashing algorithms therein.

http://us3.php.net/manual/en/function.crypt.php

 

Yes but I think that I should iterate at least a little bit. I don't think that the slow down would be that big. Any advice on what I should do for a salt? Should I store a salt, encrypt the salt, use the encrypted salt for my salt? I've been looking at the crypt function. Which of the algorithms would you recommend tho? I've heard some about blowfish but I'm thinking shouldn't the SHA512 be the best bet out of them? O_o

Link to comment
Share on other sites

sha1( sha1( $password ) . sha1( time() ) )

I'm confused.  How are you using the output of time() as a salt?  It always changes so you wouldn't be able to confirm a user later.

 

And my understanding is that using the output of one hash function as the input to another, such as md5( md5( ...  ) ), is bad practice.  The reasoning is because the inner md5() (or whatever hash you choose) has limited output, thus you are limiting the potential characters to be used in the final hash which makes dictionary attacks easier.

 

Do not confuse encryption with hashing.  The topic mentions encryption yet the OP is mentioning hashing functions.  If you want to perform hashing, then sha1( $value . $salt ) or sha256( $value . $salt ) is probably sufficient.  I wouldn't bother with encryption unless you're also encoding your PHP source code with ZendGuard, NuCoder, or another product.

Link to comment
Share on other sites

sha1( sha1( $password ) . sha1( time() ) )

I'm confused.  How are you using the output of time() as a salt?  It always changes so you wouldn't be able to confirm a user later.

 

This just serves as an example of course :) I would create the salt and store it in the database, afterwards when a user logs in I used the stored salt append it to the sha1 of his password and then sha1 the entire thing (sha1 of password and salt).

 

then sha1( $value . $salt ) or sha256( $value . $salt )

 

So the best would be to use: sha1('My91PaSsWoRD' . 'chocolate') instead of sha1(sha1('My91PaSsWoRD') . sha1('chocolate'))? I used the latter because I thought that because the input for the sha1 was more then 40 characters it would become extremely difficult to "decrypt" it.

Link to comment
Share on other sites

Nested calls to hash_func() defeat the purpose of a salt.  The entire purpose of a salt is to negate any existing dictionary database an attacker might possess.  Using hash_func( hash_func( $val . $salt ) ) will limit the size of the dictionary needed by an attacker.

 

Now your example uses hash_func( hash_func() . hash_func() ) which still limits the size of the necessary dictionary to brute force against your database.  I don't know how many attackers create dictionaries of concatenated hashes for source values so there's no way to really determine how secure your method is.

 

The one thing an attacker can not predict (and therefore can not create a dictionary to attack) is $salt in $hashed = hash_func( $value . $salt ).  That, from my understanding, is the most secure method of hashing.  There's no need to get extra fancy and nest calls, just create an appropriate salt.

 

Keep in mind though that if an attacker walks off with your source, or otherwise obtains your salt and how you apply it, they can build a dictionary to attack your database.

Link to comment
Share on other sites

Nested calls to hash_func() defeat the purpose of a salt.  The entire purpose of a salt is to negate any existing dictionary database an attacker might possess.  Using hash_func( hash_func( $val . $salt ) ) will limit the size of the dictionary needed by an attacker.

 

Now your example uses hash_func( hash_func() . hash_func() ) which still limits the size of the necessary dictionary to brute force against your database.  I don't know how many attackers create dictionaries of concatenated hashes for source values so there's no way to really determine how secure your method is.

 

The one thing an attacker can not predict (and therefore can not create a dictionary to attack) is $salt in $hashed = hash_func( $value . $salt ).  That, from my understanding, is the most secure method of hashing.  There's no need to get extra fancy and nest calls, just create an appropriate salt.

 

Keep in mind though that if an attacker walks off with your source, or otherwise obtains your salt and how you apply it, they can build a dictionary to attack your database.

 

Encryption from what I understand is used to mean the same thing as hashing. Encoding from the documents I have read is sometimes used interchangeably but means something else (i.e. it can be reversed)

 

Anywho I see what you mean on the salt being hashed as well. Since i'm pretty new to this im going on what I've been reading from the "experts". They don't recommend using a static salt but instead recommend using something that is variable. Using a time function to show when it was created would be perfect because then you could store it as something random in the table. Just call it date_created or something and then use it as a salt so if anyone did ever see ur database for some reason they would not be able to easily tell you were using the timestamp as a salt.

 

Now i haven't read about nesting hashes although from what I heard iterating the hashes is the best thing you could do. I took this to mean nesting. Perhaps it means nesting using different salts as well? Maybe someone could elaborate on this subject for me.

Link to comment
Share on other sites

Just to let anyone interested know here are two readings i found especially useful

 

http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

 

Until I find out how to get the SHA encryption algorithms to work on my machine/find a host that supports them I will have to just use the Md5 with a salt. I'm thinking that I will use a partial date stamp as my salt since this is probably the best way to go about things. Does anyone have a better solution? Md5 salts require 12 characters from what I'm reading and the first three have to be $1$ leaving only 9. The date stamps are 10 characters long if i use a - to seperate each value.

Link to comment
Share on other sites

I'll reiterate that hashing is not the same as encryption.  Both are used to protect data.  The difference is that with encryption you can recover the original value and with hashing you can not.  Once a value is hashed you will never, ever, not in a million years know what the original value was.

 

 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.