2

I was reading that a lot of authentication systems use cryptographic hash functions, whereby instead of keeping the username and password of their users they just keep the username and a hash of the associated password. This way, the system only has to compare the hash of an entered password to the known hash associated with that username's password.

Since hashes are theoeretically unique and hash functions always map to the same output, this seems like a secure scheme.

However, I was thinking about the following scenario: Let's say a hacker gains access to the server's database and can see the output of password hashes from the hash function used. Couldn't that hacker choose a password (any legal password), get the hash of that password, and then modify the database to replace another user's password hash with the hacker's own password hash? Thereby fooling the server into thinking that the hash associated with that username is the hash of that user's password, when in fact it's the hash of the hacker's password.

I'm sure this is completely bogus or it would happen all the time, but I'm curious as to what about it is infeasible.
Obviously one could question the need to do this is the hacker has already gained access to the server's database, but I'm thinking of a case where the rest of the valuable information is encrypted in a way that can only be accessed by certain users.

6

If an attacker gets write access to the database (e.g. through SQL injection), then there is nothing preventing them from changing users' password hashes to their own. The reason it's not brought up too often is that, as you point out, there are usually more serious concerns if an attacker has write access to the database.

I'm thinking of a case where the rest of the valuable information is encrypted in a way that can only be accessed by certain users.

The best way to do this would be to derive the key from the user's password (separately from the password hash used for login), in which case replacing the password hash wouldn't allow the attacker to decrypt the information.

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.