It is currently said that MD5 is partially unsafe. Taking this into consideration, I’d like to know which mechanism to use for password protection.
I’m using PHP. I want a safe and fast password encryption system. Hashing a password a million times may be safer, but also slower. How to achieve a good balance between speed and safety? Also, I’d prefer the result to have a constant number of characters.
- The hashing mechanism must be available in PHP
- It must be safe
- It can use salt (in this case, are all salts equally good? Is there any way to generate good salts?)
Also, should I store two fields in the database (one using MD5 and another one using SHA, for example)? Would it make it safer or unsafer?
In case I wasn’t clear enough, I want to know which hashing function(s) to use and how to pick a good salt in order to have a safe and fast password protection mechanism.
How to secure hash and salt for PHP passwords? Answer #1:
DISCLAIMER: This answer was written in 2008.
The theory of the answer is still a good read though.
- Don’t limit what characters users can enter for passwords. Only idiots do this.
- Don’t limit the length of a password. If your users want a sentence with supercalifragilisticexpialidocious in it, don’t prevent them from using it.
- Don’t strip or escape HTML and special characters in the password.
- Never store your user’s password in plain-text.
- Never email a password to your user except when they have lost theirs, and you sent a temporary one.
- Never, ever log passwords in any manner.
- Never hash passwords with SHA1 or MD5 or even SHA256! Modern crackers can exceed 60 and 180 billion hashes/second (respectively).
- Don’t mix bcrypt and with the raw output of hash(), either use hex output or base64_encode it. (This applies to any input that may have a rogue
\0in it, which can seriously weaken security.)
- Use scrypt when you can; bcrypt if you cannot.
- Use PBKDF2 if you cannot use either bcrypt or scrypt, with SHA2 hashes.
- Reset everyone’s passwords when the database is compromised.
- Implement a reasonable 8-10 character minimum length, plus require at least 1 upper case letter, 1 lower case letter, a number, and a symbol. This will improve the entropy of the password, in turn making it harder to crack. (See the “What makes a good password?” section for some debate.)
Why hash passwords anyway?
The objective behind hashing passwords is simple: preventing malicious access to user accounts by compromising the database. So the goal of password hashing is to deter a hacker or cracker by costing them too much time or money to calculate the plain-text passwords. And time/cost are the best deterrents in your arsenal.
Another reason that you want a good, robust hash on a user accounts is to give you enough time to change all the passwords in the system. If your database is compromised you will need enough time to at least lock the system down, if not change every password in the database.
Jeremiah Grossman, CTO of Whitehat Security, stated on White Hat Security blog after a recent password recovery that required brute-force breaking of his password protection:
Interestingly, in living out this nightmare, I learned A LOT I didn’t know about password cracking, storage, and complexity. I’ve come to appreciate why password storage is ever so much more important than password complexity. If you don’t know how your password is stored, then all you really can depend upon is complexity. This might be common knowledge to password and crypto pros, but for the average InfoSec or Web Security expert, I highly doubt it.
What makes a good password anyway?
Entropy. (Not that I fully subscribe to Randall’s viewpoint.)
In short, entropy is how much variation is within the password. When a password is only lowercase roman letters, that’s only 26 characters. That isn’t much variation. Alpha-numeric passwords are better, with 36 characters. But allowing upper and lower case, with symbols, is roughly 96 characters. That’s a lot better than just letters. One problem is, to make our passwords memorable we insert patterns—which reduces entropy. Oops!
Password entropy is approximated easily. Using the full range of ascii characters (roughly 96 typeable characters) yields an entropy of 6.6 per character, which at 8 characters for a password is still too low (52.679 bits of entropy) for future security. But the good news is: longer passwords, and passwords with unicode characters, really increase the entropy of a password and make it harder to crack.
There’s a longer discussion of password entropy on the Crypto StackExchange site. A good Google search will also turn up a lot of results.
In the comments I talked with @popnoodles, who pointed out that enforcing a password policy of X length with X many letters, numbers, symbols, etc, can actually reduce entropy by making the password scheme more predictable. I do agree. Randomess, as truly random as possible, is always the safest but least memorable solution.
So far as I’ve been able to tell, making the world’s best password is a Catch-22. Either its not memorable, too predictable, too short, too many unicode characters (hard to type on a Windows/Mobile device), too long, etc. No password is truly good enough for our purposes, so we must protect them as though they were in Fort Knox.
Bcrypt and scrypt are the current best practices. Scrypt will be better than bcrypt in time, but it hasn’t seen adoption as a standard by Linux/Unix or by webservers, and hasn’t had in-depth reviews of its algorithm posted yet. But still, the future of the algorithm does look promising. If you are working with Ruby there is an scrypt gem that will help you out, and Node.js now has its own scrypt package. You can use Scrypt in PHP either via the Scrypt extension or the Libsodium extension (both are available in PECL).
I highly suggest reading the documentation for the crypt function if you want to understand how to use bcrypt, or finding yourself a good wrapper or use something like PHPASS for a more legacy implementation. I recommend a minimum of 12 rounds of bcrypt, if not 15 to 18.
I changed my mind about using bcrypt when I learned that bcrypt only uses blowfish’s key schedule, with a variable cost mechanism. The latter lets you increase the cost to brute-force a password by increasing blowfish’s already expensive key schedule.
I almost can’t imagine this situation anymore. PHPASS supports PHP 3.0.18 through 5.3, so it is usable on almost every installation imaginable—and should be used if you don’t know for certain that your environment supports bcrypt.
But suppose that you cannot use bcrypt or PHPASS at all. What then?
Try an implementation of hash_hmac() if it is available to make the operation harder to reproduce.with the maximum number of rounds that your environment/application/user-perception can tolerate. The lowest number I’d recommend is 2500 rounds. Also, make sure to use
Coming in PHP 5.5 is a full password protection library that abstracts away any pains of working with bcrypt. While most of us are stuck with PHP 5.2 and 5.3 in most common environments, especially shared hosts, @ircmaxell has built a compatibility layer for the coming API that is backward compatible to PHP 5.3.7.
Cryptography Recap & Disclaimer
The computational power required to actually crack a hashed password doesn’t exist. The only way for computers to “crack” a password is to recreate it and simulate the hashing algorithm used to secure it. The speed of the hash is linearly related to its ability to be brute-forced. Worse still, most hash algorithms can be easily parallelized to perform even faster. This is why costly schemes like bcrypt and scrypt are so important.
You cannot possibly foresee all threats or avenues of attack, and so you must make your best effort to protect your users up front. If you do not, then you might even miss the fact that you were attacked until it’s too late… and you’re liable. To avoid that situation, act paranoid to begin with. Attack your own software (internally) and attempt to steal user credentials, or modify other user’s accounts or access their data. If you don’t test the security of your system, then you cannot blame anyone but yourself.
Lastly: I am not a cryptographer. Whatever I’ve said is my opinion, but I happen to think it’s based on good ol’ common sense … and lots of reading. Remember, be as paranoid as possible, make things as hard to intrude as possible, and then, if you are still worried, contact a white-hat hacker or cryptographer to see what they say about your code/system.
Secure hash and salt for PHP passwords- Answer #2:
A much shorter and safer answer – don’t write your own password mechanism at all, use a tried and tested mechanism.
- PHP 5.5 or higher: password_hash() is good quality and part of PHP core.
- PHP 4.x (obsolete): OpenWall’s phpass library is much better than most custom code – used in WordPress, Drupal, etc.
Most programmers just don’t have the expertise to write crypto related code safely without introducing vulnerabilities.
Quick self-test: what is password stretching and how many iterations should you use? If you don’t know the answer, you should use
password_hash(), as password stretching is now a critical feature of password mechanisms due to much faster CPUs and the use of GPUs and FPGAs to crack passwords at rates of billions of guesses per second (with GPUs).
As of 2012, you could crack all 8-character Windows passwords in 6 hours using 25 GPUs installed in 5 desktop PCs. This is brute-forcing i.e. enumerating and checking every 8-character Windows password, including special characters, and is not a dictionary attack. With modern GPUs, you can of course crack more passwords or use fewer GPUs – or rent the GPUs in the cloud for a few hours at reasonable cost.
There are also many rainbow table attacks on Windows passwords that run on ordinary CPUs and are very fast.
All this is because Windows still doesn’t salt or stretch its passwords, even in Windows 10. This is still true in 2021. Don’t make the same mistake as Microsoft did!
I would not store the password hashed in two different ways, because then the system is at least as weak as the weakest of the hash algorithms in use.
$password = 'anna'; $hash = password_hash($password, PASSWORD_DEFAULT); $expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20)); password_verify('anna', $hash); //Returns true password_verify('anna', $expensiveHash); //Also returns true password_verify('elsa', $hash); //Returns false
password_hash() is used, it generates a random salt and includes it in the outputted hash (along with the the cost and algorithm used.)
password_verify() then reads that hash and determines the salt and encryption method used, and verifies it against the provided plaintext password.
PASSWORD_DEFAULT instructs PHP to use the default hashing algorithm of the installed version of PHP. Exactly which algorithm that means is intended to change over time in future versions, so that it will always be one of the strongest available algorithms.
Increasing cost (which defaults to 10) makes the hash harder to brute-force but also means generating hashes and verifying passwords against them will be more work for your server’s CPU.
Note that even though the default hashing algorithm may change, old hashes will continue to verify just fine because the algorithm used is stored in the hash and
password_verify() picks up on it.
THINGS TO REMEMBER
A lot has been said about Password encryption for PHP, most of which is very good advice, but before you even start the process of using PHP for password encryption make sure you have the following implemented or ready to be implemented.
No matter how good your encryption is if you don’t properly secure the server that runs the PHP and DB all your efforts are worthless. Most servers function relatively the same way, they have ports assigned to allow you to access them remotely either through ftp or shell. Make sure that you change the default port of which ever remote connection you have active. By not doing this you in effect have made the attacker do one less step in accessing your system.
For all that is good in the world do not use the username admin, root or something similar. Also if you are on a unix based system DO NOT make the root account login accessible, it should always be sudo only.
You tell your users to make good passwords to avoid getting hacked, do the same. What is the point in going through all the effort of locking your front door when you have the backdoor wide open.
Ideally you want your DB and APPLICATION on separate servers. This is not always possible due to cost, but it does allow for some safety as the attacker will have to go through two steps to fully access the system.
Always have your application have its own account to access the DB, and only give it the privileges it will need.
Then have a separate user account for you that is not stored anywhere on the server, not even in the application.
Like always DO NOT make this root or something similar.
Follow the same guidelines as with all good passwords. Also don’t reuse the same password on any SERVER or DB accounts on the same system.
NEVER EVER store a password in your DB, instead store the hash and unique salt, I will explain why later.
ONE WAY HASHING!!!!!!!, Never hash a password in a way that it can be reversed, Hashes should be one way, meaning you don’t reverse them and compare them to the password, you instead hash the entered password the same way and compare the two hashes. This means that even if an attacker gets access to the DB he doesn’t know what the actually password is, just its resulting hash. Which means more security for your users in the worst possible scenario.
There are a lot of good hashing functions out there (
hash, etc…) but you need to select a good algorithm for the hash to be effective. (bcrypt and ones similar to it are decent algorithms.)
When hashing speed is the key, the slower the more resistant to Brute Force attacks.
One of the most common mistakes in hashing is that hashes are not unique to the users. This is mainly because salts are not uniquely generated.
Passwords should always be salted before hashed. Salting adds a random string to the password so similar passwords don’t appear the same in the DB. However if the salt is not unique to each user (ie: you use a hard coded salt) than you pretty much have made your salt worthless. Because once an attacker figures out one password salt he has the salt for all of them.
When you create a salt make sure it is unique to the password it is salting, then store both the completed hash and salt in your DB. What this will do is make it so that an attacker will have to individually crack each salt and hash before they can gain access. This means a lot more work and time for the attacker.
USERS CREATING PASSWORDS
If the user is creating a password through the frontend that means it has to be sent to the server. This opens up a security issue because that means the unencrypted password is being sent to the server and if a attacker is able to listen and access that all your security in PHP is worthless. ALWAYS transmit the data SECURELY, this is done through SSL, but be weary even SSL is not flawless (OpenSSL’s Heartbleed flaw is an example of this).
Also make the user create a secure password, it is simple and should always be done, the user will be grateful for it in the end.
Finally, no matter the security measures you take nothing is 100% secure, the more advanced the technology to protect becomes the more advanced the attacks become. But following these steps will make your site more secure and far less desirable for attackers to go after.
Hope you learned something from this post.
Follow Programming Articles for more!