How do you retrieve a hashed password?

[james438]

Update:

database: The password is stored in the database hashed and salted with crypt with two characters removed. The username is stored in plain text as well as their ip address.

Cookies: When the member logs in their username is stored in a cookie in plain text. The password is stored in a separate cookie, which is a crypted, salted, combined with the user's ip address, and then has two characters removed. Both cookies need to be correct. The password one is tied to the user's ip address. If a user logs in on a different computer with a different ip address then the cookie on the first computer will no longer be valid.

I don't see any reason to encrypt a member's username.

Question: When a person registers their username an email is sent which tells them what their username and password is. How do you use email confirmation?

Note: If I manually alter a cookie (you can do this quite easily with the Opera browser) so that the the username is a valid username, but the password is one that is used by someone else the user can still post just fine. I'll need to correct this. If you try to log in with a correct username and someone else's password you won't be logged in. The cookie has to be modified manually in order to do this.

[traq]

database: The password is stored in the database hashed and salted with crypt with two characters removed. The username is stored in plain text as well as their ip address.

cool.

Cookies: When the member logs in their username is stored in a cookie in plain text. The password is stored in a separate cookie, which is a crypted, salted, combined with the user's ip address, and then has two characters removed. Both cookies need to be correct. The password one is tied to the user's ip address. If a user logs in on a different computer with a different ip address then the cookie on the first computer will no longer be valid.

Is this the same hash that you store in the DB?

If so, create it some other way. You shouldn't be handing that out.

There's really no reason for a second cookie anyway. It doesn't add any security, because if one cookie is compromised, then it's likely *all* cookies were compromised.

Check the password when the user logs in, then forget about it. All you need for page-to-page visits is to remember that they did log in, and you can do that with $_SESSION['is_logged_in'] or similar. Don't worry about verifying their identity again unless they're about to do something sensitive, and then, simply ask them to give their password again.

I don't see any reason to encrypt a member's username.

no.

Question: When a person registers their username an email is sent which tells them what their username and password is. How do you use email confirmation?

Don't send them their password. Two approaches:

1) they choose a password when they register, and have to remember what it was.

