@Dragnslcr said in Compromising MD5/SHA1 hashed passwords:
@Groaner said in Compromising MD5/SHA1 hashed passwords:
Having a copy of the database gives you read access to a user's data. Having the password gives you write access to a user's data.
Addressed above with the fact that many companies use
sa as the app database login.
I don't follow. If the server side of the application uses a superuser login to the database, how does that provide access to someone out on the Internet? The database server shouldn't even be reachable to anyone outside the local network.
Exactly. At this point, we're assuming that several layers of the defense have already been breached.
The most plausible vector I can think of in which all those layers are simultaneously breached and the attacker has access to a large chunk of the data is a SQL injection vulnerability, or some other exploit. Being able to run ad hoc queries at will mean it's only a matter of time before an attacker can figure out enough about your schema to glean all the useful information from it. I've worked on systems that store unencrypted full addresses and SSNs. Who cares about passwords when that kind of info is readily available in the same database?
Other vectors (like a DB backup being uploaded somewhere it shouldn't) can be mitigated by other means. I've only started playing with encryption in SQL Server, but one can make it difficult to restore a database or read encrypted columns without having the server's master key.
Is there something I'm missing?