0

What is the safest possible way to store passwords in PHP? I am very interested in keeping my users protected while using my application and I want to use the best possible way to store their passwords. I've done some reading on various encryption methods like MD5, SHA1, etc. I also read up on "salts" and hashes. Can someone please tell me the safest way to store passwords in PHP?

rmaes4
  • 555
  • 9
  • 22
  • 2
    Here we go again... I'm not even going to look up a duplicate for this one. "Not constructive". –  Jun 07 '12 at 00:39
  • 1
    Use a preexisting, well tested [password hashing library](http://www.openwall.com/phpass/). Do not 'roll your own'. – PenguinCoder Jun 07 '12 at 00:40
  • 1
    @PenguinCoder I would go one step further: *use a pre-existing well-vetted authentication system*; Do not 'roll your own'. ;-) –  Jun 07 '12 at 00:40
  • @PenguinCoder: to hash a string is not a rocket science. It really is not. That library is overvalued – zerkms Jun 07 '12 at 00:41
  • possible duplicate of [How can I encrypt password data in a database using PHP?](http://stackoverflow.com/questions/219999/how-can-i-encrypt-password-data-in-a-database-using-php) – mario Jun 07 '12 at 00:44
  • Kid is 15 and interested in programming, give him a break – afuzzyllama Jun 07 '12 at 00:54
  • 1
    :) what do you mean by safest? Have a server script print out the password that is sha523 hashed. Delete the password from the computer. And have someone tear the printout in two. Store one in a safe and the other half in another safe across the globe. – iWantSimpleLife Jun 07 '12 at 01:08
  • @zerkms Plain SHA512 is clearly wrong. It's amazing how many people get password hashing wrong, so the recommendation to use a specialized password hashing library is good. – CodesInChaos Jun 07 '12 at 01:10
  • possible duplicate of [Secure hash and salt for PHP passwords](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) – CodesInChaos Jun 07 '12 at 01:11
  • 1
    Seriously. The safety of the password mainly lies in how complicated the password is. If your users enter stuff like 12345 for their passwords. It defeats the security measures you put in. Ensure that there is a good password policy in place. And just sha and salt it in your database. – iWantSimpleLife Jun 07 '12 at 01:11
  • @CodeInChaos: plain - is. That is why I suggested sha512 with salt – zerkms Jun 07 '12 at 02:25

2 Answers2

2

Storing a password with a hash of any sort isn't going to secure your system, but it will prevent people from seeing plaintext passwords if your system is compromised. Security comes from good monitoring and good practices.

Microsoft has this take:

Many Web applications use a password mechanism to authenticate users, where the user supplies a user name and password in an HTML form. The issues and questions to consider here include:

  • Are user names and passwords sent in plaintext over an insecure channel? If so, an attacker can eavesdrop with network monitoring software to capture the credentials. The countermeasure here is to secure the communication channel by using Secure Socket Layer (SSL).
  • How are the credentials stored? If you are storing user names and passwords in plaintext, either in files or in a database, you are inviting trouble. What if your application directory is improperly configured and an attacker browses to the file and downloads its contents or adds a new privileged logon account? What if a disgruntled administrator takes your database of user names and passwords?
  • How are the credentials verified? There is no need to store user passwords if the sole purpose is to verify that the user knows the password value. Instead, you can store a verifier in the form of a hash value and re-compute the hash using the user-supplied value during the logon process. To mitigate the threat of dictionary attacks against the credential store, use strong passwords and combine a randomly generated salt value with the password hash.
  • How is the authenticated user identified after the initial logon? Some form of authentication ticket, for example an authentication cookie, is required. How is the cookie secured? If it is sent across an insecure channel, an attacker can capture the cookie and use it to access the application. A stolen authentication cookie is a stolen logon.
afuzzyllama
  • 6,538
  • 5
  • 47
  • 64
  • The use of an *appropriate* hashing technique (along with *appropriate* salt *and* HMAC) is to mitigate **total account compromise** should the authentication store be compromised. If the assumption is made the the store *cannot* be compromised then it is no better than storing plaintext, but *that assumption can be dangerous*... –  Jun 07 '12 at 01:19
  • @pst - lol, edited my answered to a closed question – afuzzyllama Jun 07 '12 at 01:21
  • Haha, indeed. And I edited my comment for a closed question ;-) –  Jun 07 '12 at 01:22
1

Sha and salt your password before storing it in the database. Under no circumstances are you to store the password in plain text. Discard the plain password once is has been hashed.

Also use session variables to store and track user session. Do not use cookies as those are stored on the browser and is open to compromise.

Have a good password policy in place. At least make sure there is a minimum length to every password, is not a dictionary word, is not all numeric, and be a mix of upper and lor cases with numbers mixed in the middle. Etc. Google object password policy will turn up a lot.

iWantSimpleLife
  • 1,944
  • 14
  • 22