one-way encryption: mysql PASSWORD() vs php crypt()

xblue

I'm currently developing a user login system, and the passwords are stored one-way encrypted of course.

I started off using the mysql PASSWORD() function, but if 2 users have the same password, the encrypted version would be the same as well, which I'm not quite happy with.

So I consider using php's crypt() now, which should work fine this way:

// on insert and update
crypt($pwd); // always different with same $pwd

// to compare
if ($from_db == crypt($pwd, substr($from_db,0,CRYPT_SALT_LENGTH)))

However, what I'm really worried about: CRYPT_SALT_LENGTH is dependent on the system if I understand it correctly. Now, if the system would be updated, no user that registered before that time would be able to login anymore, or am I wrong?

The safest way I can think of right now would be to store the CRYPT_SALT_LENGTH along with each password. Any other suggestions? How do you handle this?

[edit: the example was a bit off, should be better now]
edit:

I've just had another idea: what about leaving the password PASSWORD() encrypted in the DB as it is, but encrypt this one again with crypt() when I need to store it client side? (the login uses either cookies or single login -again and again *g- for each protected action. I do have reasons not to use sessions.)

axo

hmmm... perhaps you should try to make unique usernames; don't let users choose an username which is already in use .

then perhaps you could try $string = md5($password) and save $string as the password in the database.

$md5 is one of the safest possibilities to do one-way-encoding 🙂 ... but if you like it better, you can also use crypt() 🙂

checking if login is true looks simple:

$user = $_POST['user']; // from form-data
$pass = md5($_POST['pass']); // from form-data

// the mysql_query:
$query = "SELECT * FROM members WHERE username='$user' AND password='$pass' LIMIT 0,1";

if(mysql_num_rows($query) == 0) {
 // login is wrong
} else {
 // login is true;
}

again: hope it helps 🙂

Apfelsafft

Hmmm,
i don't really know the crypt function. But as CRYP_SALT_LENGTH is a constant, depending on the OS, you could just use the username somehow as the salt's length.

Just ment as a hint....

matt_4013

I would suggest using md5 as your encryption method, as it's probably one of the safest you're going to get. If you notice in the mysql manual, it advises AGAINST using the PASSWORD() function to encrypt your passwords.

Also, by using md5 you can check the hash from different languages, OS, etc. as it's a standard. Comes in handy for porting and cross-platform.

matt_4013

btw, you're going to have trouble encrypting on the client using crypt or md5 because both are irreversible. Which means that you wont be able to send an encrypted version to the server, decrypt and then check it. If it's not REALLY sensitive, you might be able to do something like encrypt it to hex on the client side, so that anyone that's just opening up the cookie wont be able to read just a plain text password, however if anyone's really wanting to crack on the client side, then there's not much you're going to be able to do about it.

xblue

Matt, thanks for the note on PASSWORD(), I won't consider using it then.

Apart from that, maybe I wasn't as clear as I thought 🙁

The usernames are unique, but passwords users choose generally are not (have you ever received a "password is already taken" error?)

And I know md5() and crypt() are irreversible, this is not the problem. It is just that I'd like to use crypt() rather than md5() because it encrypts same strings in different ways if called without additional arguments, while you can make it encrypt in the same way as before in order to compare the encrypted password to the saved encrypted password.

Exactly what I need, but still - in case that system constant ever changed, it would probably break everything :eek:

matt_4013

AFAIK, the system generated salt for crypt is generated at compile time, and never changes after this. Could be misunderstanding, I'm not 100% sure. If this is the case, in the unlikely event of server migration, you could just set yourself up a script that will generate new passwords based on the new salt, and email all your users saying "hey, there's been a problem, you've got a new password, change it ASAP". Sure, not the neatest thing in the world, but it would work.

You can also use your own salt though, so you could do something like:

$sPass = crypt($sPass, substr($sPass, 0,4));

So that the salt will always be the first 4 letters of their password 🙂

xblue

Hi,

thanks for all your advice. I followed your hint to use md5(), which I feel is much better after some redesign than the way I had it before.

Now, where is that 'resolved' function? I probably need to edit the first post, let's check.

🙂