The purpose of password hashing is to preserve security even when a hacker gets access to your data. Saying you store the really long numbers “outside the database” is cheating. The numbers must be accessible to the server. If a hacker compromises the server then they have access to both the hashed passwords and the really long numbers. You basically just said “hide the salt”. If you can hide the salt then you can hide the passwords themselves and there is no need to hash them in the first place.
If the hacker has access to your really long numbers then your proposed system is on average equivalent to a 50× slower hashing algorithm. But a 50× slower hashing algorithm is superior because it has constant time performance whereas yours fluctuates randomly between 100× slowdown to no slowdown.
Edit: Actually, the slower hashing algorithm is even better because it can’t be parallelized.
Edit: Actually, the slower hashing algorithm is even better because it can’t be parallelized.
That’s true when you’re checking one password, but a slower hashing algorithm doesn’t stop you from checking multiple passwords at once (which is something you do when cracking passwords but not when authenticating them). Still, it’s something I haven’t thought about, so thanks for pointing that out.
Yes, password security is supposed to provide security even when a hacker gets access to all your data, but it doesn’t mean secrecy is completely disregarded, after all no one makes their password hashes database public, and leaks are still a security breach even if the passwords were hashed and salted correctly. So storing it in a harder to compromise place (outside the database, outside the hard drive, outside the computer, whatever) is only “cheating” if you completely rely on it and assume it would work. Which I didn’t. My problem with the first method is exactly that, that it’s useless if the secret stops being secret.
But, if you really want you can still store them in the database, The important point is that you don’t store which peppers are used for which users, which you still do for salts even if you try to hide them somehow.
The hacker does get slowed down almost 100X with a 100 peppers when cracking passwords, since to reject a password they have to try all the peppers, and most likely they have to try a very large number of passwords before finding the right one. On authentication it does take on average half the time, since you usually check correct passwords.
The purpose of password hashing is to preserve security even when a hacker gets access to your data. Saying you store the really long numbers “outside the database” is cheating. The numbers must be accessible to the server. If a hacker compromises the server then they have access to both the hashed passwords and the really long numbers. You basically just said “hide the salt”. If you can hide the salt then you can hide the passwords themselves and there is no need to hash them in the first place.
If the hacker has access to your really long numbers then your proposed system is on average equivalent to a 50× slower hashing algorithm. But a 50× slower hashing algorithm is superior because it has constant time performance whereas yours fluctuates randomly between 100× slowdown to no slowdown.
Edit: Actually, the slower hashing algorithm is even better because it can’t be parallelized.
That’s true when you’re checking one password, but a slower hashing algorithm doesn’t stop you from checking multiple passwords at once (which is something you do when cracking passwords but not when authenticating them). Still, it’s something I haven’t thought about, so thanks for pointing that out.
Yes, password security is supposed to provide security even when a hacker gets access to all your data, but it doesn’t mean secrecy is completely disregarded, after all no one makes their password hashes database public, and leaks are still a security breach even if the passwords were hashed and salted correctly. So storing it in a harder to compromise place (outside the database, outside the hard drive, outside the computer, whatever) is only “cheating” if you completely rely on it and assume it would work. Which I didn’t. My problem with the first method is exactly that, that it’s useless if the secret stops being secret.
But, if you really want you can still store them in the database, The important point is that you don’t store which peppers are used for which users, which you still do for salts even if you try to hide them somehow.
The hacker does get slowed down almost 100X with a 100 peppers when cracking passwords, since to reject a password they have to try all the peppers, and most likely they have to try a very large number of passwords before finding the right one. On authentication it does take on average half the time, since you usually check correct passwords.