This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
I use the following code to hash and store passwords:
$salt=uniqid(mt_rand(), false);
hash('sha512',$pass+$salt);
Is it secure in our time? If no, what solution is better?
Is crypt() good for this purpose or it's too old?
To make your hashing harder to brute-force, increase the computation time. sha512 is a cryptographic hashing function and it is optimized for speed. You're only hashing a password once when authenticating a user so don't be afraid to take your time.
Since an attacker will be computing millions of hashes, why not make your hash function take 0.1s per hash? You won't notice any significant speed degradation, but any brute-force attacks will be indefeasible.
That being said, instead of going out and writing your own hash function to do this:
hash = sha512(password)
for i in range(10000):
hash = sha512(hash) + salt
return hash
Use tested solutions like phpass, which uses bcrypt.
Hashing with a salt is good. However, you want to apply the hashing algorithm multiple times (a few hundred is a good ballpark).
"Stretching" the hash function in this way does not make for a stronger hash, but rather slows down brute force attacks.
http://en.wikipedia.org/wiki/Key_stretching#Hash_based_key_stretching
It depends on your use of this, it's not going to be sufficient for storing credit card details or bank details (not that you would hash them!) but it will be more than enough IMO for passwords for a website, especially given you are using a salt and it's the 512 hash.
Related
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 9 years ago.
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?
I want to know the best encryption method in php and how to apply it.
I recommend using the new PHP 5.5 password API. It provides a secure means of hashing a password, while being fast enough.
If you don't have PHP 5.5 available there is a polyfill that works with PHP 5.3.7+: https://github.com/ircmaxell/password_compat
Use PHPass, it is an excellent hashing framework and very easy to use!
Use SHA512 http://php.net/manual/en/function.hash.php.
SHA512 is not cracked. I suggest to use a salt: Some random string that you append to the password before hashing. This can protect against precomputed rainbow tables but not against dictionary attacks if the attacker gains access to the database containing passwords and salts.
SHA512(password + salt) --> hash
Store hash and salt in the DB
When checking password, retrieve salt corresponding to user, concatenate it with password, hash it and compare it with stored hash.
Read here: How long to brute force a salted SHA-512 hash? (salt provided)
Thinking back about your question and particularly about your statement "Hashing a password a million times may be safer, but also slower. How to achieve a good balance between speed and safety". Indeed, repeatedly hashing will protect you against dictionary attacks by making it computationally prohibitively expensive to compute all hashes in a dictionary. I am not teaching you anything here. From the first link I gave you, it took around 46 milliseconds to calculate a SHA512 hash, which is relatively long. Out of hand I can think of the following factors that could influence your decision as you are in an arms race setting:
- Increasing computing power (more CPU cores and GPU computations)
- Improved Algorithms over time
- Amount of money available to the attacker
- The value to get out of your site if cracked (if low, it would not be worth the effort)
against
- Amount of CPU power you have at your disposal
As a rule of thumb, I would hash as many times as possible so as to not impact my web site performance. Taking into account the number of logins per seconds, you can roughly calculate the amount of CPU power you can afford to spend without impacting your site performance.
One last comment: Assuming hackers already have access to the table containing the user names and hashed passwords, you might at that point be more worried about all the bad things they can do on your site.
your not looking for encryption - your looking for hashing.
I suggest openwalls phpass http://www.openwall.com/phpass/
If you are using PHP5.5 they have a password hasing API
http://uk3.php.net/password
for more info.
MD5 (salt-less) has been used for a while a large number of lookup lists are around, Combined with modern hardware getting 700K + passwords per second it wont take long at all to "reverse" the password.
With a salt they are more secure, But still can be cracked quickly
I have been looking at upgrading the password hashing security of one of my applications as I have been reading up about brute force attacks being considerably faster then they used to. Currently I am using sha1(md5($password)) and I see the benefits of using bcrypt + salt. My question is, Would it be any more secure if I were to do the following:
Scenario 1:
$password -> sha1 -> bcrypt -> sha1
// This would enable me to keep all existing passwords and just
// regenerate all the hashes without waiting for the user to re login
Scenario 2:
$password -> bcrypt -> sha1
// I would have to add an extra column for the new hash until every
// user has logged in but the hash will still be sha1.
Would any of these two increase the security of the hash at all? I am no cryptographic master, far from it, I would just like a simple explanation as to if it would work, if not, and why.
Thanks
EDIT
After a little more reading, it seems that bcrypt is favoured because of its slowness in that i makes the cpu/gpu work longer before the hash is generated.
In the case of sha1 vs bcrypt, sha1 is roughly 300000 times faster then bcrypt. Which begs the question, if bcrypts advantage is slowness, surely a recursive hashing function which uses sha1 300000 times would be as secure as bcrypt?
I made this function as an example:
function bsha1($data, $salt) {
$hash = $data;
for ($i = 0; $i < 300000; ++$i) {
$hash = sha1($hash . $salt);
}
Provide it with a salt and itll return a sha1 hash where every iteration is a hashed hash and salt. This takes approximately the same ammount of time as bcrypt. Would this be as secure?
You best upgrade to password_hash().
As it is likely you are not using PHP 5.5 yet (I assume maybe you are already for testing purposes at this time), you can use the PHP userland implementation of password_hash() also written by Ircmaxell for PHP 5.3+.
To upgrade the password hashes on login, you fetch the hash from the database and test first against the new hashing. If it returns FALSE, you test against the old hashing. If that returns TRUE, you re-hash the password with the new new hashing and store it back into the database.
Combining or chaining multiple hashes after each other - and I fear I read that in your question - is a total stupidity you should never consider. Hash algorithms are not compatible to each other and using a hash on a hash that way is doing it wrong: sha1(md5($password)) and the like effectively reduce the output space which makes it easier to attack - something you want prevent in the future.
So take the new password hashing API that there is in PHP and sleep well.
neither scenario gives you much of a security margin over just bcrypt. That said, bcrypt is absolutely the way to go as far as a hashing algorithm that will resist brute forcing, as with a sufficiently high cost factor, it will take a much longer time to hash than any SHA-based hashing scheme.
Saying all that, Scenario 1 may be the way to go, as you are able to secure your db now instead of piecemeal as users log in. Despite what M8R-1jmw5r says in his/her answer, combining hashing algorithms doesn't give you any extra security, but it also won't really impact your security negatively.
You can use any standard hashing algorithm, but being standard hashing function they can be backtracked and there is a potential security risk.
You better go with any hash functions but combine it with salt with your personal keys. here is link
http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
Short answer is yes it would help. However the long answer is no because SHA-1 and MD5 are just weak hashing algorithms now. It would be better for you to just go with SHA-2 algorithms or even wait a little longer and go directly to SHA-3.
The problem is in the hashing function. Three layers will definitely stop someone, but honestly most of the time one layer is enough to get most people to not even bother. If someone is very intent on getting in I would use SHA-2 at the very least other wise you should be fine with what you have.
EDIT::
Ok so to clarify the above. Using SHA1 with Bcrypt is not necesarilly the best way to go. I would use SHA-2 algorithms with bcrypt instead, this would give you more security than using the SHA-1. Also by layers I mean the Bcrypt is one Hash pass the SHA-1 is one Hash pass the second SHA-1 is another Hash pass. I really don't understand why this is wrong? Sorry for the difference in semantics about the layers.
EDIT2::
$Password -> Bcrypt -> SHA-2 or Bcrypt(SHA-2($Password)) Where SHA-2 is one of the SHA-2 family of hashing algorithms.
Code to be more clear than Bcrypt with SHA-2 instead of SHA-1.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to best store user information and user login and password
How do you use bcrypt for hashing passwords in PHP?
I am used to using the md5() which I know is now outdated and I hear that sha1() is also insecure. So what is exactly the best way to store and retrieve passwords in a database these days with security in mind? I'd be very happy if you can provide a small example.
Thank you!
I would recommend looking at bcrypt, since it can help against brute-force attacks. http://codahale.com/how-to-safely-store-a-password/
You can find example Here
You should really use bcrypt to hash your passwords, it was designed especially for hashing password.
Hash functions for passwords should be slow (need some computing time). Most hash algorithms like SHA-1 and MD5 or even SHA-256 are designed to be fast, but this makes it an easy target for brute force attacks. An off-the-shelf GPU is able to calculate about 8 Giga MD5 hashes per second!
Don't be afraid to use bcrypt! It is not for high security sites only, and using it can be as easy, as using an md5 hash. It's recommended to use a well established library like phpass, and if you want to understand how it can be implemented, you can read this article, where i tried to explain the most important points.
UPDATE:
Current PHP versions offers the functions password_hash() and password_verify() to handle passwords. Use them like this:
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
We use crypt with Blowfish:
// Hash our password
$hashed = crypt($plain_text_password, '$2a$08$' . substr(hash('whirlpool', microtime()), rand(0, 105), 22));
// Validate a password
if (crypt($plain_text_password, $hashed) == $hashed)) {
// Valid password
}
The salt prefix $2a$ (read the docs) is what instructs crypt to use Blowfish. And assuming the implementation of crypt(3) in the underlying OS supports it, you get it "for free."
md5\sha1 + unique salt = best way
Don't be paranoid.
You could look up alot of encryption codes or mix them for example like this:
sha1(md5(sha1($pw)));
I find that unnecessary so what I use is SHA512 hash("sha512",$pw);
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is “double hashing” a password less secure than just hashing it once?
So, I was reading an article on securing PHP websites and they recommended hashing a password multiple times, in fact, this is a direct quote from the article:
md4(md4(md5(sha1(md4(md5(sha1(sha1($_POST['password']))))))));
Now, personally, I generally use a salted SHA-256 hash on my passwords, because I thought that MD4 and MD5 were no longer secure and that hashing a password multiple times would just put too much strain on a server for no practical benefit. Is that correct?
The direct quote from the article wouldn't work, as there is no md4() function in PHP. And then it wouldn't make sense still.
Normally applying multiple hashing functions wouldn't hurt. But when you go from sha1 to md5 you are losing input range (md5 gives you 128 bit output, but sha1 is 160 bits long). This is rehashing a shortened excerpt, which means the possible output set is never bigger than that of md5().
If you don't hash your passwords tens of thousands of times, you don't know what you are doing.
This is computationally expensive; that is the point. For the legitimate purpose of authenticating a user who has the correct password, the load is negligible. But for a cracker who is trying to test a huge list of passwords in an offline attack, the cost is prohibitive.
Using thousands of iterations of a hash function is a well-established and widely used technique for "key strengthening." It is incorporated in standards for key derivation, and used in algorithms like bcrypt for password protection.
Use bcrypt or PBKDF2, which will require you to use salt and iterations. Don't try to make up your own method using a few broken hashes.
A bit. If the goal is to actually get the original password, it becomes an impossible task. However, usually it is not, and if you really use md4 for the outermost hash, well.. http://en.wikipedia.org/wiki/MD4#Security
There are many other ways to improve security, the most basic of which is to use some kind of random salt that is not stored along with the password.
function oneWayEncrypt($string) {
$salt = md5($string."yHuJ#8&6%4#%([#d-]");
$salt2 = md5($string."#!#&+-)jU#[yT$#%");
$string = hash('sha512',"$salt$string$salt2");
return $string;
}
Using SHA-512 is a good idea to get a cryptographically strong hash, but your choice of a salt does not add much extra security. In particular, a salt is only good if its value is random and cannot be predicted in advance. This prevents an attacker from precomputing a table of known hashes with which to try to attack your database. If the salt is known, then the attacker can just precompute a table of hash values with the salt hardcoded in.
In your case, the salt is essentially known to the attacker because it's deterministically computed from the input string. If I wanted to attack your system, I could iterate across a bunch of known strings, (deterministically) compute the salt for each string, then compute the SHA-512 hash of the salted string and store it in a table. From this, I could invert a hash to a password for any string I happened to precompute.
If you want a better security system, instead consider using a salt that's randomly-generated and then stored alongside the resulting hash. That way, no matter what tables I precompute, there's a slim chance that the table will be useful because I won't necessarily have computed the tables for all possible salts. Essentially, each random bit in your salt doubles the amount of work I have to do, so if you pick a good random salt (say, 128 bits) then there's no feasible way I could do a precomputation attack. I'd have to attack SHA-512, a hash assumed to be cryptographically secure (the name means "Secure Hash Algorithm"), to break your system.
How secure for what?
For storing hashed passwords? - Use random salts, different for every password.
For signing cookies? - Use HMAC, a Hash-based Message Authentication Code.
You're saying that you want to use it for storing passwords in DB and cookies, both of which should be done using other proved techniques, see above. Don't try to reinvent the wheel.
When you ask how secure something is, you have to know not only what way are you going to use it but also what kind of attack do you want it to be secure against. Things are not secure in a vacuum.
Also, don't assume that SHA-512 is better for your application just because it has more bits. Read the paper Preimage Attacks on 41-Step SHA-256 and 46-Step SHA-512 by Yu Sasaki, Lei Wang, and Kazumaro Aoki (PDF) to see that for certain applications some shorter hashes can be actually more secure than SHA-256 and SHA-512 because there are no known preimage attacks that would brake so many rounds as for SHA-256 and SHA-512.
Although SHA-512 is a good choice for a cryptographic hash function in general, it still might be too easy to compute: SHA-512 is computationally fast enough to process 154 MB/s. You should better choose a cryptographic hash function that is computationally slower like bcrypt that can be slowed down with a cost factor.
Additionally, use a random and unique salt for each hash operation and store it together with the hash to be able to reproduce the hash for comparison.