Chris9902, can you please point where exactly this book says that “double hashing is a waste of time”?
According to one that I have - Appendix C.1 Storing passwords:
You should never store cleartext passwords in a database. Instead, store the hash of the password, and use a salt for best results:
<?php
/* $password contains the password. */
$salt = 'SHIFLETT';
$password_hash = md5($salt . md5($password . $salt));
/* Store password hash. */
?>
AlienDev, Ok I got the book, so which part are you referring to? I found on page 117 in chapter named “Secrets-Making and breaking a code” a subtitle - “What makes your password safe”, I read it, but all it said was what a hash function is, what properties should it have to be cryptographically secure hash function and latest developments (to the date of book publishing) of cryptanalysis of MD5 and SHA1. Nothing about double hashing at all.
It doesn’t. That was my comment.
The book (as you’ve already posted) shows you how to handle encryption. There’s no need to double hash if you use the method you posted (from the book). Using a salt and md5() or sha1() is plenty good. Double hashing only adds work for the CPU (so it’s a waste of time).
The method in book is:
$password_hash = md5($salt . md5($password . $salt));
Awfully like double hashing - applying md5 twice 
Or you were referring to the original md5(md5($password)) ?
I think he was refering to the original.
Multiple MD5ing without salts are, as I said, weaker. Why weaker? Because it allows for more collisions - The more collisions, the weaker the hash.
But if you run the password through a few bit-wise operations, you will find that even if they DID break it, they’d need to know what you did to it to get a password that’s not a load of garbage.
Arkinstall, while keeping your transformations secret is considered good thing, relying on them to be secret is not.
Kerckhoffs’ principle
Kerckhoffs’ Requirements
No, it is still the same for the given input. Otherwise, it would be pretty useless as you’d never be able to check the password against anything!
The key changes with each different input here, but you will still always get the same output for the same input. Therefore, rainbow tables can be generated just as easily.
Exactly - its a principle of cryptography that it should rely on the key being kept secret, not the algorithm / encryption process. Although with hashes this is slightly irrelevant because there isn’t really a key as such. In this case, its the length of time it would take to break passwords given a hash and the algorithm that is the key factor.
This is definitely rubbish. Using a salt has nothing to do with reducing collisions at all - you are just as likely to get a collision using a salt as without. The point of it is to ‘personalise’ the hashing function as such, so rainbow tables won’t exist for your particular hashing method, and would be a lengthy process to generate.
that’s not double hashing. There’s an extra layer there with the use of $salt.
so what’s the argument here? If you can’t keep your salt secret you’re toast? I think we all knew that.
Yep.
To be honest, if someone gets access to the passwords, you already have pretty bad problems.
I think more time should be spent on stopping people getting said passwords in the first place. After all, even with the salt - without the actual encrypted password they can’t do anything.
Of course, passwords should be encrypted - my encryption involves various operations on the user’s password and email address. To change their email, they enter their password - if it’s correct, it generates the new encrypted password.
But if anyone got access to the administration side, one of the last things I’d worry about is users’ passwords. Yeah, it’d be a problem but I think my main focus would be getting the site back into shape (after all, they wouldn’t just take passwords and run, they’d probably rip the site apart).
People often use the same weak passwords at many sites. They often have similar usernames as well, so if I get password for site A there is a chance that this password will be used somewhere else as well. If you use strong password then simple methods are sufficient, but in reality people use very weak passwords. The question weather this is their problem or not goes out of the scope of discussion - how to protect passwords.
The whole point of protecting passwords is that in an event of breach you do not have to worry about bad guys getting them. You are right that you need to stop people getting your password DB, but protecting from breach and ensuring that in event of breach minimum damage is done are two different things that can and must be done both.
because of this very problem you can have your system compromised because somebody on another system has crappy security and some of the user accounts on your “highly secure” system are the same.
somebody on another system has crappy security and some of the user accounts on your “highly secure” system are the same.
Therefore it doesn’t matter what encryption you use - they already have the password from the other server.
Yes, but in “highly secure system” I do not really care that single password for ordinary account is compromised because user disclosed it to third party. What I need to ensure is that by somehow obtaining password/session the attacker can not compromise other passwords/sesions and that audit trail remains.
Since every hacker would assume you used some hashing method to encrypt your passwords why not ‘go back to basics’? I simply apply a ROT13 to the password.
That would surely fool them, don’ t you think?
</sarcasm>
Not necessarily. If someone gains access to your salt, they still have to generate rainbow tables for that particular salt. One per user if you use user salts.
Another form of attack that is used is to take a common word that people might have as a password, hash it, and search for the user(s) that match the passwords, rather than trying to find a specific password for a user. Using a salt will prevent this kind of attack as well.
that’s what I meant. I assumed they would go through the hassle of creating rainbow tables for salt + hashed password.
Using single iteration creating rainbow table for dictionary with a given salt would require say 20 minutes, using 500 iterations for a given salt it would require 500 times longer -> 6 days 22 hours and 40 minutes.