Password salting by default?

Password salting by default?

by Garret Gengler -
Number of replies: 7

I noticed recently that password salting (for internal enrollment) is not enabled by default. It seems to me that a randomized salt should be assigned by the Moodle installer, and the upgrader or security report should force a salt be assigned if one is not set.

Without salting, hashed passwords are trivial to crack with rainbow tables and the like. It's a myth that the MD5 algorithm is not-reversible.    For short plaintext, the hashes can be pre-calculated by a processing farm, and stored in a db for easy lookup.

Online sites like http://www.md5decrypter.co.uk/ and http://www.cmd5.com/english.aspx can reverse billions of md5 hashes.  In my testing, they can reverse many typical user passwords.  Try it yourself if you're curious... look up the password hash for a given account in the moodle db (select password from mdl_user where username='user') and copy/paste it into the md5decrypter site.  You might want to be sitting down.  smile

If you salt a password before hashing, you effectively eliminate the possible that the hashes can be reversed.

The code for handling salted passwords in /lib/moodlelib.php looks complete..

-- when a password is checked, the code looks for CFG->passwordsaltmain.  If set, it appends the user's password to the salt before the md5.

-- if the unsalted md5 of a user's password validates, it is assumed that the salt was set for the first time since the last time the user logged in.  The user's password is upgraded, using the salt.

-- if neither the unsalted md5, or the salted md5 validates, the code looks for up to 20 alternate salts.  I can see how these could be used to change the main salt without locking out your users.  (You would store the old main salt in one of the numbered alternate salt slots, and set the passwordsaltmain to the new value.)  Then after a suitable time for password rehashing (a year or so) you could clear out the alternate salt entry.

So... is there a reason why Moodle couldn't set up a random salt by default?   Something like 32 characters of alphanumerics + punctuation would be ideal.

-Garret

Average of ratings: Useful (3)
In reply to Garret Gengler

Re: Password salting by default?

by Dan Poltawski -
Great post, you raise a good point. I think I would like to see this go further though, I am not a big fan of the 'site-wide' salt strategy and instead would like to see us convert to a per-password salt.

This is a bit tricky to upgrade from and i've never really considered what would be the best way to upgrade to enforced salting.

Could you create an issue in the tracker for this? Hopefully we can get some votes and have many minds considering the best way to proceed.
Average of ratings: -
In reply to Dan Poltawski

Re: Password salting by default?

by Myles Carrick -
That's a fantastic idea... and per-password salting gets my +1.

I don't think it's possible to just upgrade all of the passwords... but an upgrade path could see each user get a new salt and salted password the next time they login...? (i.e. just what the current code does after the global setting is enabled). It'd leave existing user accounts unsalted... but that's certainly no less secure than at present.

Myles C.
Catalyst AU.
Average of ratings: -
In reply to Dan Poltawski

Re: Password salting by default?

by Garret Gengler -

I like the idea of per-user salts... I'll have to read up on what the encryption and security community thinks of that.... here's one discussion I found helpful.

http://forums.devnetwork.net/viewtopic.php?f=34&t=62782

The first post in that discussion advises generating a per-user salt, and storing it in the db along with the hashed password.

I wonder if that is necessary... I would think it would be equally valid to generate the "per-user" part with an algorithm.

I'm thinking something like this:

combo_salt= system_salt + (every other character of the password + userid))

I don't think you would want to draw from the username or email address in generating the user's salt, because those might be changed by a site admin or by the user (thus invalidating the hashed password).

But you could use the numeric userid, plus all or some of the password itself. 

Let me think about this some more, and create an issue in the tracker.     It's funny though... at my school, we are not using Moodle to store passwords, since we use CAS for authentication.

I just happened the other day to notice that someone had attached a full database dump into a Moodle tracker issue...  Out of curiousity, I downloaded the dump file, and found to my alarm that the user tables were present, including the hashed passwords for three admin-role accounts.  I was able to easily reverse two of the admin accounts using the md5decrypter site.   (I have since notified the poster to take the db dump offline and to change passwords.)

That got me thinking though that Moodle is taking unnecessary risks with user passwords... there is simply no reason not to salt the passwords.   It is all-too easy to grant a hacker read access to the mdl_user table... either by a bug in the codebase, or by allowing uploaded code to execute, or by improper mysql permissions, or by leaking a database dump.

And if you know a simple md5-hashed password, you can reverse it immediately if it's in the look-up tables, or by brute force in a few days.

Average of ratings: -
In reply to Garret Gengler

Re: Password salting by default?

by Hubert Chathi -
Using the userid (which is predictable -- especially for the admin user) does not add much to the strength of the salt, and using parts of the password is essentially just a weak modification of the hashing algorithm, and does not add much to the strength of the algorithm. It's a step up from using just a system-wide salt, but it is trivial to build a lookup table for a single user on a given site (if you know the system salt). Once the table is "complete", you can look up the user's password whenever it gets changed.

In contrast, the standard method is to randomly generate a salt every time the user changes their password, and store it somewhere (usually alongside the hash). This way, you need to start brute forcing from square one every time the user changes their password; you can't use any pregenerated tables of any sort.

As for what the security community thinks of per-user salts, UNIX has been using it to store user passwords for a very long time.

By the way, I highly doubt that you could brute force an MD5 hash in only a few days (provided that the password was chosen well), unless you had a very large computer. But in any event, a salt doesn't help against a brute force attack (it is only effective against rainbow tables), and it is generally recommended to use SHA-? instead of MD5 these days anyways.
Average of ratings: -
In reply to Hubert Chathi

Re: Password salting by default?

by Garret Gengler -

Good thoughts, Hubert. 

BarsWF is a recently-released MD5 cracker that uses Nvidia graphics cards to achieve serious performance improvements.  I have not used it myself, but folks are claiming it can generate 3.6 billion hashes/second.  Some published speeds:

All passwords (lowercase or uppercase, alpha)

  • up to 8 characters => 60 seconds
  • up to 9 characters => 26 minutes
  • up to 10 characters => 11 hours

All passwords (mixed case, alphanumerics)

  • up to 7 characters => 16 minutes
  • up to 8 characters => 17 hours
  • up to 9 characters => 4 days

My understanding is that Barswf has (or will soon have) support for many salting methods.   So the only true source of entropy is the user password itself.  The rest is known.   Even if you randomly assign a random per-user salt, you have to assume that if the hacker has a password hash, he also has the per-user salt, and the system-wide salt, and he has the codebase to see how they fit together.

Generating md5s of long strings (like salted passwords) is slower than generating md5s of short strings (bare passwords).   So we would have that working in our favor.   But the md5 algorithm is fast by design... 3.6 billion hashes/second for one machine... imagine a bot net of infected gamer machines running this... eek.

If we really want to have secure password hashes, we need to move to a better algorithm...  something that takes more time to generate a hash.   bcrypt is recommended for password hashing, for this reason.    It is designed to be computationally expensive (and variably-so, so that it is future-proof).

My main concern is still the trivial case of hacking moodle passwords by online rainbow tables.  And that can be prevented by setting CFG->passwordsaltmain to something other than "".

Best regards,
-Garret

Average of ratings: -
In reply to Garret Gengler

Re: Password salting by default?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
We really ought to have an admin setting for CFG->passwordsaltmain, and have it on by default. Please ensure that there is an issue in the Moodle tracker.
Average of ratings: -