Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 48

Thread: How do you retrieve a hashed password?

  1. #31
    Join Date
    Jan 2007
    Location
    Davenport, Iowa
    Posts
    1,711
    Thanks
    82
    Thanked 90 Times in 88 Posts

    Default

    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.
    Last edited by james438; 01-31-2013 at 02:40 AM.
    To choose the lesser of two evils is still to choose evil. My personal site

  2. #32
    Join Date
    Apr 2008
    Location
    So.Cal
    Posts
    3,643
    Thanks
    63
    Thanked 517 Times in 503 Posts
    Blog Entries
    5

    Default

    Quote Originally Posted by james438 View Post
    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.

    Quote Originally Posted by james438 View Post
    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.

    Quote Originally Posted by james438 View Post
    I don't see any reason to encrypt a member's username.
    no.

    Quote Originally Posted by james438 View Post
    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.

  3. #33
    Join Date
    Jan 2007
    Location
    Davenport, Iowa
    Posts
    1,711
    Thanks
    82
    Thanked 90 Times in 88 Posts

    Default

    Quote Originally Posted by traq View Post
    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.
    To choose the lesser of two evils is still to choose evil. My personal site

  4. #34
    Join Date
    Mar 2006
    Location
    Illinois, USA
    Posts
    12,162
    Thanks
    263
    Thanked 690 Times in 678 Posts

    Default

    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).
    Daniel - Freelance Web Design | <?php?> | <html>| español | Deutsch | italiano | português | català | un peu de français | some knowledge of several other languages: I can sometimes help translate here on DD | Linguistics Forum

  5. #35
    Join Date
    Jan 2007
    Location
    Davenport, Iowa
    Posts
    1,711
    Thanks
    82
    Thanked 90 Times in 88 Posts

    Default

    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.
    To choose the lesser of two evils is still to choose evil. My personal site

  6. #36
    Join Date
    Mar 2006
    Location
    Illinois, USA
    Posts
    12,162
    Thanks
    263
    Thanked 690 Times in 678 Posts

    Default

    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...
    Daniel - Freelance Web Design | <?php?> | <html>| español | Deutsch | italiano | português | català | un peu de français | some knowledge of several other languages: I can sometimes help translate here on DD | Linguistics Forum

  7. #37
    Join Date
    Jan 2007
    Location
    Davenport, Iowa
    Posts
    1,711
    Thanks
    82
    Thanked 90 Times in 88 Posts

    Default

    Quote Originally Posted by djr33 View Post
    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 .
    To choose the lesser of two evils is still to choose evil. My personal site

  8. #38
    Join Date
    Mar 2006
    Location
    Illinois, USA
    Posts
    12,162
    Thanks
    263
    Thanked 690 Times in 678 Posts

    Default

    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.
    Daniel - Freelance Web Design | <?php?> | <html>| español | Deutsch | italiano | português | català | un peu de français | some knowledge of several other languages: I can sometimes help translate here on DD | Linguistics Forum

  9. #39
    Join Date
    Apr 2008
    Location
    So.Cal
    Posts
    3,643
    Thanks
    63
    Thanked 517 Times in 503 Posts
    Blog Entries
    5

    Default

    ...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.

  10. #40
    Join Date
    Jan 2007
    Location
    Davenport, Iowa
    Posts
    1,711
    Thanks
    82
    Thanked 90 Times in 88 Posts

    Default

    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.
    To choose the lesser of two evils is still to choose evil. My personal site

Similar Threads

  1. Replies: 4
    Last Post: 01-24-2011, 10:57 AM
  2. Replies: 4
    Last Post: 03-04-2009, 02:36 PM
  3. Replies: 2
    Last Post: 07-01-2008, 11:47 AM
  4. how to retrieve
    By jr_yeo in forum PHP
    Replies: 6
    Last Post: 08-17-2007, 11:18 PM
  5. retrieve files
    By sukanya.paul in forum PHP
    Replies: 2
    Last Post: 04-24-2007, 02:14 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •