SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Addict fattyjules's Avatar
    Join Date
    Dec 2005
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why bother storing hashed passwords in the database?

    Not storing passwords in plaintext is pretty much standard practice. The logic behind it is that if a bad guy gets his hands on your database, the amount of damage he can do is limited.

    However, if he has all the password hashes, can't he impersonate any user he wants, e.g. save hash in a cookie? How is that better than just having the password?

    (I've just thought of one answer to my own question - while the attacker could sign in as a user, he couldn't change the password, assuming the 'change password' function requires the old password. If anyone has any other reasons, please let me know!)

  2. #2
    SitePoint Enthusiast
    Join Date
    Sep 2008
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It depends on the security model you've implemented what the bad person can do. If, for example, you've got a "remember me" function that depends on the password hash in a cookie, then you're right, the bad person can impersonate anyone.
    Teun Hoogendoorn
    ATSC
    LinkedIn
    Blog

  3. #3
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Yet...what are you doing storing the password, even the hash inside of a cookie? When storing passwords don't just hash them, you should be salting them making rainbow tables ineffective.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  4. #4
    SitePoint Addict fattyjules's Avatar
    Join Date
    Dec 2005
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know if this is known technique, but what if you store a hash of the username AND password, e.g. sha1($username.$password)?

    That way, weak passwords won't be exposed if the hashes are obtained - the username acts as per-record salt.

  5. #5
    Your Lord and Master, Foamy gold trophy Hierophant's Avatar
    Join Date
    Aug 1999
    Location
    Lancaster, Ca. USA
    Posts
    12,305
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fattyjules View Post
    However, if he has all the password hashes, can't he impersonate any user he wants, e.g. save hash in a cookie? How is that better than just having the password?
    If the cookie hash is different from what is stored in the database then they couldn't do this. vBulletin does something like this...

    The hash in the database is stored as md5(md5($password).salt).

    The hash in the cookie is roughly stored as md5($passwordhash.sitekey). Each and every license has a different sitekey. To recreate the cookie hash, not only would they need your database but they would need your vBulletin files. Still not 100% foolproof but makes impersonation a lot less likely.

    To prevent man in the middle attacks, all javascript enabled browsers (read over 90% of them) should send the password to the server as md5($password) so the plain text password is never sent. Theoretically the salt is unique per registration but there is really no collision detection on them. Its mainly to prevent the hash at site A being the same as the hash at site B if the user uses the same password at both places. Or implement SSL for sign-ins.

    I am sure other software packages have similar hashing schemes to keep passwords safe. Of course if you want to be 100% safe then implement RSA Security Tokens along with passwords like the banks do.
    Wayne Luke
    ------------


  6. #6
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here was rather long discussion on how and why multiple hashing of passwords is good idea compared to storing passwords in plaintext:
    Double Hashing Passwords for Extra Security.

  7. #7
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hierophant View Post
    If the cookie hash is different from what is stored in the database then they couldn't do this. vBulletin does something like this...

    The hash in the database is stored as md5(md5($password).salt).

    The hash in the cookie is roughly stored as md5($passwordhash.sitekey). Each and every license has a different sitekey. To recreate the cookie hash, not only would they need your database but they would need your vBulletin files. Still not 100% foolproof but makes impersonation a lot less likely.
    Either way, do not store the password in any form in a cookie. Just don't do it. Instead create a token for that user's cookie.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.



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
  •