Password encryption?

When you save passwords in a database, how much encryption should you use?

$rand = rand(0,9999);
$password = sha1((md5($password)+$rand),CRYPT);

Would something like this be enough encryption?

Ah yer that would be more then enough, in fact it would be too much. How are you going to work out what random number you added to the record?

I usally just go md5($password);

However I've started going sha1($password); and I figure thats enough its one way encryption so it should be hard enough.

I keep hearing people say bad things about using sha1 or md5 alone so I didn't know how far I should actually take it

You could store the random number in the database also .

Use SHA256/SHA2 instead of SHA128/SHA1. SHA1 has security flaws. MD5 is nothing that you should ever use, besides when doing checksums on files.

Originally Posted by echoSwe Use SHA256/SHA2 instead of SHA128/SHA1. SHA1 has security flaws. MD5 is nothing that you should ever use, besides when doing checksums on files.

hm everyone here says, you shouldn't use md5... but why? isn't it secure?

Originally Posted by noodles hm everyone here says, you shouldn't use md5... but why? isn't it secure?

As many above said, you can simply use a rainbow table to find the corresponding password to that specific hash.

MD5 is also such a quick algorithm that it borders on when you really have to use rainbow tables and when you can use a brute-force attack.
http://eprint.iacr.org/2006/105

However, as Phaaze said. You could use key strengthening.

I can't understand why you guys still argue about MD5. I don't usually deal with PHP; but just a quick search gave me this code snippet:
So I mean, what's so troublesome about that, that you can't use it? It's just a line of code and then you got your SHA-2 hash ready to go! Add a known salt to that, for example a large random number that you store in the column next to the password column and concatenate to the password before hashing it all. Then brute-force attacks can only be done on one password at a time, because all passwords use a different salt. This is what makes the time required to find the password increase so much that it becomes impractical to try, just using the hardware of today.

Although I'm wondering what quantum computing will turn out like and what it will do to the area of computer security.

Lastly, hashing != encryption, because it's irreversible. Encryption is stuff like blowfish and RSA.

there are many md5 library/ crackers now that you just add the hash and it will find wheat the word is. This generally only works with dictionary words.

I don't know what type of site you're seeking encryption for, but if you're merely trying to avoid storing raw passwords on your average site, using a standard method (such as md5 or sha1) along with salting it with an unknown and random (yet static) string should be more than sufficient. There are obviously numerous stronger methods than I mentioned, but they are also less efficient and thus unless needed, wouldn't exactly be practical.

I just stick with md5(md5($password)) It's pretty simple but can easily bypass most of those library's / crackers he was talkin' about...

If you have the registration timestamp in the database you can do md5(md5($password)+$reg_timestamp)

I've heard that you shouldn't hash a hash. It (supposedly) makes the hash have a greater chance of collisions (which is a bad thing).

So doing md5(md5($p)) is not the best way to do things.

Thats what I have been told, so I'm not to sure what to do.