Drupal should have a salting variable set in its configuration that it prepends or appends to passwords prior to computing the MD5 hash for the database. This would increase security by rendering pre-computed dictionary attacks useless without the salt, which could/should be stored as a server variable outside the database so that even if someone compromises the RDBMS then the passwords are safe.

I have a great deal of experience writing modules and classes for Drupal for work in-house and would be willing to tackle this if I have some agreement in principle that this is a good idea.

Thank you.

Comments

erdemkose’s picture

Version: 4.7.3 » x.y.z
Component: user.module » user system
Category: bug » feature

I aggree that salting is important. But I have a question. How can we replace old passwords?

I think a helper module must be written. It will replace user password hash with a salted hash while signing in and keep track of which password hashes are salted. And when all the password hashes are salted, it must create a watchdog entry to be removed.

Any better solution?

*Since this is a feature request I have moved it to cvs. New features will be included in cvs version only.

shultzc’s picture

I agree, that's probably the safest way to do it.

Egon Bianchet’s picture

Version: x.y.z » 6.x-dev
selmanj’s picture

Status: Active » Closed (duplicate)
gravisrs’s picture

I think I've found best solution.

For user table add field called salt which is null by default. This field will be generated automatically as a random bytes during user register and password recovery, and will be concatenated with password before creating & saving hash to database.

This will preserve old accounts (null added to password won't change hash) and will implement anti-rainbow security.