I know that, for security reasons, it is necessary to hash (with salt) the user's password and comparing it to a stored hashed password, so if anybody else gets the hashed string, he will have no way to compute back the password or look it up in a rainbow table.
There is one part of the method that I don't understand. Let's say I have this standard login form
<form method='post' action='login.php'>
<input type='text' name='user' />
<input type='password' name='password' />
<input type='submit' name='submit' value='login' />
</form>
and then I use PHP for login
<?php
if(isset($_POST['submit'])){
$username = $_POST['username'];
$password = sha1($_POST['password']);
$authorize = $login_object->login($username, $password);
}
?>
and, behind the scenes, the $login_object
takes care of authenticating with the database and returning true/false. (I made this object up, I have real, useful objects to do this)
but that means the password in the POST request
traveled raw, un-hashed and unsafely! Anybody could have intercepted the real password!
So what I am thinking is that I should use javascript to hash the password before it's sent. I would have a hidden field <input type='hidden' name='real_password' value='' />
and have javaScript copy the value of the input named password, hash it, put it in real_password hidden input and blank the password field. This way, the POST request
would have the hashed password and not the raw, unsafe, original password.
Am I right with what I'm saying, or should I just do the hashing on php?
Hashing secures the data on the server side. To secure the data-flow to the server, use HTTPS. In that regard it makes no difference whether the password or its hash is stolen (and later duplicated) on the wire. HTTPS also grants certificates to ensure that a padlock is displayed in the user's browser (remember never to enter important password in pages without proper certification).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With