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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Zen’s picture

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

steve.m’s picture

FileSize
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.

steve.m’s picture

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.

Zen’s picture

Status: Active » Needs work

If you can roll this up into a proper patch, that will be great. I'm not too keen on modifying core tables either.

As for inclusion in core, please see #29706 .

Thanks,
-K

jhedstrom’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev
FileSize
2.84 KB

Attached is a patch that enables this for Drupal 6.x. It adds a sub-module, salt_user, that handles the storage and generation of the per-user salts.

jhedstrom’s picture

Note that the last patch is broken for most use cases...working on it more.

jhedstrom’s picture

Status: Needs work » Needs review
FileSize
3.9 KB

Here is another attempt.

drewish’s picture

What about using the {users}.init field? That should be static after the user's created.

aosiname’s picture

I wish I'd seen this (plus patch) before writing a module i called saltandpepper (not released). It would be a duplicate of this :(:(