2

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?

Community
  • 1
  • 1
treng
  • 1,665
  • 3
  • 15
  • 22
  • 2
    @JohnConde no, because that question was asked in 2008 – treng Jul 30 '12 at 19:47
  • 2
    @riwette: The methods described in that answer are still in use today. – Blender Jul 30 '12 at 19:51
  • 2
    @riwette: Cryptography is not a technology that changes from day to day, and the answers from that question are still current. – Crozin Jul 30 '12 at 19:51
  • @riwette: Could you give some examples? – Blender Jul 30 '12 at 19:54
  • 1
    Alongside the useful link provided by @JohnConde, consider taking a look at OWASP's Password Storage Cheat Sheet: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet – Paulo Freitas Jul 30 '12 at 20:10
  • Also see Openwall's [PHP password hashing framework](http://www.openwall.com/phpass/) (PHPass). Its portable and hardened against a number of common attacks on user passwords. The guy who wrote the framework (SolarDesigner) is the same guy who wrote [John The Ripper](http://www.openwall.com/john/) and sits as a judge in the [Password Hashing Competition](http://password-hashing.net/). So he knows a thing or two about attacks on passwords. – jww Oct 12 '14 at 00:51
  • The best variant not to use hash functions but use Key Deviation Function, the best one is Argon2 – sluge Apr 05 '19 at 11:55

3 Answers3

2

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

Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • Doesn't re-hashing just make the hash less unique? – gen_Eric Jul 30 '12 at 19:43
  • I respectfully disagree on the multiple hashing point. If the hash is properly designed, it shouldn't need several hundred iterations on the end user's part to optimize entropy, and if you do too many iterations, you can actually *decrease* the entropy and end up with significantly more collisions. Of course this is just my personal opinion, but I'd like to point out that multiple applications of hashes is just as much a personal choice as not. – Palladium Jul 30 '12 at 19:45
  • @Rocket: No, but it does not make it *more* unique either, at least with a well-designed hash algorithm (see next comment). – Eric J. Jul 30 '12 at 19:47
  • 2
    @Palladium: Why would you want the hashing function to be fast? If you are only computing the hash once to authenticate a user, you won't notice if it takes `0.1s` to compute the hash. But if an attacker is brute-forcing your passwords, they're going to have a hard time cracking at 10 hashes/second. – Blender Jul 30 '12 at 19:47
  • @Palladium: Multiple hashing iterations slows down brute force attacks. – Eric J. Jul 30 '12 at 19:48
  • @Blender When did I ever say I *wanted* the hashing algorithm to be fast? I was speaking from a purely entropic perspective. Again, my personal belief is that something like slowing a hash down is the onus of the designer, rather than the end user, to fulfill. – Palladium Jul 30 '12 at 19:52
  • @Palladium: My bad, I for some reason thought you were talking about `sha512` as the hashing function, not any generic cryptographic hash. Could you explain how re-hashing a hash will decrease the entropy? – Blender Jul 30 '12 at 20:05
  • @Blender I don't remember the exact math behind it, but it was something along the lines of "each round of hashing pigeonholes the data due to the nature of hashing, so a lack of new data introduced results in catastrophic pigeonholing". This, of course, decreases the entropy (but we're talking about thousands to millions of repetitions). A fix that was suggested was re-applying the salt each iteration to introduce new data. – Palladium Jul 30 '12 at 20:14
  • @Palladium: That makes sense. I thought you were referring to iterations of *any* cryptographic hashing function, but shoving the output of `sha512` back into `sha512` will definitely cause some problems after you start exhausting all the possible hashes. – Blender Jul 30 '12 at 20:19
2

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.

Blender
  • 289,723
  • 53
  • 439
  • 496
  • 1
    Bcrypt uses the blowfish encryption algorithm published in 1993. Is it still secure? – treng Jul 30 '12 at 20:17
  • 1
    Bcrypt is made to be future-proof, as you can just increase the number of rounds when hardware starts becoming faster. If you read the Wikipedia article on Blowfish, it says *Blowfish provides a good encryption rate in software and no effective cryptanalysis of it has been found to date*. – Blender Jul 30 '12 at 20:21
1

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.

williamvicary
  • 805
  • 5
  • 20