Good cryptographic hash functions [duplicate]

Question

This question already has answers here:

Closed 9 years ago.

Possible Duplicate:
Secure hash and salt for PHP passwords

I am making a website, and I need a secure algorithm to store passwords. I was first thinking of bcrypt, but then I found out my host did not support it and I am not able to change host.

My host allow this encryption:

• Standard DES

And these hashes:

• MD5
• md2, md4 & md5
• sha1, sha256, sha384 & sha512
• ripemd128, ripemd160, ripemd256 and ripemd360
• whirlpool
• tiger128,3, tiger160,3, tiger192,3, tiger128,4, tiger160,4 & tiger192,4
• snefru
• gost
• adler32
• crc32 & crc32b
• haval128,3, haval160,3, haval192,3, haval224,3, haval256,3, haval128,4, haval160,4, haval192,4, haval224,3, haval256,4, haval128,5, haval160,5, haval192,5, haval224,5 & haval256,5

So, can anyone of you fix a good algorithm with that and a salt, please?

Answer 1

You shouldn't store encrypted (or even unencryped) passwords at all. Instead, use salted hashes (stretched, e.g. with PBKDF2), preferably SHA2-512.

For reference, here is a classification of the listed hashes (See wikipedia for details):

Encryption (not a hash function): DES
Non-cryptographic checksums (laughable): adler32, crc32, crc32b
Broken: MD2, MD4, MD5,SHA1
Probably broken: Tiger, snefru, GOST, HAVAL*
Probably safe: SHA2-256/384/512, RIPEMD-128/256, RIPEMD-160/320, WHIRLPOOL

Note that the strength refers to the attack of finding any password that matches a known hash (preimage attack). Also, the above sorting is paranoid, instantly discarding any hash with any known vulnerabilities.

Answer 2

crc32, adler32 etc. are not designed to be cryptographically secure -- they're merely fast checksum algorithms. I think salted SHA-256 should offer a good combination of security and compatibility.

On a somewhat less serious note, I once recall using salted MD5 on a slow server that was expected to tank moderate load. So I decided to pad it with a 32-bit random salt, and stored the whole thing as hexadecimal -- it gave off the impression the whole thing was unsalted SHA-1. I sincerely hope someone wasted precious time running rainbow tables on the stolen dump!

Security isn't really all about more expensive hashing :)

Answer 3

You should

• Use a salt as part of your hash.
• Use an iterative routine in the 10,000+ iteration range. For example, PBKDF#2.
• Use a known strong hash (SHA-256, SHA-512)

Answer 4

You should store passwords as hashes as mentioned above, not encrypted.

A hash function is basically a one way transformation which always produces the same hash for the same input argument. It should not be possible to transform the hash back to its original form, or the hash function is to be considered broken.

An encryption is a two way transformation where you can transform the encrypted data back into its original form if you have the key.

By storing passwords as hashes, and as they are one way transformed, they can not be extracted even if someone were to get hold of the database.

When checking a password simply transform it with the same hash function you used on your stored password and check against the database.

Answer 5

As gnur said, you need to decide if you want to hash or encrypt passwords. If these are passwords for your own users and the passwords are only being used on your system, then hash them using salt and stretching. Of the hash algorithms you have available use SHA-256 or SHA-512. For salt use 128 random bits (16 bytes). Ideally use a cryptographic RNG though a non-crypto RNG will do in a pinch. The attacker is assumed to know the salts anyway. Stretch enough that it takes about 0.1 second to process a single password. This limits any attacker to ten attempts at breaking a password every second.

If you are storing passwords to log on to an external system then you will need to encrypt the passwords and decrypt them when needed. DES is your only real option here, unless you also have 3DES (aka Triple DES or DESede) available. I am surprised that AES/Rijndael is not available. If it is then us it in preference to DES.