Storing passwords - converting to a better way

[IndynewToPhp]

Hi,

 

I'm fairly new to PHP, MySQL but I've been storing user passwords (all I store is a username and a password and an email address) in the MySQL database. I've used the password() function to hash the password before storing it in the database but I've discovered that is not the proper way to do it...but am unsure if it is "unsafe".

 

Besides the fact that it could break depending on MySQL version, is it inherently easy to crack?

If so, then I want to change how I am storing the passwords....using MD5 or SHA-1. Are there recommendations on how to go about porting over this change? I'm assuming everyone will have to get new passwords since I can't retrieve the old password to put into MD5 or SHA-1.

 

Any advice on both these matters are extremely appreciated. I found some very old topics on this so this is why I started a brand new one. One old topic was here:

http://www.phpfreaks.com/forums/index.php/topic,77769.0.html

 

Thanks

 

 

 

 

[JonnoTheDev]

Store a password however you want. You can use md5, crypt, make up your own algorithm, etc

When a user enters their password to login you must run it through the encryption function in your php script and then compare it to the database record.

[IndynewToPhp]

Thanks for your response

 

I am already using an encyption method.... password(). But I've found out that is not a good idea. What I am unsure about is...is it not a good idea because the implementation may change or if it is a very weak method or both?

 

My second question is, if anyone has any advice on how to stop using password and move to a better encryption method. The problem is, any stored passwords will be using the old way and so I am unsure how to move to a new way of storing passwords. I'm pretty sure everyone will have to enter new passwords but again, maybe there is a good way to handle this I am not thinking of.

 

 

 

 

[JonnoTheDev]

But I've found out that is not a good idea

Where have you found this information from?

 

If you dont want to use PASSWORD() then use md5() in php. Nothing wrong with that.

[IndynewToPhp]

Hi,

 

Where I found information: One of the sources is in my original post. See that link.

 

Secondly, I do know I can use whatever I want...and that is the issue...I want clarification on if password is weaker and easily breakable than md5 or sha1.

 

and again, secondly, now that I have ALREADY implemented everything using password, and users have signed up...how I can go about changing this with limited disruption to the user.

 

Anyway, thanks, I appreciate you are trying to help but again, I am aware of how the various ways of storing passwords....just wondering if it's worth it to change from using MySQL function password to something else.

 

Hope to hear more comments

[Daniel0]

Regardless of the hashing algorithm you choose you need to use salting to make brute forcing and dictionary attacks more difficult. I'd recommend an application wide static salt that never changes coupled with perhaps a user specific salt that changes e.g. when logging in. I'd probably go with a strong hashing algorithm like SHA-512 available through the hash() function.

 

As for changing the algorithm, that's a bit more difficult. You could keep the current password and then create a new field called "password_new" or something like that. When authenticating you'd check if password_new is empty and then use the old algorithm. Seeing as the password is supplied when authenticating you'll be able to update to the new algorithm. This means, however, that you'll still be vulnerable to attacks using the old algorithm's weaknesses. Another option would be to simply require all users to reset their passwords and send them an email informing them about it. The former has security implications, but is transparent to the user. The latter is more secure, but isn't transparent and requires the user to actively do something.

[IndynewToPhp]

I like the new field idea.....after storing the new hash into the new field, I can then remove the old hash (from password()). I think I'll implement that...then after 30 days....if someone hasn't visited for that to occur, I'll delete all old passwords from the system and when they come back, and try to log in, I'll say that we've updated the website and they have just been sent a new password.

 

Does that sound reasonable?

[Daniel0]

You could do that. It's a bit messy though.

[IndynewToPhp]

Well its a site with a small # of people...and some may never return. I'd like to give the regular user a chance to convert to new way of storing password without having them be sent a new automatically generated password (which is what happens now when they forget their password)....so your suggestion of updating when they log in is a good one. However, I don't want to do that forever, because as you also suggest, it is still somewhat vulnerable so after a certain point, I will delete passwords that are stored poorly (though hashed with password()...)

and when they attempt to log in, tell them that passwords are being updated to be more secure and they need to enter their email address (as I already have their username) to be sent the new password.

[corbin]

You could always use the same column for passwords....

 

 

Update it if the hash from the old function matches, but that could easily get ghetto.

[IndynewToPhp]

Thanks.

 

Maybe I'm not understanding but the only thing that saves me is adding a new field to the database....still have same issue of figuring out how to move everyone to the new hashing scheme if they don't ever sign back in for months and months.

 

To be honest, I'm irritated with myself I didn't realize using password() wasn't the best I could do...but hey...live and learn.

 

I am glad that I don't really have anything outrageous stored...just email address, password, their name.....but it's making me nervous that I don't have their password stored better in case they reuse it on other sites...which everyone does.

 

The one thing that makes me feel better is that when they enter new password (if they don't like the auto generated one when they sign up) is they have to have a combo of numbers between letters and so on on so that may keep it unique to my site.

 

 

[corbin]

Uh, do you plan on your DB getting stolen?  lol.

 

 

 

But one solution could be to hash the PASSWORD() return (you would have to reimplement it in PHP to make it efficient).

 

Then you could simple do:

 

SELECT 1 FROM users WHERE username = '$username' AND (password = '$sha_pass' OR password = '$sha_pass_pass');

 

Where $p is the user's password in plaintext, you would do something like:

 

$sha_pass = hash('sha512', $p);

$sha_pass_pass = hash('sha512', PASSWORD($p));

 

 

 

 

You would of course eventually want to move to all of one hash type though.

[Daniel0]

Uh, do you plan on your DB getting stolen?  lol.

 

Always plan for the worst scenario. Expect your users are malicious. Except that your system will be compromised. Trust nobody, trust nothing.

[corbin]

Yes, I accepted that mentality a long time ago with programming.

 

 

I just thought the wording was funny, almost like he expects his database to be stolen in the near future.

[IndynewToPhp]

No, but now that I am aware that I've implemented this poorly ...or at least....it can be implemented better....perhaps I do have a sense of urgency about it that came through. Hell I don't know....all this talk about the total collapse of the U.S. Financial system has me on edge too...maybe it's that

 

It is funny, because hey, it's been this way for awhile now. But NOW...I know about it.

 

Thanks for your tips and suggestions.

[IndynewToPhp]

Oh wait, I think I see. doh!

 

I could convert all the poorlyhashed passwords RIGHT now to the new hash method.

 

I can run the password that the user enters when they try to login through the password() first, getting the poorlyhashed password. Then run that result through the new hash function. If that result matches what is in the database...boom (roasted)...I'm in. If not, sorry you're out.

 

That's the idea right?

 

Didn't realize what you meant until I read it 20 times. Low IQ. Lead poisoning.

 

 

 

[corbin]

Yes, that would be the basic gist.

 

 

 

Then, if it did match the old hash type, you would want to convert it to the new hash type (since you would have the user's password in plaintext again).

[IndynewToPhp]

Yes good point.

 

I read that hashing twice may not be a good idea but the reasons why made me a bit dizzy.... but in this case it improves things.

 

I should be able to "add salt" in this whole process just like I would if there wasn't the extra step.

 

Anyway I'll try all this out. You were a great help.

 

 

 

 

[IndynewToPhp]

Alright, thought I was done pestering. I'm not testing this tonight....will do so tomorrow but...

 

do I *have* to implement my own PASSWORD function to do this....or is it possible to continue using MySQL's? Maybe....

 

$query = "select PASSWORD('$passwd')";

$result = mysql_fetch_array(mysql_query($query));

$user_pass = $result[0];

 

 

if I do have to reimplement it...I'm reading that it is just a double SHA-1 hash...does that sound right?

 

[corbin]

Double sha1?

 

C:\Users\Corbin>php -r "echo sha1(sha1('corbin'));"

ed592d4061c783e5cb0173ea60d0f5d95d71d298

C:\Users\Corbin>mysql -uroot -proot -e "SELECT PASSWORD('corbin');"

+-------------------------------------------+

| PASSWORD('corbin')                        |

+-------------------------------------------+

| *C76713651E3DC3332A10353B46CE2E34A310579C |

+-------------------------------------------+

 

Doesn't look like it, but maybe I did something wrong.

 

 

 

As for the hash being less secure because it's double hashed....

 

 

In this case, I don't think double hashing would reduce the security.  It some cases it definitely does though.

 

 

I could be wrong though.  I can explain the math behind my theory if you want, but I don't feel like typing it all out.