Timeline for Set a hash, login with a password?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 18, 2017 at 14:17 | comment | added | TTT | @Thorbear - Wow did I muddy that up. Somehow I crossed the normal way of preventing reusing passwords with this answer. Sorry about that. It sounds like the server may generate the salt, but you're right, that still doesn't help unless it always uses the same salt (which isn't recommended). I must have had a senior moment. Or more like a senior day...thx for setting me straight. | |
| Feb 18, 2017 at 12:31 | comment | added | Gustavo Rodrigues | @Thorbear I understand what you're saying: the client fetch the "client salt" from the server and safety hash then password, the server take this hash then apply password hashing with the "server salt". If the client changes it's salt every time then the user can't login, as the first hash will change. If you're storing hashes to avoid reusing store the hashes and the salts, but then when changing the password the client will need to regenerate the new password using the previous client hashes, so it can be compared with the previous passwords, what can cause some problems. | |
| Feb 18, 2017 at 9:08 | comment | added | Thorbear |
@TTT Yes, but the whole premise here is that the client generated the hash and sent it to the server. The server doesn't have the plaintext for the previous passwords or the new password. If I am wrong, could you tell me if these two bcrypt hashes hide the same password? $2a$12$eKLFLeJECybwoJAuLBXIq.Y8e0YUidG0vf8LflD0fPNucbnAV7ftq $2a$12$Wm4jw10om87cbAkUZXWSCuPYorHk/wc72TmZ.RW.Fe9n3MJxGP7mq
|
|
| Feb 18, 2017 at 4:56 | comment | added | TTT | @Thorbear - each different salt is associated with its hash result. You simply iterate through each one to see if any of the password/salt combos yield that salt's hash. (pw+salt1=hash1? if no, pw+salt2=hash2?, etc...) Bcrypt for example has the unique salt built into the "hash". | |
| Feb 18, 2017 at 0:39 | comment | added | Thorbear | @TTT Unless the server specifies that the client must use the same salt for all passwords for that user, it cannot compare the hashes, even if it knows all the salts. Unless the salts for two hashes are identical, you cannot determine if the plaintext was identical, even if you know all the salts. | |
| Feb 17, 2017 at 16:56 | comment | added | TTT | @GustavoRodrigues - I agree with your first sentence. But, the client can't stop a user from tweaking the hash that gets sent to the server, but that doesn't help because then they could never login. | |
| Feb 17, 2017 at 16:55 | comment | added | TTT | @Thorbear - I agree with GustavoRodrigues' first sentence- you don't need to know the passwords; you simply compare the hashes. The server must know the individual salts for each password otherwise the user could never login. | |
| Feb 16, 2017 at 13:34 | comment | added | Thorbear | @GustavoRodrigues Any recommended password hashing algorithm will either take as input, or generate on its own, a random salt. The same password, using the same procedure, should produce different hashes. If the server doesn't have access to the plaintext at the point of registration, it can't compare the input to previous hashes (the server could still detect it the first time the user attempted to log in, but it is a bit late at that point). | |
| Feb 16, 2017 at 12:43 | comment | added | Gustavo Rodrigues | @Thorbear Why you can't just compare the client hashes? Are you assuming the client can change how it hashes its passwords? I don't think a client should allow that because then users will need to remember passwords and hashing settings. | |
| Feb 16, 2017 at 12:06 | comment | added | Thorbear | @IsmaelMiguel If the system requires passwords to periodically be changed (which is recently discouraged by NIST), then it has often been desirable to check that the newly entered password doesn't match any of your previous X passwords. If the initial hashing is done on the server, this is trivial to check, simply attempt to validate it against the previous hashes. If the initial hashing is done on the client, you can do no such thing. | |
| Feb 16, 2017 at 9:14 | comment | added | Ismael Miguel | Why would you even care about password re-use? How would you test it? How is it useful in any way to check for password re-use? If you're talking about password re-use by the client, then that may be useful | |
| Feb 16, 2017 at 0:37 | history | answered | John Wu | CC BY-SA 3.0 |