Distinct salt for each user [#199358]

If I have the same salt for all users, it becomes easy to find the users with the same password. If a user hacks and finds the salted passwords, he/she can find all other users with the same password.

Is there a way to make the salt unique for each user? For example, can I use each user's username or account creation time as the salt? Can I insert a variable name that denotes the user's username or account creation time as the salt value under the Salt module configuration? Thanks.

Comment	File	Size	Author
#7	salt.per_user.patch	3.9 KB	jhedstrom
#5	salt.per_user.patch	2.84 KB	jhedstrom
#2	salt_with_nonces.tgz	2.4 KB	steve.m

Comments

Comment #1

Zen commented 11 December 2007 at 08:53

This module was created to handle a site I was porting to Drupal. As such, I have no plans on coding new features at the moment. I will be happy to look at patches though.

I also don't think the scenario that you have outlined - finding other users with the same password - is easy. The cracker might know other users with the same password, but won't know the actual password itself. The aim of salting is primarily to prevent attacks such as rainbow table attacks. While using individual salts will be nice, I don't see how it will be anything more than a stumbling block once the system has been compromised.

If you're interested in coding this, you could perhaps look into using the token module to specify the salt string. Just a thought.

Thanks,
-K

Comment #2

steve.m commented 27 December 2007 at 05:24

Status	File	Size
new	salt_with_nonces.tgz	2.4 KB

There are a couple of reasons to want per-user (nonce) hashes. The risk of easily identified duplicate passwords is one; another is that discovering the site-wide salt value lets an attacker break ALL the passwords by recomputing a rainbow table.

I revised the module to apply a random nonce hash per user. The settings form now lets admins choose to turn on the nonces -- this will invalidate any passwords created with the site-wide salt, of course.

I attach the revised salt.module and salt.install. I wrote this up fairly quickly and tested it on a site with relatively few users. I'd want to test it more thoroughly before putting it into play on a production site.

Comment #3

steve.m commented 27 December 2007 at 14:24

Hm. It occurs to me that this module could remain compatible with existing non-salted passwords if it re-hashed the password on hook_user events rather than on login form validation. This would introduce a race condition (the password would be unsalted until the hook kicked in), but existing passwords would still be valid. That might help make this change make it into core, which would ultimately solve the race condition.