Page 1 of 1

Random thought about password hashing ingredients

Posted: Wed Aug 03, 2011 4:19 pm
by flying_circus
This is a hypothetical situation, but lets say I gain access to a database, but not the file system. This could be a SQL injection voulnerability through some test script in an obscure directory on the webserver, or whatever else you can imagine.

Typically user registration systems are stored in the database as:
UserId, UserName, UserPasswordHash, UserPasswordSalt

Usernames are typically plain text, while password and salt are hashes

My point is, if I have access to the database and I have created an account, I know my own password. So consider the following:

# Fetch My Personal Info
SELECT `userPasswordHash`, `UserPasswordSalt` FROM `users` WHERE `UserName`='my_username';

# Update All Users Info
UPDATE `users` SET `UserPasswordHash`='my_password_hash', `UserPasswordSalt`='my_password_salt';

Now I know everyone's password. I wouldn't have to have any knowledge of the password hashing scheme mechanics to make this work.

In addition to a random user salt, plus a global pepper (stored outside the database), I think it would be beneficial to add the username or id to the password hashing scheme. Tying the username into the hashing scheme would make the hash unique, even if the password and salt were identical.

On the other hand, if I have access to the database, it's already game over, but with that mind set, why hash passwords before storage to begin with?

I don't know, I'm sure most of you have already thought about this before, but it dawned on me while driving to work this morning. Any comments?

Re: Random thought about password hashing ingredients

Posted: Fri Aug 05, 2011 12:29 am
by André D
Hashing passwords is less about protecting your system and more about protecting your users. Many people use the same password everywhere, which means if your system is compromised and your users' passwords are discovered, then higher value attacks against your users are possible, such as bank and e-mail accounts.

Re: Random thought about password hashing ingredients

Posted: Fri Aug 05, 2011 12:34 pm
by social_experiment
Interesting...I've tried this once or twice when i've lost my password but never thought about it from an attackers point of view. This statement about access to the database meaning the game is over is probably the thing that stopped my thoughts from continuing as i would imagine if a malicious user were to gain control of your database, what would there first action be? No points for guessing "TRUNCATE table_name".

However, not all users are malicious, there might be a few who decide to give themselves access to see how things work, etc. It would probably be a lot harder finding an illegal 'legal' user when searching because on the surface everything seems normal; user logs in with their password so they must be who they say they are. This actually highlights (for me) why there should be an external pepper or something else to differentiate between users, because as demonstrated, even hashed passkeys aren't as secure as we would like them to be.
André D wrote:Hashing passwords is less about protecting your system and more about protecting your users. Many people use the same password everywhere, which means if your system is compromised and your users' passwords are discovered, then higher value attacks against your users are possible, such as bank and e-mail accounts.
Imo it's a 50-50 split between protecting your system and your users. If your system were penetrated due a breach as mentioned by the OP i don't think your users would even contemplate changing their other passwords because if they were savvy enough (which they aren't) they would know NEVER to use the same password for two accounts. They would most likely be outraged by your system and it's lax security, a case of pot calling the kettle black.

Re: Random thought about password hashing ingredients

Posted: Mon Aug 08, 2011 2:02 am
by Mordred
In a realistic scenario, you're much, much more likely to gain read-only access to the database than a read-write access. This is the most common intrusion and this is what salt-and-pepper is a good measure against.

That said, even in this attack scenario, if your salting scheme includes the username as part of the per-user salt, you still would not be able to "copy" your credentials over the admin's.

Re: Random thought about password hashing ingredients

Posted: Mon Aug 08, 2011 3:43 am
by social_experiment
Mordred wrote:if your salting scheme includes the username as part of the per-user salt
In this instance, would you store the username as a plain-text value in the database?

Re: Random thought about password hashing ingredients

Posted: Mon Aug 08, 2011 4:31 am
by Mordred
social_experiment wrote:In this instance, would you store the username as a plain-text value in the database?
Sure, why not, the only purpose and requirement for usernames is to be unique.

You could probably cook up a scheme where you keep some hash of the username (and still satisfy the uniqueness requirement), but why bother if you protect the password.
Also, salts are not required to be secret (though it's good if they are, hence the recommended salt-and-pepper scheme). Including a known component (username) in the salting scheme is no different than using the per-user salt itself (which is still kept in plaintext in the same database).

The benefit comes from preventing a replay attack against another user, as flying_circus suggested (BTW: Good one, mate!).

Re: Random thought about password hashing ingredients

Posted: Mon Aug 08, 2011 4:53 am
by social_experiment
Mordred wrote:Sure, why not, the only purpose and requirement for usernames is to be unique.
Ok, to add another angle to the discussion - The 'safe' use of usernames as part of the salt is only effective if its use as part_salt remains unknown because it's not hashed or encrypted. Granted that one piece of the puzzle that is know in the security chain might not give access to the system but it is something that the malicious attacker doesn't have to find out.

On another hand, if the username is taken, then hashed or modified in a manner to help with authentication, storing it as plain-text wouldn't be a problem. It seems (to me) that the 'weaker' link of the login system is the file system, which contains the recipe to the baking of the authentication data. If that were to be known, no amount of hashing would matter, and the storing of the username as plain-text would be moot.