password encryption

[wsproperties]

Using php admin (server side) I have the following code

insert into admin values ('','Smith','smith_gr ',password('tlc84')) ;

I have done this several times. I general get the name and an encrypted password resembling a hexidecimal numeric sequence. Now I get a long number like this *EAA2EB17BB18979A5D3824AC. The password will not work when I access it. In addition, if I want to encrypt using a particular ID would the code be something like this

insert into admin values ('','Smith','smith_gr ',password('tlc84')) where id = 146;

 

[vacunita]

This is a mysql question, and has nothing to do with PHP. password is a mysql function. So try asking the question in forum436

Password() function entry in the MYSQL online manual:

http://dev.mysql.com/doc/refman/6.0/en/encryption-functions.html#function_password

----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[jpadie]

do NOT use the mysql password function to encrypt web passwords. that is not what it is there for.

use md5 sha1 or whatever, preferably with a salt. or some other form of complex one-way hash algorithm.

 

[MichealC4]

First off, I'm guessing you want to hash instead of encrypt? Hashing is one-way, and is what the majority of web applications do to protect passwords. As jpadie pointed out, you'll want to use MD5, SHA1 (or any of the other SHA family members), with a salt. Preferably with a unique salt for each password.

----------------------------
"Will work for bandwidth" - Thinkgeek T-shirt

 

[wsproperties]

I have not used this before. Using my example how would I set code this? Can I get an example

 

[jpadie]

insert into admin values ('','Smith','smith_gr ',sha1('tlc84')) ;

or as a salted version

$salt = '^&$%(£()!';
$query = "
insert into admin values (NULL, 'Smith', 'smith_gr', sha1('smith_gr_tlc84_$salt')";

here the salt is part static, part dynamic. the dynamic part of the salt is created by the userID of the user. this must, of course, be unchangeable by the user (or you will have to provide a way for the password to be regenerated on change of user name).

the key thing is that it is a 'bad thing' for a website to capture unhashed passwords.

it is also a bad thing for the password to be sent unhashed. i would recommend taking the above one step further an using javascript to combing the user name and password, and hash it before sending it. you would then add a salt and rehash it before storing it in the database. this way the website (nor any man-in-the-middle) will never know the user's actual password (always assuming the absence of a brute force unhash).

 

[MichealC4]

I agree with jpadie up until the recommendation of using JavaScript where I have to respectfully disagree. If you don't want the password sent in the clear, use SSL. That's what it is for. Using JavaScript, while "neat," causes problems. For example, what if a user disables JavaScript? I do by default until I know I can trust a website, then I enable it for that website alone. What about users that don't have JavaScript at all? In security, we have a saying that goes like this: "Never trust the client." That's what JavaScript for password hashing is doing, trusting the client.

Incidentally, it is not possible to unhash. A hash is a one-way function. It is possible to find the equivalent using brute force, but it is not possible to reverse the hash.

----------------------------
"Will work for bandwidth" - Thinkgeek T-shirt

 

[ingresman]

Incidentally, it is not possible to unhash. A hash is a one-way function. It is possible to find the equivalent using brute force, but it is not possible to reverse the hash.

Totaly agree, as a hash function can return the same value for more than one set of input (hence overflow in hash files)

 

[jpadie]

unhash was used figuratively.

ssl is not available for a large proportion of small sites that sit on shared servers.

js is an adequate solution. the workaround for non-js browsers is simply to allow those passwords to come through unhashed. It is the user's own choice to reduce his security (obviously this should be made clear in the user terms and conditions). a flag can be set in the form (by js) that will tell the receiving script how to interpret the incoming data.

consider this as pseudo code as i'm not at all strong on js.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"[URL unfurl="true"]http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">[/URL]
<html xmlns="[URL unfurl="true"]http://www.w3.org/1999/xhtml">[/URL]
<head>
	<script type="text/javascript">
		var done = false;
		function init(){
			document.getElementById('nonJSWarning').style.display = 'none';
			document.getElementById('js').value = "1";
			focusit();
		}
		function focusit() {
			document.getElementById('user_login').focus();
		}
		function hashMe(f){
			if (!done) {
				var p;
				p = sha1(f.user_login.value + "_" + f.user_pass.value);
				f.user_pass.value = p;
				done = true;
			}
			return true;
		}
		function sha1(v){
			return v;
			//abstract from the reference hash library
		}
		function undone(c){
			if (done){
				c.value = '';
				done=false;
			}
		}
		window.onload = init;
	</script>
	<script src="somehashlibrary.js" type="text/javascript" />
</head>
<body class="login">

<form name="loginform" id="loginform" action="index.php" method="post" onsubmit="return (hashMe(this));">
	<p>
		<label>Username<br />
		<input type="text" name="user_login" id="user_login" class="input" value="" size="20" tabindex="10" /></label>
	</p>
	<p>
		<label>Password<br />
		<input type="text" name="user_pass" id="user_pass" class="input" value="" size="20" tabindex="20" onfocus="undone(this);"/></label>
		<p id="nonJSWarning">
			You have turned off javascript. This will reduce the functionality and security of this site.
		</p>
	</p>
	<p class="submit">
		<input type="submit" name="submit" id="submit" value="Log In" tabindex="100" />
		<input type="hidden" name="js" id="js" value="0" />
	</p>

</form>


</body>
</html>

 

[Ruggie]

I agree with TechieMicheal about the JavaScript thing, a lot of the programming I do is viewed by hospital networks, most of them use proxy servers to strip any kind of client-side script tags. You can never trust the client to handle key operations. My login pages are all on the SSL side of the server.

As for the rest of what jpadie said, I completely agree, salting a hash is very important to prevent against rainbow attacks.

Also don't forget to clean the input data before placing it into the SQL query, don't rely on magic_quotes because it doesn't always work the way you expect it to!