Timeline for Why is password hashing considered so important?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Aug 31, 2013 at 20:09 | comment | added | Anorov | One thing to add is that a "partial, read-only" break can turn into a "full" break or even a "root access" break if the attacker is able to obtain the password of a user with administrator privileges. If the admin re-uses that password anywhere, they could potentially gain SSH or FTP access, and even if they don't, there's a decent chance that somewhere in the web application's interface is a way for them to augment their foothold (shell upload, LFI, etc.). Making it difficult for them to determine admin passwords mitigates this greatly. | |
| Aug 29, 2013 at 19:13 | comment | added | Tom Leek | What I mean is that if the server uses a key to verify stored MAC values on user passwords, and that key is in a dedicated hardware (a HSM, a smart card) which uses the key but never reveals it, then the attacker who gets a complete copy of the disk still does not have the key, and won't be able to run an offline dictionary attack. Such hardware is also tamper-resistant, but I agree that in this specific case the tamper resistance is irrelevant. | |
| Aug 29, 2013 at 18:56 | comment | added | user | I'd actually take slight exception to the last point. I see what you mean, but anything the server process can do, in principle any software can do; it's mostly a matter of how much money and manpower the attacker wants to throw at the problem. Tamper-resistant hardware can go a long way to mitigate many threats, but it won't eliminate them completely. (That said, I did give you +1 for this.) | |
| Aug 29, 2013 at 13:37 | history | answered | Tom Leek | CC BY-SA 3.0 |