I am trying to hash a password but I am not sure I understand sha-1

Hello,

I am trying to take a password from a form field and compare it to the hashed equiv. in the db.

Now, the part that confuses me is that, does php hash it for you or do I have to say in php,

$pass = ‘1234’;

then hash $pass;

if not, how do I say to hash the password in the db.

I did this originally

$passwordHash = sha1($_POST[‘mypassword’]);

but I am not sure that this is doing what I am trying to do. LOL

confused yet?

thanks for any help or advice on this,

Paul

You still need to do that.

i Assume you saved the pass hashed in your db. so


SELECT user, pass
FROM tblUsers
WHERE user = '$user' AND pass = 'pass'

Run a query on that. Then


$query = //see above;
$result = mysql_query($query);
if(mysql_num_rows($result) == 1){
  // yay logged in
 // do stuff
}Else{  // aka mysql_num_rows() !== 1
 //do stuff saying log in failed
}

If the stored password is a sha1 hash as you say, then you can hash the incoming password in PHP first OR do it as part of the select query (but not both together)


$hash = sha1($_POST['mypassword']);
$query = "SELECT username FROM users WHERE username='$username' AND password='$hash'";

// OR
$pw = mysql_real_escape_string($_POST['mypassword']);
$query = "SELECT username FROM users WHERE username='$username' AND sha1('$pw')=password";

Thanks everyone for your input, I think I understand how this work now.

Mike, I have one question on your post though,

That 1st script that you layed out where php will hash the incoming password,

will that run on it’s own or will I need to tell php somwhere to say… oh by the way… do this…

just wondering … thanks,

Paul

If this is for a production system, you should find a library to do the password security for you. Your customers don’t want your guesses as to how to do passwords, and there are tons of free options out there which will provide more robust security options.

If this is for your own learning, or perhaps a school project, some recommendations:

Append a salt to the password. See below:


