e: Downvoting questions is mean. FWIW I always use bcrypt.
This assumption is known to be false. We should not design systems around this assumption. If we do, popping a random startup will give up Gmail accounts, by the thousands to tens of thousands, and since we've settled on email accounts as The One Ring To Your Identity that imperils their brokerages, domain registrars, employers, World of Warcraft characters, physical safety, privacy, cat photos, etc.
(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).
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.
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.
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
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.
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).
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.
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.
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.
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
> 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.
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.
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.
Not that users don't do it, but that's an invariant he stated.
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.
Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the attacker gets the user database and nothing else.
Typical case, there may be differences depending on what the attacker is after, whether the dump is publicly released, etc.
Off the top of my head:
(1) Timing attacks against string comparison (in the hash cases, this usually also implies a guessable salt)
(2) Misconfigured servers showing exceptions/debug info to users, coupled with sensitive information in debug messages, coupled with a remotely triggerable exception
(3) Compromise only of the offsite backup site containing DB dumps but no access to the live DB
(4) Flaky drive is replaced without being physically destroyed. Dumpster diver gets drive working again briefly and gets partial/all DB contents at drive failure time.
(5) Someone else compromises the DB and posts a dump on the web.
Account read-write access opens up a lot more opportunities for fraud and abuse vs. account read-only access.
If I have enough processing power to brute-force compare them, I can eventually get the original password back, but that isn't a zero-cost effort in terms of time. As soon as you realise you have been breached, I would expect you would have initiated a lockdown of some kind, either preventing access to accounts until the owner can confirm identity, or forcing a password reset for all users.
If you store passwords in plaintext, I can copy the passwords, and impersonate users even while they continue using their accounts, unknown to them.
Edit: moreover, the GP has already mentioned that "[brute force] isn't a zero-cost effort in terms of time," even if you have access to humongous amounts of processing power. The point of encryption isn't to protect data forever; just long enough for them to become uninteresting.
Or, given a strong-enough original password. I postulate that, until the moment I posted it, '3BgZhZcGPcHswmfic79jgjsfqyMKW1Rh1rkFjagJC090V2tljd9Zy2vpYJw944HG' would never have been brute-forced, even with an extremely low work factor (in fact, it wouldn't have been brute-forced even without bcrypt, scrypt or PBKDF2: even were it just stored as a simple SHA2-512(pw) (i.e., baafbe64d25f27d4b7b2965f9abf43cf25acd8fc6021798a90253f33b3071e9 fd145eaccd555290913c8679fd4acf949f05243ac1089548abbab0e0ed77e63 31), no computer on earth, nor all the computers which ever have been or ever will be, would have brute-forced it (unless there's something we don't know about SHA2, or about computing).
Lesson? Always use high-quality random passwords. For a 128-bit security level, with upper- and lower-case letters & digits (62 characters, which means each character yields (log 62 2) = 5.9542 bits of entropy), you want a 22-character truly random password. 'xNl5gkbgXntyxi3oNO1dML' is a perfectly fine password (save for the fact that it's now public).
According to the NSA [1], 256-bit keys should be used to protect data up to TOP SECRET; that works out to 43 characters. Hence, 'TIdmzj1COc9ECwcilyQYVfLl5Dt8ti3UUlDVULrUrfx' is as secure an example password as could be.
(Yes, I'm assuming here that your password-generation algorithm is truly random. If not, do not pass Go; do not collect $200…)
I'm on Mac and found KeePassX to be a better solution than the original KeePass, it's much lighter weight. My only hope is that KeePassX gets browser integration at some point via keepasshttp - https://www.keepassx.org/dev/issues/91
(Though I've heard noises recently about KeePass's .kdbx file format having some known vulnerabilities. Anyone else heard this, or have more details?)
This doesn't seem like a particularly scary vulnerability, but one scenario that was brought up (though I'm not 100% convinced), is that a malicious actor can corrupt the password for one website, leading you to change the password.
I dunno, don't see it as a huge vulnerability, but I do agree there is little reason for such a database not to be authenticated.