With some inspiration from Ben Ramsey i created a little demo for using my md5 database during the signup process on a website.
This example demonstrates the use of the MD5 database at http://md5.rednoize.com and AJAX to check password strength during signup on a website. After supplying a username and a password, a md5 hash of the password is generated using Paul Johnston’s md5 javascript library.
The hash of the password (not the password itself) is then sent to http://md5.rednoize.com. If the website returns a result for the given password (hence the hash password combination is stored in the md5 database) it can be regarded as “insecure”. Because the md5 hash of the password, and not the password itself is transferred, no sensitive data will be saved at md5.rednoize.com.
For sure not every password that is not stored in the MD5 database can be considered secure. I recommend adding some extra checks (existence of upper and lowercase characters, numbers, special characters and so on) to increase the password strength.
You can see the example in action here: http://md5.rednoize.com/ajax/
Feel free to use the code in this example any play with it ;)
To implement this on your own webserver you would need some kind of proxy script that redirects the AJAX calls from your own server to the md5 database.
Update:
I recommend saving passwords using salted md5 hashes. Salting in short: “When the user sets a password, a short string called the salt is suffixed to the password before encrypting it; the salt is stored along with the encrypted password so that it can be used during verification. Since the salt is different for each user, the attacker can no longer use a single encrypted version of each candidate password. If the salt is long enough, the attacker must repeat the encryption of every guess for each user, and this can only be done after obtaining the encrypted password record for that user.”
Here’s a little example using salted passwords:
To authenticate users on your website (login) your probably using a SQL statement like this one:
SELECT user_id, username FROM users WHERE passsword = MD5('thepassword');
This is insecure. If someone would know the md5 hash of the password, and the password is weak, it could be “reversed” using the MD5 database.
Use salted passwords to avoid this:
SELECT user_id, username FROM users WHERE passsword = MD5(user_id || 'some_secret_string' || 'thepassword');
Its also possible to store the salt along the password in the database.
Popularity: 42% [?]
Marcel Oelke!
7 Users Responded in " Checking password strength using md5.rednoize.com and AJAX "
Good one, thanks.
Its pretty simple approach, since many ppl will check common passwords with your md5() db :)
And yea P@ssw0rd is also a common password.
thx dude
Hi,
I really like your md5() password checker. I also like the AJAX implementation to check the passwords. I was trying to implement it on my site when i read your statement about the proxy script. Since i was confinced that there should be an easier way to use your “webservice”, I used a very simple PHP implementation. Instead of using a direct XML-request to your server, I made a local file called (for instance) check.php. This file accepts a GET-variable containing the MD5-hash and use that to query your site:
The rest of your javascript remains exactly the same, only the function should be called using:
javascript:xmlhttpPost(‘check.php?string=’)
Thanks a million for sharing this with us!
Hmm my code got ripped for security reasons probably:
$url = “http://md5.rednoize.com/?p&q=” .$_GET['string'];
$feedback = file_get_contents($url);
echo $feedback;
Great post Marcel,
The only comment I would like to make is that if someone gains access to the database in which you are also storing the salt they should be able to easily recalculate their own hash database using the salt you have now given them.
It’s true they would have to recalculate for every user because the hash is different but what if they only need to gain access to one account?
My own method for storing the salt would be to place it outside the webroot as a variable your script will read during the runtime. This way the attacker will not know the needed salt to recalculate the hash.
Making a more complicated model you could create a random salt for each user and store it outside the webroot on a one file per user basis.
Dynamic includes are a beautiful thing.
You can see my post about the subject at:
http://juanjose.blackfalconsolutions.com/2007/09/13/md5-hashing-and-salt/
Pingback & Trackback