2) they choose a password afterwards - when you send them their email confirmation, include a "first-time" log in link (exactly the same as if they'd clicked on "I forgot my password", like we discussed earlier). Then, they choose a password for themselves.

[james438]

Is this the same hash that you store in the DB?

I am happy to say it is not . Or rather it is the same one from the database, but that hashed password is first salted, encrypted with the ip address, and has two characters removed so that the hash stored in the cookie is not the same as the one in the database.

Thanks for the feedback! It sounds like I am on the right track . I use method 1 currently, but I can't help but wonder if method 2 is better.

I was trying to remember why I even have the member's username stored in a cookie then I remembered that it is used to remember the theme he is using for the site whether it be one of the premade one's or one he designed himself. It really is not needed. I'll try to combine the two cookies, but not right away, because there are several files I need to go through. Not a big deal.

I should add that I use cookies as opposed to sessions. A long time ago I recall that I had trouble getting the session to last past the restart of a user's computer. I want users to be able to stay logged in without having to log back in every day or every moth even. I have always found it annoying to have have to log back into a site multiple times a day and don't wan that for my site. I would prefer to counter that with other measures such as limiting the number of articles a user can post in a 24 hour period, limit the number of registered users per ip address, etc. I also sanitize my sql queries. I have several other security measures in place as well.

[djr33]

I agree with what traq said. Not much to add, but--

database: The password is stored in the database hashed and salted with crypt with two characters removed. The username is stored in plain text as well as their ip address.

Removing two characters seems bad to me. If you have a 32 character hash, then you have 16^32 possibilities. If you have removed two characters, then you have 16^30 possibilities, which is significantly smaller. (The former has 256 times more many possibilities than the latter.)
Sure, 16^30 is still a huge number. But this means that any password that has a hash that has the same first 30 digits, regardless of the last 2, will count as the right password. That makes it a lot easier to hack with brute force.

Instead of removing any characters, I'd suggest doing some other kind of manipulation, perhaps reversing the string of the hash, or switching several characters, etc. Or, if the hash algorithm by itself is strong enough (in a way that MD5 is not), then you may not need to do anything (except that salt is always a good idea).

[james438]

I took your advice to heart and stopped shortening the hash by two characters and have instead switched several characters. This was complicated because I then had to create a password reset script using email confirmation for the people that have registered on my site. I've been at it the last few days and I have just finished writing it. At least I can't seem to find any more bugs. I do still need to update my site so that the salt can be changed with one file edit instead of about 6. I also need to add some notation to the password reset script.

On a different aspect of security, is it much of a security risk to let users register their username, email, and password and be instantly logged in (usernames and passwords must still be unique) or would it be better to sacrifice a little convenience for increased security by requiring the member to confirm their registration via email?

The reason I removed the first two letters from the encrypted passwords is because the first two letters were the salt letters. That seemed a bit of a security risk to me and I am a little puzzled as to why crypt() behaves that way. I certainly agree that removing the letters just made brute force a whole lot easier, which is why I put the two characters back and opted for moving some characters around instead.

[djr33]

I took your advice to heart and stopped shortening the hash by two characters and have instead switched several characters. This was complicated because I then had to create a password reset script using email confirmation for the people that have registered on my site. I've been at it the last few days and I have just finished writing it. At least I can't seem to find any more bugs. I do still need to update my site so that the salt can be changed with one file edit instead of about 6. I also need to add some notation to the password reset script.

It would actually be more work for you, but you could allow them to continue with the old passwords by using both algorithms based on a date stored somewhere in your database (or just a binary value of which password system they're using). You should recommend that they upgrade for security, but it would allow them to not need to redo everything. What you did is probably fine, though.

On a different aspect of security, is it much of a security risk to let users register their username, email, and password and be instantly logged in (usernames and passwords must still be unique) or would it be better to sacrifice a little convenience for increased security by requiring the member to confirm their registration via email?

There's no security issue at all*. It's just a matter of spam. Like several other measures you can take (eg, a CAPTCHA), requiring email verification will increase the difficulty for spammers.
(*At least there's none in theory. It's imaginable that a badly written script could do something odd like let them log in without an account if they can find some odd loophole.)
Also, usually sites require that you retype your password to actually log in. I'm not really sure why that is. It seems that as long as it's soon after registering, there's no real advantage there. Perhaps it's to be sure they don't forget the password (and they can store it in their browsers).

The reason I removed the first two letters from the encrypted passwords is because the first two letters were the salt letters. That seemed a bit of a security risk to me and I am a little puzzled as to why crypt() behaves that way. I certainly agree that removing the letters just made brute force a whole lot easier, which is why I put the two characters back and opted for moving some characters around instead.

They were always the same output? In that case they don't add much security. But there shouldn't be any recognizable relationship between character-location in the string and the input string...

[james438]

They were always the same output? In that case they don't add much security. But there shouldn't be any recognizable relationship between character-location in the string and the input string...

The first two characters of the hash were always the salt characters used. I tried this several times. It was a little confusing why this would be and a little annoying too. I figure it should be fine if the hash characters are rearranged a little.

As far as the registration part I can see spam as a potential issue, but I suppose it is fine for now. I can work out various anti-spam measures later when spam becomes more of an issue.

I'm going to mark this as resolved now .

[djr33]

As you've seen, updating a password hash algorithm can be problematic, but updating anti-spam measures can be done at any time (including a verify-by-email requirement). Sounds fine to me.

Not sure about the salt issue though-- maybe traq does.

[traq]

...convenience?

I dunno. It's not necessarily a security risk, though - the salt isn't a decryption key, it's just extra entropy for the hash algorithm. And you have to store it somewhere, and it's typically stored close to the hash (in the same DB) anyway.

[james438]

If you are interested would either of you be willing to register on my site here: http://www.animeviews.com/loginuser.php and then log out. Pretend that you can't remember your password and try resetting it? It works ok when I try it,but I want to be sure that it is working. I can delete your account afterwards if you want.