What is the risk of an attacker inserting new password hashes?

Question

The normal threat model that I see with password hashing is as a kind of defense against if the hash somehow leaks to the wider world. In practice, this appears to usually be via some manner of database breach that ends up with (at least) the user table being dumped out. Given that this has happened or can happen, what are the chances that the attacker is also able to put new values into the database?

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record.

Basically, is this a realistic threat to be guarded against or just my thoughts spinning into security paranoia?

Answer 1

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record."

So, the attacker's own password thing is unlikely. There are technical defences that could stop it, such as deterministic "salt" (instead of hashing just the password, hash something like the username and password together) However, the bigger reason that isn't likely is that it leaves a big red arrow pointing towards the attacker's identity!

Unfortunately, that doesn't mean that the adding a known hash thing is unlikely. You are correct that it is possible. It is something many young developers do by hand when home rolling an authentication system and not yet having the password reset form working. It is also fundamentally how password reset forms work: just overwrite the hash you don't know with one you do.

Essentially, if an attacker has write access to the users table, hashing does not protect it. You might get a small level of defence if you include "pepper" in the hash (which is just a secret value stored away from the database) but with this level of access there is just unavoidably a lot of scope for harm. Other options for attack include changing the type of a user to a privileged one, or messing with the table to prevent real users from logging in, in a DOS attack. Pepper in the hash doesn't help against those.

The take home is yes, hash passwords because it prevents a specific sort of harm (namely password harvesting) but that should not be the only area of security. You also need best practices such as separation of privilege to avoid an attacker having write access to a database to begin with.

Answer 2

1. "What is the risk" - only you can answer what is the risk. Nobody else knows your system, nobody else can evaluate what is your risk.

2. "having the application decrypt secrets" - This cannot happen. Well, it can, if you do everything wrong. But nobody uses authentication password for anything else like for encryption of data on the server. Authentication password can be forgotten or expire regularly and user gets new password. But this has nothing to do with data encryption on server (of course some naive developers do that, but we are talking about a bit more professional developers). When encryption of some user data is needed on per user base, one of approaches is that user generates a key (or even a key file, e.g. 1K of random bytes), which is used to encrypt user data on server. Then overriding users password does not mean access to the encrypted data.

3. Overridden password allows access to applications functionality. The consequences depend on you application. If your application provides access to weather forecast, there will be not much harm if an attacker gets access to the application :) But if your application allows to pay anything, allows to sign contracts for big amounts of money, then the consequences can be very harmful.

What can you do? First, think what can be the consequences, how much harm such attack can cost you, then estimate the probability, then compare it to the costs of mitigation. May be mitigation makes no sense. Second, if you decide for mitigation, consider 2-factor authentication.

Answer 3

You need a threat model in order to assess risk. You don't have one.

Yes, an attacker could insert new password hashes into a stolen copy of the database. That is relatively easy to do. In fact, you can assume any attacker who bothers to steal a database is capable of mounting, reading, and modifying that database in its entirety.

But what is the harm associated with replacing password hashes on his copy of the database? This will not allow him to do anything useful. Exception: If the database has used some horribly flawed home-brew encryption, then he may be able to retrieve encrypted records from the database. Don't roll your own security unless you have a team of full-time experts.

Once the database is stolen, you will never load it back onto your production systems. If he has replaced the password hash on an account in his copy, it doesn't change anything on your instance. He cannot log into your users' accounts that way.

Lacking a clear path to a negative outcome...

A threat model would include a technical method by which an attacker could harm you, and then you can assess the impact and likelihood of that harm occurring. Unless you can describe how the proposed action leads to any harm, there is no risk to assess.

Provided that your database did not employ custom, low-quality "security" and your production database is not restored from a leaked copy, I don't see how additional harm is possible.

To be clear, there is potential harm under normal circumstances, just not from the actions you describe.

The most likely threat is rainbow tables and/or cracking.

With possession of the database, he could attempt to recover passwords for your users. However, this requires the attacker to retain the original hashes. This is the real threat associated with stolen authentication data.

The correct response to this threat is two-fold: force a password reset for your entire userbase using your standard challenge mechanism, and warn your users to change their password on any other sites if they used the same password.

If you used salts when hashing, a rainbow table will be useless, and the attacker must crack each password individually. This is automatically true if you chose a modern password hashing algorithm, although it will only slow down a skilled attacker.

Modern (dictionary+rules) cracking efforts run on consumer-grade GPUs will recover 50%+ of passwords easily---unless you have insanely high complexity requirements and a high effort algorithm.