www.webdeveloper.com
Results 1 to 10 of 10

Thread: How to compare password to encrypted password?

  1. #1
    Join Date
    Nov 2013
    Posts
    72

    How to compare password to encrypted password?

    I have been working on a website, (one of my first) and I have ran into a problem with the passwords. I found the below code to encrypt a password, which is what gets stored in the data base. I assumed that when the user enters his or her username and password, I could simply grab the password, do the same thing with it, compare that with what is in the database and it would be the same encrypted string, but it is not.

    How can I do this? I don't have to use the code below to encrypt the password. I am sure there are many ways.


    PHP Code:
               $cost 10;
               
    $salt strtr(base64_encode(mcrypt_create_iv(16MCRYPT_DEV_URANDOM)), '+''.');
               
    $salt sprintf("$2a$%02d$"$cost) . $salt;
               
    $password crypt($password$salt); 

  2. #2
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,247
    I think you'll need to store the salt in the DB, too. Otherwise with that code the salt will be randomly generated each time, which will then cause the encryption results to be different.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  3. #3
    Join Date
    Nov 2013
    Posts
    72
    That makes perfect sense after you pointed it out. I didn't think about the MCRYPT_DEV_URANDOM part of the algorithm.

    Is there a better way to do that? It seems that storing the salt would make it much easier for someone to crack the passwords if they get access to the database. Not that I am storing anything that is sensitive but I would like to do it right.

  4. #4
    Join Date
    Nov 2013
    Posts
    33
    personally i don't use a set salt or "random salt" instead I use a row that holds unchangeable data (such as signup date) of the user signup and use 128 bit encryption with the whirlpool algorithm.
    Code:
    $salt = strtotime(date('Y-m-d h:i:s')); //the users signup date taken from database
    $password = hash('whirlpool', $salt.'users desired password');  // this will give you a 128 character long hashed password.
    by using an arbitrary row from the database any hack attempt that get hold of you password would not know what the salt key would be.

  5. #5
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,247
    The main purpose of using a salt is so that a cracker cannot simply use a pre-generated "rainbow table" of hashed passwords to search against with the hashed values in your DB. By using a different salt on each password, they would now have to regenerate a new rainbow table for each such salt - and do it twice if they have to guess whether it's being added to the beginning or the end. The best security practice is still to get/force the users to use very strong passwords. ("E5-tc!2_xM34-" is not going to appear in many rainbow tables. )
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  6. #6
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,247
    Quote Originally Posted by unasAquila View Post
    personally i don't use a set salt or "random salt" instead I use a row that holds unchangeable data (such as signup date) of the user signup and use 128 bit encryption with the whirlpool algorithm.
    Code:
    $salt = strtotime(date('Y-m-d h:i:s')); //the users signup date taken from database
    $password = hash('whirlpool', $salt.'users desired password');  // this will give you a 128 character long hashed password.
    by using an arbitrary row from the database any hack attempt that get hold of you password would not know what the salt key would be.
    Another decent option. It's all about defense in layers: the more hoops you make a cracker jump through, the more likely it is he'll look for easier pickings -- unless you have "heroin content" that he just has to have.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  7. #7
    Join Date
    Nov 2013
    Location
    North West England, UK
    Posts
    5
    This whole area is very difficult to implement correctly without having a very good understanding of cryptography. I recently wrote a user management area in PHP and when I started researching this properly, I came to the conclusion that implementing this is not that straightforward.

    The solution I ended up with is Openwall's Portable PHP Password Hashing Framework. This is e.g. what Wordpress (and many other projects) use for storing passwords, and makes the job very easy. Personally I would highly recommend anyone to use this instead of trying to come up with your own solution using PHP's encryption functions, because unless you have a very, very good understanding of encryption in this context, it's easy to get the implementation wrong.

  8. #8
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Since PHP 5.5, there are built-in password hashing functions that do things the right way. And if you're not on 5.5, then you can use this forward compatibility library.

    This is probably your best option right now.
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  9. #9
    Join Date
    Nov 2013
    Location
    North West England, UK
    Posts
    5
    Quote Originally Posted by Jeff Mott View Post
    Since PHP 5.5, there are built-in password hashing functions that do things the right way. And if you're not on 5.5, then you can use this forward compatibility library.

    This is probably your best option right now.
    I hadn't hear about that, that's an excellent move by PHP, sorely needed.

    Hmm, personally I think I'll still keep using Openwall's Portable PHP Password Hashing Framework for a while though, since it's mature. I'll wait until PHP 5.5 is more widely used and further stabalised and then start using the new built in functions for new projects, as they are definitely the way to go ultimately.

  10. #10
    Join Date
    Nov 2013
    Posts
    72
    Quote Originally Posted by Jeff Mott View Post
    Since PHP 5.5, there are built-in password hashing functions that do things the right way. And if you're not on 5.5, then you can use this forward compatibility library.

    This is probably your best option right now.
    That is a great solution. Thanks!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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



Recent Articles