md5 password with login script

[topflight]

I have created a login script which gets the password from the mysql database well the problem is that when the user sign up I md5 the password so it is some big log character how can I use the password the user signed up with for the login script and still have the password MD5?

[Maq]

It's one way encryption so you have to md5 the input from the user and compare it to what the DB has.

[topflight]

oo ok thanks

[topflight]

Ok how can I send a member the password when it is MD5 in an email I want them to see their actual password not the MD5 one.

[Silverado_NL]

Ok how can I send a member the password when it is MD5 in an email I want them to see their actual password not the MD5 one.

you cant, unless u store the password in a normal format somewhere in your database.

md5 is a one way encryption, the hash u end up with cant be reverted back to a password.

best practice would be to have an option on your website where people can reset their password instead of asking the old one.

[Maq]

you cant, unless u store the password in a normal format somewhere in your database.

 

That would defeat the whole idea of using encryption.  If you store both why not just store the original?  Very bad idea...

 

Ok how can I send a member the password when it is MD5 in an email I want them to see their actual password not the MD5 one.

 

Are you talking about a "forgot your password" thing?  If so, you need to generate a new random password and send it to them.  Then MD5 it and store it in your DB.

[Silverado_NL]

you cant, unless u store the password in a normal format somewhere in your database.

 

That would defeat the whole idea of using encryption.  If you store both why not just store the original?  Very bad idea...

 

read his question then read my answer:P, it answers the question, im not saying its a good idea.

as topflight clearly asks he wants to have people be able to see their "forgotten" password.

and as u cant restore md5 encrypted passwords, he must either do one of the following:

1 use another encryption

