Add hashing support for Argon2

https://github.com/AuthMe/AuthMeReloaded/blob/master/docs/hash_algorithms.md

argon2
https://github.com/p-h-c/phc-winner-argon2

table

[ljacqu]

we can do it with https://github.com/wg/scrypt, which is even on Maven central

[Eyremba]

This is useless. I already posted this some time ago:

Maybe take a look at Argon2? Argon2 is currently the most secure password hashing algorithm, even more secure than scrypt. It could be a milestone too for 5.4.

Original Argon2 source: https://github.com/P-H-C/phc-winner-argon2
Java implementation of Argon2: https://github.com/phxql/argon2-jvm

Argon2 is much more secure than Scrypt and much better. Implementing scrypt would just implement an old outdated algorithm...

[timvisee]

Maybe, implementing some dynamic hashing solution might be the best idea. With that, I mean a solution that supports many known hashing algorithms without requiring changes in the code regarding hashing, with minimal code change (just for the initial implementation), and a little configuration property. It would be awesome if the server administrator would have the ability to configure what algorithm is used using some form of algorithm identifier string, whether that'd be a bcrypt, scrypt, Argon2 or /dev/random.

The problem is, that a single algorithm isn't ideal for all situations. Generally speaking, a hashing algorithm that takes longer (in time) to hash, is more secure against brute force attacks. However, that also means that the longer it takes to hash, the more resource expensive it is. And that for each hash calculation that needs to be done when a user enters a password through the login command. Some hashing algorithms even occupy all available CPU cores, which can cause great performance hits on servers running lots of users, or on low performance servers. I've heard that Facebook even uses dedicated hashing servers to minimize the performance impact for users that are logging in on their regular servers, although I don't know whether that is true.

Giving the server administrator freedom to choose an appropriate hashing algorithm would be ideal in my honest opinion. Purely implementing something like this might be a bit overkill solely for the reason mentioned above. But, there can be a constant debate on what algorithm is best, and all users seem to like different hashing implementations. Thus, something like this would be a perfect solution. Many other bigger projects that are focused on password security implement some form of this. And of course, it provides many pro's.

I've seen something like this a few weeks ago, with many supported hashing algorithm adapters, although I can't remember what it was called right now. Maybe it has been mentioned before.

If a feature like this is desired, I might be able to make some free time to implement this through a PR.

What does everybody think about this?

[ljacqu]

@timvisee Your efforts are very welcome (and we have tons of stuff that needs work!) but I think they'd be better spent on another subject.

It's generally a bad idea to mix hashing algorithms. The only legitimate reason for doing this is to hook into an existing system like a forum. There, admittedly, it needs the introduction of a new hash algorithm for it to work.

Given that we sometimes use the configured hash algorithm as an indiciation to perform forum-specific stuff (e.g. XFBCRYPT I think is just bcrypt but it triggers additional work in the data source) I fear that we won't be able to simplify the settings that way.

Bcrypt does a good job of hashing in many iterations. One improvement we can do there is in the settings. I don't think they're clear at all (on mobile, but I think one is called bcryptRoundsLog2 or similar and the comment just restates that xD)

http://softwareengineering.stackexchange.com/a/214451

Of course, I'm happy to be proven otherwise ;)

[ljacqu]

What could be interesting is hashing some password with the same algorithm multiple times: hash1(hash2(hash3(...hashn(pass + salt) + pass + salt) + pass + salt)...) + pass + salt) where n and maybe hash are configurable. But that's essentially Bcrypt, I'd still vouch for making Bcrypt more accessible

[Eyremba]

But that's essentially Bcrypt, I'd still vouch for making Bcrypt more accessible

Bcrypt is OLD and INSECURE when you attack it with modern methods. Like stated multiple times, Bcrypt has been replaced by Scrypt, and Scrypt has been replaced by Argon2. Argon2 is the newest and currently most secure method.

[timvisee]

@Eyremba Is it? Is there any proof for that statement?

Is it because it doesn't require much performance to brute force? The cool think about bcrypt is, that you can configure how much rounds (iterations ^2) to use while hashing, which increases the hashing time exponentially. Also, brypt uses a (secure) random salt for each hash further strengthening the security.

[Eyremba]

@Eyremba Is it? Is there any proof for that statement?

Wtf just google it! Argon2 is the official successor of Bcrypt and Scrypt.

The cool think about bcrypt is, that you can configure how much iterations to use while hashing.

And...? Argon2 can do even more. You can specify the iterations, and also the memory consumption and other things to prevent other attacks.

Also, Argon2 has won the official PHC!

-->

Argon2 is a key derivation function that was selected as the winner of the Password Hashing Competition in July 2015.

--> https://en.wikipedia.org/wiki/Argon2

It has also won against Bcrypt and Scrypt....

--> https://github.com/p-h-c/phc-winner-argon2

[EbonJaeger]

https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

As a note with security algorithms, older does not inherently mean worse or less secure. Nor does something newer mean more secure. Older ones have been tested by time in the wild.

As another note, NIST recommends PKDBF (prolly misspelled, on mobile) for a security hashing algorithm.

[timvisee]

@Eyremba Thank you for the quick reply. Argon2 really does seem promising!

@Gnat008 That's exactly what I ment. This doesn't mean that bcrypt isn't 'secure' anymore. However, I did find some articles where it was mentioned that more efficient ways to brute force bcrypt hashes have been found. Again, this doesn't instantly render it an 'unsecure' algorithm.

I must add, that if a single algorithm is used; Argon2 seems to be the best option.

[Eyremba]

As another note, NIST recommends PKDBF (prolly misspelled, on mobile) for a security hashing algorithm.

That's because they have not tested Argon2 yet, however, Argon2 has won the official Password Hashing Competition in July 2015.

And just as another note, the popular password manager "KeePass" which is used by millions of people uses Argon2 too since the last version/release.

[EbonJaeger]

Congratulations. Doesn't mean I'm gonna necessarily trust the latest and greatest, for exactly the reasons I gave above.

Maybe it is better. But maybe it has a critical flaw that we don't know about yet because it hasn't spent too long in the wild.

See what I'm getting at here?