Good cryptographic hash functions [duplicate]

Question

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?

Truffle

What do you want? Encrypting or hashing? Also, md5 is a hash, not encryption. – Proscription

Check out stackoverflow.com/search?q=php+store+passwords, it's bound to have good information – Vetiver

Read this answer. Use sha256 or sha512, iterated, and be done with it... – Mauromaurois

I'm not sure about the difference between encryption and hashing, but the way you described it I guess hashing. – Truffle

@Snacker: The answer I linked above describes the difference in pretty good detail... – Mauromaurois

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.

Egan

The question mentions both hashing and a salt... – Textual

Sometimes it is necessary to store encrypted passwords in order to be able to log on to external systems. – Klapp

@Klapp In these cases, you should use a Single-Sign On solution. You don't store the password in plaintext to prevent attackers from logging in in case of compromised system data. Since the encryption key is part of the system's data, encrypting is generally pointless, unless key and data are in different security domains. – Egan

@Textual The question is about how to store passwords. Encryption is not the answer, as detailed in my prior comment. – Egan

@Egan what makes you think Tiger is in any way broken? – Aletaaletha

@Aletaaletha This paper includes a full collision for the 16-round reduced Tiger with complexity 2^47, and a pseudo-collision on the full 24-round Tiger with complexity 2^47 as well. This does not mean that Tiger is broken at the level of SHA-1 (where basically everybody can run a preimage attack), but I am not feeling comfortable with these safety margins. I'm open to the possibility that I'm misunderstanding something though. – Egan

very close, but not quite, read a bit closer, its a pseudo-collision for 23 rounds, not 24.. but discomforting indeed – Aletaaletha

@Aletaaletha In §4.7, the authors describe an attack against the full Tiger as well, but you are correct, the full pseudo-collision only works against the 23-round version. – Egan

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 :)

Harebell

Security through obscurity (which the padding method really is) is not security. It may make you feel better at night, but in the end it's not really making it any more secure. And when you couple that with the concept of when it is broken (and it will be, it only takes time), everybody's password would be easier to brute force due to the easier hash. And in most implementations, md5 is actually slower than either sha1 or sha256... So I don't know what you're trying to achieve (and you missed it by a long shot)... – Mauromaurois

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)

Ornamented

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.

Endo

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.

Klapp

DES is never an option in this day in age. It's better to implement Rijndael (AES) in PHP land, than to use DES which is VERY trivially broken... – Mauromaurois