2 store the password in plaintext (dumb idea yeah i know but would allow him to use the md5'd anyway and be able to restore old passwords.)

3 as i suggested let people reset their password

 

Dont be fooled about thinking these encryption methods are the total security sollution

(they are save on server side).

But unless your using a SSL connection or you are encrypting the password on client side before sending.

U are still sending your password in plaintext from client towards server

(and yes that includes the passwords filled into password tagged input fields of html forms that show up as dots )

These packets can be sniffed out by people with bad intentions, and make any server sided encryption useless.

 

i think there might be javascript written scripts to encrypt passwords at client side, but im not sure about it.

[PFMaBiSmAd]

http://pajhome.org.uk/crypt/md5/

 

The problem with producing the hash in the client and sending it is that your script is expecting the hash as input and if someone is monitoring data packets, they have the hash your script is expecting and can simply supply that to log in. This does protect the actual password but does not provide any log in security.

[PFMaBiSmAd]

Edit to the above: I do recall seeing a method using a "seed" that is changed on every page generation so that the hash produced in the client is different each time and could only be produced if you know the password and have the current "seed" value.

[corbin]

Couldn't the seed value be intercepted too?  I guess no one would be that determined though.

[PFMaBiSmAd]

If the one-use hash that is expected is produced using the seed and the password, if you don't know the password and you only have one chance at producing the right hash per seed, having the seed is of no concern (assuming there is bad password attempt checking and account lock-out.)

 

Also, to clarify, the seed is produced on the server and sent to the client.

[Silverado_NL]

maybe combine the encrypted password with the senders ip address so it will only be accepted when comming from client?(not sure if this will work).

[corbin]

Ahhhh yeah, I was thinking of it the wrong way.  But couldn't the same seed be used later on, since the seeded password would have to be stored somewhere?

[PFMaBiSmAd]

The person most likely to be monitoring data packets is someone on the same hardwired local network or unencrypted wireless network. In which case, they would have the same IP address as the actual visitor and could not be distinguished from the actual visitor.

[PFMaBiSmAd]

The seed would be a random hash itself. Unlikely to be repeated or guessed.

[corbin]

Wait....  You aren't thinking md5 anymore, are you?  I was thinking salt, and then I realized that you probably mean seed in an encryption algorithm, not a salt in a digest algorithm.

 

 

I was thinking that the person sniffing packets would still know the password that would be stored on the server, and he would still know the salt, so he would know everything needed.  (Since the md5'd password/salt would have to be stored as such since the md5'ing couldn't be reversed.)

 

 

A reversible algorithm makes much more sense with that ;p.

[Silverado_NL]

The person most likely to be monitoring data packets is someone on the same hardwired local network or unencrypted wireless network. In which case, they would have the same IP address as the actual visitor and could not be distinguished from the actual visitor.

 

meh i give up,i would just purchase a SSL then.

trying to solve security issues can really make your head go OUCH!

btw PFMaBiSmAd are u the ONE they used to call barand?

 

[Silverado_NL]

sry somehow double posted

[corbin]

Uhhhhh....

 

 

Barand is/was Barand.

 

http://www.phpfreaks.com/forums/index.php?action=profile;u=3113

[Silverado_NL]

eek nevermind, the little avatar confused me:P

[PFMaBiSmAd]

That's not the first time someone has asked that. PFMaBiSmAd != Barand

 

------

This seed/client side hash method would require that the username be sent to the server first (AJAX) so that the MD5 of the password could be retrieved from the user table and the seed could be produced and sent to the client (AJAX) to be able calculate and store what the expected hash from the client will be.

 

Server side -

 

// client sends username to server

$md5_of_password = ; // retrieve from user table

$seed = md5(uniqid(rand(), true)); // sent to client

$expected_hash = md5($md5_of_password . $seed);

 

Client side -

 

md5_of_entered_password = md5(entered_value);

produced_hash = md5(md5_of_entered_password + seed_from_server);

[corbin]

Ahhhhh ok.  I get it now!  Today and last night have been slow days x.x.

 

 

So the first seed ever used would have to be used every time, and another salt just tacked on?

 

 

Edit:  By salt tacked on, I mean that that salt would be passed to the client later.

[PFMaBiSmAd]

In case someone wants to experiment with the client side hash being discussed, here is some demo code (uses the md5.js file from the link posted above in this thread) -

 

<?php
// demo of client side password hash using random seed from server
// a one-use seed is generated per form, per username
session_start(); // the expected hash value is passed in a session variable
// At this point a form with username has been submitted, simulate md5 hash of password from user table -
$md5_of_password = md5('pwd'); // get md5 of dummy password for demo
$seed = md5(uniqid(rand(), true)); // produce seed - to be sent to client
$_SESSION['expected_hash'] = md5($md5_of_password . $seed); // expected hash value that will be received from client
//echo "Expected: {$_SESSION['expected_hash']}<br />"; // debugging information
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<script type="text/javascript" src="md5.js"></script>
<script type="text/javascript">
function notEmpty(elem, helperMsg){
if(elem.value.length == 0){
	alert(helperMsg);
	elem.focus();
	return false;
}
return true;
}

function hash_pwd()
{
var pwd = document.getElementById('password');
if (notEmpty(pwd,'Please Enter a Password') == false){
	return false;
}
var val = pwd.value;
var seed = '<?php echo $seed; ?>';
var produced_hash = hex_md5(hex_md5(val) + seed);
// alert('Expected: ' + produced_hash); // debugging information
document.getElementById('hash').value = produced_hash; // set the form field
return true;
}
</script>
<title>Client side password hash demo</title>
</head>
<body>
<form method="post" action="formaction.php" onsubmit="return hash_pwd()">
<div>
Password: <input type="text" id="password" size="30">
<input type="hidden" name="hash" id="hash">
<input type="submit" name="submit" value="Submit">
</div>
</form>
</body>
</html>

 

The form processing code for that above would be like this -

 

<?php
session_start();
if(isset($_POST['submit'])){
if(!empty($_SESSION['expected_hash']) && $_SESSION['expected_hash'] == $_POST['hash']){
	// submitted hash is same as expected hash
	echo "Same<br />";
} else {
	// no match
	echo "Wrong password<br />";
}
}
unset($_SESSION['expected_hash']); // only use one time
?>

[Silverado_NL]

In case someone wants to experiment with the client side hash being discussed, here is some demo code

oh that's awesome code, thank you.

this is stuff even i can understand.

just what i was looking for, cause i still dont know ANY javascript, so i didnt know where to begin:P

 

many thx