What is the safety way to store Passwords in DB using a register form?

Question

I have a register form called server with fields Name, IP, Password. The form will send the data prevously filled by operator, but the problems is:

How the field Password will travel until my insert verification code ?

some short example:

The form

<form method=POST action=myActPage.php>
  <input type=PASSWORD name=PWD value="" />
  <input type=SUBMIT value=GO />
</form>

THE PROBLEM IS HERE --- BETWEEN --- THE TRAFFIC --- password can be stolen here.. how to prevent it to happen?

The PHP Action Page

if ($_POST) {

   $pwd = $_POST['PWD'];
   $pwd = md5($pwd);

   $response = mysql_query("INSERT INTO tbl_pwd ('pwd') VALUES ('$pwd') ");

}

Thanks for any idea on this matter.

EDITED: I really spent almost two hours searching on stackoverflow and I found nothing on this specifc matter, thats is why the question. No question about the "traffic between form and php action script" Important: I'm looking for a solution without the use of SSL over HTTP.

possible duplicate of [Best way to store password in database](http://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database) — Johan, May 25 '11 at 21:15

Richard Marskell - Drackir · Accepted Answer · 2011-05-25T21:06:14.180

7

If you're concerned about the password getting intercepted, you'll have to look into using HTTPS. Even if you hashed the password client-side, it would most likely still be susceptible to replay attacks.

Edit

As far as storing them, you don't want to use MD5 anymore. It's old and has flaws (see second paragraph). You should use a better hash algorithm such as SHA. You should also add a salt to them. The salt makes dictionary attacks more difficult, especially if you use a unique salt for every password. That will mean that even if two users have the same password, their hashes will be different.

edited May 25 '11 at 21:06

answered May 25 '11 at 20:59

Richard Marskell - Drackir

13,080
3
33
54

@Drackir Thanks, I do know about the use of SSL over HTTP, It is a solution, but I forgot to write this is this question, I'm looking for a solution without the use of SSL. Is that possible? – devasia2112 May 25 '11 at 21:05
@Drackir The code above was a tiny sample of the problem in question, I'm not using md5() hash function (was a sample) It is not my code. Just very curious about the password traffic, is there any way to keep it safety? perheps using JS to crypt it on event typing.. or whaever solution.. 'cause if there is no solution for this matter, only SSL solves the problem. Yeah? – devasia2112 May 25 '11 at 21:11
@Fernando Costa: If you were to encrypt the data somehow via JavaScript, an attacker could see how you encrypt it (and possibly figure out how to decrypt it) since it's client-side. They could also see the encrypted block of information itself and even without knowing what it says, just send that to the server over again. – Richard Marskell - Drackir May 25 '11 at 21:30
@Drackir You are right, but it means there are no way to safety store passwrd in database without the use of SSL over HTTP??? – devasia2112 May 26 '11 at 12:53
@Fernando Costa: I'm still confused as to whether you're talking about storing the passwords or sending them over the network. With regards to sending them, HTTPS is a tried, tested, well-documented, well-supported method for encrypting your HTTP traffic. There are always other options, but I'm just saying, why reinvent the wheel with a JavaScript scheme that you came up with (that may even have flaws you don't even realize)? – Richard Marskell - Drackir May 26 '11 at 15:51
@Drackir -- You are right, I'm just speculating the security of send data over the network, for sure I will not get in the JS solution to this kind of matter, I thank you for the advice. How I said, it is only speculation, since the web has a lot of website with register without using SSL over HTTP and it is a big fail, specially if the register request personal data. Thanks anyway for your time! – devasia2112 May 26 '11 at 16:21
@Fernando Costa: Yes. Many sites don't utilize HTTPS, probably because it can cost several hundred dollars to buy an SSL certificate. Most large sites have the option log in "securely". I always utilize that option when I can. You're welcome. :) – Richard Marskell - Drackir May 26 '11 at 19:32

score 1 · Answer 2 · answered May 25 '11 at 21:30

What you're looking for gets into math and cryptography. The Diffie Hellman key exchange would also work very well.

You should widen your search when doing your research. Stack Exchange is good for specific problems but bad for gathering general knowledge.

Johan · Answer 3 · 2011-05-26T12:58:20.640

To expand on @Drackir:

If you are really worried, double wrap your hash. First store a plain old salted hash as your password in the database, just a hash, with e.g. the username as salt.
This should preferably be a password that is system generated, because humans suck at making passwords other than password1 or monkey.

You will never compare against this hash, but always against a double salted hash using a timestamp.
The timestamp is provided by the php server. And I'm assuming the channel between the php-server and the MySQL server is safe by using a SSH tunnel or whatnot.

Here's example code that demonstrates my suggestion.

Timestamp double salted hash login

$user = mysql_real_escape_string($_POST['USER']);
$password = $pwd = $_POST['PWD']; 
$time = time();
$hash = hash('sha512',$time.hash('sha512',$user.$password)); 

$query0= "SELECT * FROM logins WHERE user = '$user' AND `timestamp` <= '$time'";
$query1= "INSERT INTO logins (username, `timestamp`) VALUES ('$user','$time')";
$query2= "SELECT * FROM users u 
           INNER JOIN logins l ON (l.username = '$user')
           WHERE u.username = '$user' 
           AND sha2(CONCAT(MAX(l.`timestamp`),u.passhash),512) = '$hash'";

Instructions
First run query0. Deny any logins that return a row, because any match means someone is trying a replay.
Next run query1 and query2 in that order. Allow any login with a match.

This will prevent replay attacks as well as defeat rainbow tables.
If you use system generated passwords, if will also make password guessing very hard.
Remember to block the account after x wrong login attempts.

If you do not a botnet can guess a password an unlimited number of times across all your user names e.g. 1 million users x 1 million attempts will guess a numeric password of length 12. (not statistically sound but you get the idea I hope)

Please excuse if there's a minor error in the php, I'm a bit rusty on that front

What is the safety way to store Passwords in DB using a register form?

3 Answers3