4

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?

  • 1
    Related (not sure if it's close enough to be a dup): security.stackexchange.com/q/208963/151903 – AndrolGenhald Aug 29 '19 at 18:16
  • See this article about swapping the passwords to increase privileges. – kelalaka Aug 29 '19 at 18:27
  • Yeah. That's close, but not quite there. It's a given that if an attacker can do this there could be serious problems. As in the other question, those serious problems could include having the application decrypt secrets that the compromised user has access to. I have a mitigation in mind, but am mostly questioning whether it's worth implementing. – Michael Cordingley Aug 29 '19 at 18:28
  • @kelalaka: It seems that there are more vectors for this to happen than I had initially thought. That's bumping my estimation of the need to mitigate. – Michael Cordingley Aug 29 '19 at 18:30
  • Yes it need to be guarded against and mitigation for this are also pretty standard.. so go for it.. – Soumen Mukherjee Aug 29 '19 at 18:37
4

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.

  • Thank you. I think this more or less addresses the question. Essentially, I should be worried about the scenario in question if the application stores data sensitive enough that I'd be encrypting it in the first place. Encrypting in the database implies some level of concern about the database being breached. The database being breached is likely to translate into the attacker also having write access, etc. Your point about the attacker being able to modify other values is well made and is something that I'll have to think about. – Michael Cordingley Aug 31 '19 at 16:59
  • That red arrow isn't a necessarily a problem. Someone could make a throwaway account. Or hijack any other user's account using a different method, like phishing. – Future Security Sep 5 '19 at 0:57
0
  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.

  • Perhaps I didn't explain it clearly. There can be values that are encrypted in the database. Users with permissions to those values can see them in plaintext, as the application performs a decryption for the sake of the authorized user. If the attacker is able to replace another user's password and then log in as that user, the attacker now has access to those values. – Michael Cordingley Aug 31 '19 at 16:53
0

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.

  • I think you misunderstand. I'm not asking about the damage done with a copy of the database out in the wild. Passwords are bcrypted, which should make them uncrackable*. I believe my model is at least in part "an attacker has acquired some manner of access to my actual database". I just don't know how often however the attacker got read access also ends up giving write access. I get that this is not a well-formed scenario, but that's what I'm actually trying to get a handle on. – Michael Cordingley Aug 29 '19 at 22:30
  • My reading of the question is that it's about an attacker with access to the database on your server, which they could leak, and asking whether they could instead/also edit it. – Josiah Aug 29 '19 at 22:37
  • @Josiah That's correct. – Michael Cordingley Aug 29 '19 at 22:51
  • @MichaelCordingley What you're talking about is called privilege escalation. Although it is most often discussed at the OS level, it applies to any piece of software. E.g., CVE-2016-6663 for MySQL/MariaDB. – DoubleD Aug 30 '19 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.