6 ms·

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, wi

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).

nerdy 11y ago
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.
sillysaurus3 11y ago
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.
- JosephRedfern 11y ago
  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
  - icebraining 11y ago
    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.
    - JosephRedfern 11y ago
      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).
  - deleted 11y ago
    [deleted]
  - CWuestefeld 11y ago
    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.
gmac 11y ago
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.
- paulmd 11y ago
  If you're using the passwords on multiple sites they're not unique. Not that users don't do it, but that's an invariant he stated.
  - ska 11y ago
    Which is (part of) what makes this an unrealistic assumption.
kitd 11y ago
They may only have 'access' via SQL injection. But now they have all the passwords in plaintext and can login as whoever they want.
ddlatham 11y ago
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.

nerdy 11y ago

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.

sillysaurus3 11y ago

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.

JosephRedfern 11y ago
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
- icebraining 11y ago
  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.
  - JosephRedfern 11y ago
    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).
- deleted 11y ago
  [deleted]
- CWuestefeld 11y ago
  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.

gmac 11y ago

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.

paulmd 11y ago
If you're using the passwords on multiple sites they're not unique. Not that users don't do it, but that's an invariant he stated.
- ska 11y ago
  Which is (part of) what makes this an unrealistic assumption.

kitd 11y ago

They may only have 'access' via SQL injection. But now they have all the passwords in plaintext and can login as whoever they want.

ddlatham 11y ago

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.