$hash = sha1($_POST["password] . "salt");

Adding salt makes the passwords more difficult to guess. Ideally, you should be randomly generating a salt and storing that in the database with the password.

Also, I’m kind of beating a broken drum, but steer clear of sha1. There are tons of slower, larger algorithms (both of which are better in terms of password security) than sha1. I personally prefer Whirlpool, which is available by default in PHP as well.

Thanks mike for the advice on this,

This was a project for work that turned into me learning more about php. So kind of column a and column b to your answer above.

They wanted the site to have a secure login but no registration for the user. We would create the user and pass for people to use.

When I started doing this, I did all plain text passwords in the db but then was reading how I should be securing that somehow.

Back to my situation though, I have another question.

I should put the sha1psss with salt in the db?

if I do that code that you said above, nothing really happens, I was expecting to get a cannot log in message after I added that to my code.

Thanks again for your help,

Paul

yes, when you make an user:


<input name='user'>
<input name='pass'>
...
<?php
$user = mysql_real_escape_string($_POST['user']);
$pass = sha1(mysql_real_escape_string($_POST['pass']));

// establish a mysql connection
$newUserQuery = 'INSERT INTO tblUser (username,userpass) VALUES ($user,$pass);
$results = mysql_query($newUserQuery);

if (!$result) {
    $message  = 'Invalid query: ' . mysql_error() . "\
";
    $message .= 'Whole query: ' . $newUserQuery;
    die($message);
}

There are two values you should save in the DB

$hash

and

"salt"

.

Like I said, the salt should be randomly generated for every user. When you go to log a user in, you should retrieve the salt for that user from the database, and then use it as part of the hashing process of the entered password. You then compare the hash of the password the user just entered to the one that you’ve saved in the DB, and if they’re the same, then you permit the user to continue. Does that make sense?

Hashing a password basically is there to prevent someone with direct access to the database from being able to tell what people’s passwords are. It has very little to do with the security that the passwording itself provides since about the only people with easy access to view the data in the database are the staff at the datacentre where the server is located.

The actual security of the password when accessing via a web browser is completely independent of how the password is stored in the database as from outside the server the only way to get into the database in order to see a password stored in plain text is if they know or can obtain a username and password to log into your account. If they can do that then your entire hosting is compromised and not just the passwords.

Mike, I have one question on your post though,

That 1st script that you layed out where php will hash the incoming password,

will that run on it’s own or will I need to tell php somwhere to say… oh by the way… do this…

Nothing happens automatically. If you don’t call sha1() then $_POST[‘mypassword’] will be whatever the user typed in directly. Since you’re storing hashes you need to compare hashes.

Regarding salts, yes they are a good idea, but not sure they are really necessary in this situation. If you want to keep learning, feel free.
The purpose of a salt is to make a rainbow, or lookup table useless (search for this term to find out what a rainbow table is) in case someone bad ever got access to your hashes.

And you probably know, but I’ll mention anyway that without SSL the password the user types is transmitted in plain text over the internet, until it gets to your server and is hashed and compared. From a security perspective it’s more likely someone would sniff a password on a public network, than break into your DB and read your data.

You would be 100% right in your post, except you blatantly ignore SQL injection. Not recommending that someone do something so simple as hashing and salting their passwords to protect their users is neglectful, to say the least.

But, and this is the bigger issue: why wouldn’t you recommend that he do it the right way? Why make someone who has admitted they don’t really understand security guess as to how to implement it in the future? I really don’t understand this attitude in the PHP community. “It’ll take me an extra hour to make sure that I do passwording right the first time, eh, I’ll just skip it and maybe do it better next time”. Three years later, when you didn’t ever “do it right the next time”, and you have to tell all your users to change their passwords everywhere, do you ever sit back and think “Was it worth it”?

Then you have much bigger problems. Which is currently irrelevant to this discussion since hashing a password would not solve SQL injection. That is a whole other issue.

Technically, a sha1 string can not contain quotes, so doesn’t need escaped… but whatever.

Since it is irrelevant to hashing it was appropriate to ignore it.

I wasn’t saying that hashing a password isn’t an appropriate thing to do, I was just pointing out the rather limited area in which it serves a purpose.

Probably the most useful purpose if storing a salted hash of the password rather than the password or an unsalted hash is that you cover yourself against possible accusations of having yourself used someone’s password to access their account on another site where they use the same password. Using a salted hash means that not only can’t you see what their password is but even the hashed value will be different from the hash on the other site. So even staff in a computer centre would be unable to tell if a person having logins on two separate systems hosted there is using the same password for both .

There are far more important things relating to password security that hashing though. Probably the most important is the requirement for the password to contain an appropriate mix of different types of characters si as to prevent dictionary attacks. Some means of temporarily locking an account after wrong passwords are entered is also useful.

Also if you use Prepare statements for all the SQL calls then you make database injection extremely difficult even without adding any extra code to test for it.

SQL Injection is a legitimate concern in response to your statement that “the only way someone can get the list of your passwords is if they have credentials to your database”. I was simply pointing out the inherent falseness in that statement.

The bigger question, and the one you didn’t address, however is this: why ask someone who is admittedly new to make judgment calls on what security is needed in their application? The OP has already noted that he’s still trying to figure this stuff out, why wouldn’t you teach him how to do it right, all the way, the first time.

To use a bad analogy, it’s like (and yes, I know, this is stretching it) handing someone the keys to your car, teaching them how to use the transmission, steering wheel and pedals, and then sending them off down the road saying “Eh, the driving laws are kind of important, but it would take a while to learn those, and most of them probably don’t matter most of the time”.

There’s a lot of insecure PHP being written these days, still. Tons of stuff that we figured out the answer to years ago is still going into production without the author knowing any better. Threads like this one are like threads where someone asks for help with a SQL Query, and no one explains to them how putting unfiltered input into non-parameterized queries is a bad idea. They’re negligent.