Article on hashing passwords: viewtopic.php?t=62782
HMAC vs. basic hash: There are some attacks against some families of hash functions, among which are md5 and sha*. HMAC protects agains them. They mostly concern appending data to an unkonwn signed message and producing a valid HMAC of the new message, which is not relevant to the application of securing passwords. Nevertheless, when working with security primitives, it is always better to stick to old and proven ones, such as HMAC. For that reason, I recommend using it.
multiple hashings: This is called strengthening and is a valid method. It does not provide much better security on its own without salting, so you can consider using it on top of proper salting.
What is a good length for a salt?: As long as you can "afford" in your environment. The purpose of salting is to increase the entropy of weak passwords, so instead of "qwerty" you'd have "qwertyn230nm,GFM@#$()". A good rule of thumb is to use a salt of lenght and complexity as a "good" password according to your security needs. So 256 chars of salt is possible, but overkill, 4 chars is clearly too little, anything between 8 and 16 depending on the charset is okay.
Brute force attacks against stolen passwords: Yes, a "full" BF is generally a hard thing to do, but you can do some clever attacks nevertheless. Salting and strengthening will help protect against mass recovery of passwords. Salting and peppering (described in the article I linked to) may severely diminish the chances of success for the attacker.
Password Hashing
Moderator: General Moderators
Re: Password Hashing
I still kinda miss the point of HMAC'ing, I'd like to copy a question which I posed earlier to another guy:Mordred wrote:HMAC vs. basic hash: There are some attacks against some families of hash functions, among which are md5 and sha*. HMAC protects agains them. They mostly concern appending data to an unkonwn signed message and producing a valid HMAC of the new message, which is not relevant to the application of securing passwords. Nevertheless, when working with security primitives, it is always better to stick to old and proven ones, such as HMAC. For that reason, I recommend using it.
hash_hmac does essentially this:
Code: Select all
hash('sha512',$salt1.hash('sha512',$salt2.$user_salt.$password))I don't think this is more secure than what you (=the original TS) were doing:
Code: Select all
hash('sha512',$user_salt.$password.$sitesalt);(all this of course assuming that $sitesalt and $user_salt are both sufficiently long & complex, let's say 20 random chars including non-alphanumerics)
I don't see how any possible future sha512 vulnerabilities (currently there are none known) could affect the 2nd more than the 1st? On the other hand, the 1st (HMAC) has higher collission probability than the 2nd (regular single hash)..
Re: Password Hashing
The effect on the collision probability over a couple of hashing iterations is negligible.
Moreover, the exact collision-resistance properties of the hash functions are in general not "interesting" in the application of hashing a password. All practical bruteforce attacks would require dictionaries or at least printable subsets of passwords, while it would be extra rare to find collisions where both preimages are printable.
About hmac, as I already said, the attack which HMAC protects against ...
1. Always good practice to use solid proven primitives instead of inventing your own
2. I might be wrong, and there might be even more attacks against your hashing scheme, that HMAC would protect against. Which is actually saying again point 1 in different wording.
Use HMAC.
Moreover, the exact collision-resistance properties of the hash functions are in general not "interesting" in the application of hashing a password. All practical bruteforce attacks would require dictionaries or at least printable subsets of passwords, while it would be extra rare to find collisions where both preimages are printable.
About hmac, as I already said, the attack which HMAC protects against ...
That said, it isMordred wrote:...is not relevant to the application of securing passwords
1. Always good practice to use solid proven primitives instead of inventing your own
2. I might be wrong, and there might be even more attacks against your hashing scheme, that HMAC would protect against. Which is actually saying again point 1 in different wording.
Use HMAC.