I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway?
(edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already have access to the data that knowing the password behind the hash would provide).
If we assume every user is employing long, random, unique passwords ... then we surrender the ability to reason about the real world. Economists are fond of that kind of thing, but in IT security it's not terribly helpful.
Many (most?) users employ the same password on many different sites. So now an attacker has email/password pairs that work not just on the site that was compromised, but also on Gmail, Facebook, Twitter, Amazon, banking sites, and so on.
The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access.
Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, they won't be able to use any info within it to log in as anyone else unless they use brute force to reverse a hash.
EDIT: It's true that the attacker might have a copy of all the user's data. But unless they know someone's plaintext password, they can't log in as them. The attacker might have a copy of your tweets, but they won't be able to log in as you and send a new one.
There are only a few ways an attacker can snag a database. Most of the attacks let an attacker download it, but not modify it. For example, directory traversal lets you download ../../../../etc/passwd along with ../../path/to/database_backup.
Even if an attacker has shell access, it's unlikely they'd be able to use the service or change a user's password by manipulating the database directly. They might not be able to modify database for a number of reasons: the database might require credentials the attacker didn't get, or the attacker might only have access to a server containing database dumps rather than the database itself, or the attacker might be logging in as a user which has read-only access to the database file.
I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway?
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun
You can get a password hash from other sources besides a full DB dump. SQL injection, poorly generated tokens in URLs or cookies, etc.
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own account
Often it's easier to do an injection against a SELECT, just forcing it to read an extra field, particularly now with ORMs that won't pass straight SQL through.
Sure - in this specific case I was referring to "any attacker who snags the server's database" - I was taking snags the server's database to mean "has full DB dump", which perhaps was not sillysaurus3's intention.
I agree that if the only information you have is a users password hash then your options beyond attempting to brute-force the hash are limited (unless the system was vulnerable to a pass-the-hash attack, of course).
If an attacker somehow downloaded all my databases (because we keep data partitioned to minimize damage if one of them is compromised, as well as to better partition the application itself), then they would be able to see all of history.
But they wouldn't have the user's credit card, because that's encrypted separately with the key stored somewhere else.
And they wouldn't be able to take action on behalf of the user. That is, they couldn't place new orders as the user, or stuff like that.
It depends what you're after. If you see that someone is subscribed to Ashley Madison and what to blackmail him/her, then you have what you need. On the other hand, the password is the most important thing, because the majority of people use the same password everywhere; if you have the password from AM, maybe you have the one for GMail or for the bank account, where the real "juice" is at.
> if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway?
Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today.
> If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun
Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.
> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today.
I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shouldn't be a thing - it certainly should be). I'm saying that it's likely that if they can access the database that contains the user's account details, they're able to access other information that's held in the system anyway (that's what I meant by "game-over").
> Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.
I bet in a lot of cases (not all, would require open-signup etc), you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation.
Hopefully the important data is also not stored on the system in clear text and the key to decrypt it is stored on a different server only held in a secure area of memory while the process is working.
Password have value beyond one system they can be used to impersonate the user and often they are reused on other sites like email accounts (which can be used with reset password almost everywhere to gain access to those sites).
"you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation."
The hash should also have a salt included (which hopefully is also not stored on the same server as the database) so hashing is salt + password =hashingfunction> hash. The salt can also be a supplemented by a user specific info (unique account id) so that hashes for one user wont' work for another
Perhaps, but it would then depend on user privileges set in the database. If the application is accessing the DB as root or as a user with full admin privileges, then yes, I would say that would be a "game over" situation. On the other hand, if the DB user that is being used in the injection attack has read access to a limited set of tables, the damage may be much less severe.
> and swap out the hash of the privileged user.
True, if the initialization vectors of the hash are the same for admin and regular user accounts (for example, using the same salt for admin and normal users). You would also need write access to the DB via your injection attack.
This is, I think, actually a very reasonable argument. The threat model which compels us to use specific strong techniques to hash passwords is very much a last line of defense: If an adversary has got hold of a copy of our database, and the user has chosen a relatively weak password that's vulnerable to rainbow tables, and they have reused that password on their banking service, then the fact that their password is bcrypted rather than MD5'd might prevent their bank account getting hacked. Bcrypting all your users' passwords is a just-in-case-the-worst-happens measure, like issuing a cyanide capsule to a spy - "Alright, you've captured me, but you'll never get any information out of me!"
But it should be clear that a lot of other stuff has to have gone wrong before it comes to that, and - more importantly, why are we all of a sudden so concerned about whether the user's bank account will get hacked? That's the user's problem, not ours, right? If someone's stolen our entire database, things have already got as bad as they can for us - if they're also bad for our users, why do we particularly care?
Fundamentally, if a user has elected to give us their bank password, why is it on us to protect it with military-grade crypto, when clearly the user doesn't think it's sufficiently valuable that they kept it secret? And why should we act as if every password someone chooses to use might be a shared credential?
It seems you're expected to assume that it's your duty to protect customers against any loss they may incur on a third party site because they reused a password, if that password is revealed by someone hacking your database.
But total DB compromise isn't actually the only place in your threat model where you should be worrying about who can figure out a user's password. One very good reason for strongly hashing passwords is to make it very clear that your employees who have legitimate access to the database can not themselves discover users' passwords. This helps maintain the trail of accountability that lets you demonstrate that actions taken by a specific user who logged in with their password were actually taken by that user.
In that sense, the real reason for using strong crypto on user-chosen passwords is because they are secrets which belong to the user and which nobody else should be able to find out about. As such we take extraordinary measures to ensure that that secret is kept. That way it doesn't matter if their secret is that they use a weak, nonunique password. Indeed, how could you even know?
In the Ashley Madison case, of course, it turns out that there are a lot of other secrets that a database can be holding on behalf of a user that should not ever be accessible to anyone else.... but nobody's complaining that the activity history of accounts wasn't encrypted to protect customers against loss after a total data breach.
They would have read access to all of the database. However, if they also have the password, then they have they ability to impersonate that user and take actions as well.
As an example, if you're a bank, if someone gets your database of data, but the passwords are well protected, they can find out how much money you have in your account. If they get your password, too, then they can login as you and transfer your money to their offshore account.
They may not necessarily have compromised the entire system.
Consider for example, SQL injection. Alternatively, some kind of DB dump mistakenly exposed in the webroot. Neither should happen but they're real-world examples. Sometimes misconfiguration leaves you in a weird state.
