#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2012
    Posts
    8
    Rep Power
    0

    Question Password encryption


    Hy 2 all,

    I have some questions about password security that I haven't been able to find an answer yet.
    Hopefully you guys know.

    Here it goes:

    1. Is it better to hash(sha2) the password and then salt it or salt it and than hash it ?
    2. I'm guessing that using a random salt is better than the same salt used for every password.
    3. How can you generate a different random salt for each password ? I mean how will the login page know which random salt to mix with the hashed user inserted password and then to compare it with the password stored in the db. (an example would be great(for both: generating and authentication)
    4. I saw some codes in which the salt and/or hash and/or password was split into two (ex: hash.salt1a.password.salt1b or password1a.salt.password1b or salt.hash1a.password.hash1b etc.) Is this a good idea ? Is it really more secure ? If so which would be more secure (splitting the password, the hash or the salt) ?
    5. Is double hashing (ex: (sha1(md5($password))) any good ?
    6. I've been reading something about password salt and pepper ?? What exactly is pepper ? Is it some sort of second salt ?

    If somebody could enlighten me about these questions, that would be great.

    Thanks in advance!
  2. #2
  3. Code Monkey V. 0.9
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Mar 2005
    Location
    A Land Down Under
    Posts
    2,101
    Rep Power
    1990
    Originally Posted by nameless.1
    1. Is it better to hash(sha2) the password and then salt it or salt it and than hash it ?
    Salt first, then hash. salting after hashing won't have any effect on the hash itself so there's no point doing any sort of salt after the fact.

    Originally Posted by nameless.1
    2. I'm guessing that using a random salt is better than the same salt used for every password.
    Yes.

    Originally Posted by nameless.1
    3. How can you generate a different random salt for each password ? I mean how will the login page know which random salt to mix with the hashed user inserted password and then to compare it with the password stored in the db. (an example would be great(for both: generating and authentication)
    I use a function that returns a string of random characters. That salt value is stored with the users record with the password. There's not a lot else that can be done because as soon as you generate a new salt value, your hashed password is no longer correct.

    Originally Posted by nameless.1
    4. I saw some codes in which the salt and/or hash and/or password was split into two (ex: hash.salt1a.password.salt1b or password1a.salt.password1b or salt.hash1a.password.hash1b etc.) Is this a good idea ? Is it really more secure ? If so which would be more secure (splitting the password, the hash or the salt) ?
    Yes, it's a very good idea. A lot of systems will use this so that in conjunction with the random salt that's stored for each user, there's also a system-wide salt value that's used as well. That way you need both values before the correct hash can be computed. As far as a difference between splitting the salt and splitting the password, I don't believe that it would make a great deal of difference as salting the password in the first place takes care of most of the issues of "insecure" passwords.

    Originally Posted by nameless.1
    5. Is double hashing (ex: (sha1(md5($password))) any good ?
    No. In some cases doing multiple hashes actually reduces the security of the hash value. Stick with doing it once through the most secure method that you have access to on your system.

    Originally Posted by nameless.1
    6. I've been reading something about password salt and pepper ?? What exactly is pepper ? Is it some sort of second salt ?
    I haven't heard of that before, but I'd think the same as you, it's just another terminology for using two salt values at the same time.
  4. #3
  5. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    13,997
    Rep Power
    9397
    Copied into Sec & Crypto. I was kinda hoping it would be a by-reference copy but it isn't
    [edit] This one should be moved there instead fairly soon... [/edit]


    4. A popular one is HMAC, which is roughly
    Code:
    hash(salt1 + hash(salt2 + value))
    6. "Pepper" tends to refer to a constant (but random) value defined for the entire system. While the salt gets stored alongside the hash the pepper is recorded somewhere else, and without both of them the hash can't be reversed into the/an original text.
    Last edited by requinix; April 30th, 2012 at 04:15 AM.
  6. #4
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2012
    Posts
    8
    Rep Power
    0
    Thanks guys for the HELPFUL answers.

    I just have a few follow up questions:

    Catacaustic

    I use a function that returns a string of random characters. That salt value is stored with the users record with the password. There's not a lot else that can be done because as soon as you generate a new salt value, your hashed password is no longer correct.
    So the random salt is stored with the password in the password column or do I need an extra column in the db table ?


    Yes, it's a very good idea. A lot of systems will use this so that in conjunction with the random salt that's stored for each user, there's also a system-wide salt value that's used as well. That way you need both values before the correct hash can be computed. As far as a difference between splitting the salt and splitting the password, I don't believe that it would make a great deal of difference as salting the password in the first place takes care of most of the issues of "insecure" passwords.
    So it's good to double salt it. So I do something like this: sha512($random_salt . $password . $system_wide_salt)

    Adding more than 2 salts would be useless or more secure ? (I mean something like 2 random salts and 2 system wide salts)

    Where does the system wide salt gets stored ?

    No. In some cases doing multiple hashes actually reduces the security of the hash value. Stick with doing it once through the most secure method that you have access to on your system.
    Does
    PHP Code:
    $password=sha1(sha1($password $salt) . $salt); 
    mean I'm double hashing ?



    requinix

    Isn't "pepper" some sort of system wide salt ?

    I've been reading a little about HMAC. But isn't it the same as hash + salt ? I mean isn't the $key from hmac some sort of $salt ?

    Wouldn't hash + random salt be safer ? or hash + salt + pepper (which is the same as the $key from hmac; a value stored somewhere else) ?
  8. #5
  9. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    13,997
    Rep Power
    9397
    Originally Posted by nameless.1
    Isn't "pepper" some sort of system wide salt ?
    As I know it, yes.

    Originally Posted by nameless.1
    I've been reading a little about HMAC. But isn't it the same as hash + salt ? I mean isn't the $key from hmac some sort of $salt ?
    A true HMAC is actually more involved than just adding a couple salts. Check the Wikipedia article for the real implementation. The jist of it is hashing a salted password, salting that, then hashing it again.

    Originally Posted by nameless.1
    Wouldn't hash + random salt be safer ? or hash + salt + pepper (which is the same as the $key from hmac; a value stored somewhere else) ?
    There's no point adding a salt to a hash and just leaving it as it is. Every hashing algorithm (that I know) has a fixed-length output: MD5 has 256 bits, SHA1 320, and so on. Concatenating more bits to that offers no additional security. To make it worth adding a salt you have to hash the result again.


    And I want to reply to one of the others too.

    Originally Posted by nameless.1
    So it's good to double salt it. So I do something like this: sha512($random_salt . $password . $system_wide_salt)
    No, it's good to use salt(s) over the whole algorithm. Using more than one at any single step is no better than using just one long salt.

    Originally Posted by nameless.1
    Adding more than 2 salts would be useless or more secure ? (I mean something like 2 random salts and 2 system wide salts)
    More secure, but at <2x the effectiveness of just one salt+pepper. If you're really concerned about security then you should invest more time in the algorithm itself and less in worrying about how many salts to throw at it.
    Cryptography is not as simple as "if this is good then doing it two times is twice as good". There's complicated stuff in there involving mathematics and number theory and other things I don't even know about. Don't try to come up with something yourself: find a well-known, agreed upon solution and implement that as it is.

    Originally Posted by nameless.1
    Where does the system wide salt gets stored ?
    Somewhere secure that's not with the database (ie, where the password hashes/salts are stored). A config file, for example.
    Last edited by requinix; April 30th, 2012 at 04:17 AM.
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2012
    Posts
    8
    Rep Power
    0
    THANKS for the info
  12. #7
  13. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    I've given up hashing passwords. too many clients want the ability to retrieve rather than reset forgotten passwords, so I salt and pepper the password and encrypt with mcrypt.

    The password is salted with the md5 of the user's UUID and the mcrypt key is (pepper) is the md5 of the domain name.

    I use the md5 values for salt and pepper as my implementation of mcrypt limts the key length to 32 chars
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  14. #8
  15. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    Forgive me in advance Northie, but I have to criticize you for that system.

    I've given up hashing passwords. too many clients want the ability to retrieve rather than reset forgotten passwords, so I salt and pepper the password and encrypt with mcrypt.
    You've given up implementing a secure system by default because you have some clients that demand less secure designs? Why wouldn't you default to using a secure system and then only implement a less secure system specifically if the client requests it? It seems like your ignorant clients are suffering as a result of your stupid clients.

    The password is salted with the md5 of the user's UUID
    md5 hashing the UUID before using it as a salt does nothing to improve security.

    the mcrypt key is (pepper) is the md5 of the domain name
    I don't understand that part, but in this situation your key should definitely not be derived in any way from a non-random value. If you randomly generate your keys you don't even need to use salt or pepper in a symmetric encryption key.

    If your key is just (domain + pepper) it is pretty much only negligibly more secure than using just (pepper) for all of your sites because of how easy domain is to guess. Even if your key is (random key + domain) [domain serving as the pepper] it is still only negligibly more secure than having just (random key).

    I use the md5 values for salt and pepper as my implementation of mcrypt limts the key length to 32 chars
    If I'm understanding you correctly, you're saying you use the hex representation of the md5 hash in ASCII (ie: the 32 character string output by md5) as your encryption key? An ASCII representation of the hex values of an MD5 hash are only composed of the characters a-f0-9. That gives you a key space of only 3.4*10^38 (128 bits). A random key has a keyspace of 1.2*10^77 (256 bits). While a 128-bit key is still strong enough, it seems pointless to reduce the security of your encryption by 2^128 times for no particular reason.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  16. #9
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2012
    Posts
    8
    Rep Power
    0
    Thanks for the info guys

    I've been searching and reading for the last 2 days about PHP password Cryptographic hashing.

    The most common and secure functions I came across were sha256/512 , bcrypt , HMAC , PBKDF2(Password-Based Key Derivation Function) and PHPass.

    From what I've been reading speed is an enemy (http://codahale.com/how-to-safely-store-a-password/)
    So I've been looking for the "slowest" secure hashing algorithm which I found is bcrypt and PHPass (http://www.openwall.com/phpass/).

    Now I can't make up my mind which one to use.
    What do you guys think? Which one should I go with and why?

    Just to make sure:
    1. bcrypt = crypt_blowfish right ?
    2. bcrypt and PHPass are both hash + salt functions ? I mean I don't have to add salt, they already have the salt function built-in.

    Thanks in advance!
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2012
    Posts
    34
    Rep Power
    3
    You won't need to store the salt in a separate column in your table if you use this technique, as the salt gets stored in the same field as the hashed_password.
    PHP Code:
    //This is just a supporting function that you wouldn't normally call in your scripts:
    function make_salt() {
        static 
    $seed "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
        
    $algorithm '$2a';
        
    $strength '$08';
        
    $salt '$';
        for (
    $i 0$i 22$i++) {
            
    $salt .= substr($seedmt_rand(063), 1);
        }
        
    //see http://php.net/manual/en/function.crypt.php
        
    return $algorithm $strength $salt//blowfish
    }

    //This is the way you create a hash from a user-supplied password, and you store this hash in one field (the salt is included)
    function make_hash($password_supplied) {
        return 
    crypt($password_suppliedmake_salt());
    }

    //This is the function you use to verify if the user-supplied password is actually correct when compared against the hashed_password that you stored in the table for that user:
    function verify_hash($password_supplied$hashed_password) {
        return 
    $hashed_password == crypt($password_supplied$hashed_password);

    So, to verify the credentials a user supplied are OK (or not):
    1. Fetch the user's hashed_password from the table for the username he typed in.
    2. Run the function verify_hash to compare what the user typed in as his password with the hashed password you fetched in step 1.

    To add a new user to the table:
    1. Store his username in plain text
    2. Run the function make_hash to hash up his password, and store that in the table. No need to store the salt separately.

IMN logo majestic logo threadwatch logo seochat tools logo