9 ms·
No it doesn't. In your example, the hash of the password becomes the new password (I.e. the new secret). The nonce/salt adds no security because it must be open
by itcrowd 7y ago
No it doesn't. In your example, the hash of the password becomes the new password (I.e. the new secret). The nonce/salt adds no security because it must be open to anyone attempting to authenticate.
- mnem 7y agoSurely it adds security in that an attacker cannot take that new password and use it on another site, even if the user re-used the underlying password?
- itcrowd 7y agoYes. It adds this feature. But only if you assume that the database was compromised or nefarious logging was enabled and no further access to the server was possible. Otherwise, the attacker can modify the JavaScript that is used by the client to perform the hashing (and remove/adjust the hashing function). To be clear, it would have prevented these logged passwords from impacting other websites if the true cause of the Robin Hood password reset was a logging issue. As a user, you can prevent this from happening either way by choosing strong, unique passwords for every service.
- naniwaduni 7y agoThis is still a meaningful improvement because accidentally making everything world-readable is in many cases easier than accidentally making everything world-writable.
- mnem 7y agoIt’s not assuming that has happened, it’s acknowledging it could happen (or any other bug that reveals database field, e.g. sql injection). It seems like it should just be a default practice - generally I try to design systems to fail safe, regardless of what causes that failure.