Is it too early to be suggesting Argon2? I've not heard of it until now, but the Wikipedia entry[1] shows that the paper was just released late last year.
Most environments don't have an implementation for it yet, and the ones that do will probably only get it through libsodium for the first few years.
> I've not heard of it until now, but the Wikipedia entry[1] shows that the paper was just released late last year.
Argon2 was the winner of the Password Hashing Competition, a several-year cryptography competition to find a new password hashing algorithm that would be secure against an attacker armed with a large GPU cluster.
The judges included a lot of famous cryptographers and security experts. Of particular note: Colin Percival, the author of scrypt, and Jens Steube, the project lead for hashcat.
I've read the paper and I think Argon2 will stand the test of time, but I could (of course) be wrong.
Most environments don't have an implementation for it yet
The speed with which environments actually got implementations of previous secure algorithms was half the problem with their use, but I think Argon2 has this nailed. The README now links bindings for Go, Haskell, JavaScript, JVM, Lua, OCaml, Python, Ruby and Rust.
I don't trust them. The various language bindings are maintained by random people who have gone through no particular vetting, and their code is not formally reviewed by anyone.
When I started looking through the node bindings, I found a number of minor bugs and a critical issue that left ~1% of passwords vulnerable.
I trust that the C developers do a good job, but phc-winner-argon2 does not appear to have ever made a formal release. Is master really always perfect?
My suggestion, if you really want to overkill and knock it out of the park: use both. Run it through bcrypt, then through Argon2. If something happens where one of them is deemed insecure/bad practice, you've still got the other one.
This falls into the category of "coming up with your own system". It sounds theoretically as strong as either one, but it could end up weaker overall.
Define X as the maximum time you can allow a hash to run on your server, before it either starts to annoy users, or becomes a DoS issue. Moving from "Argon2, such that it runs for X" to "both algorithms, with a total cost X" means both of them are running with a much reduced work strength.
In the case of Argon2, there is an "iterations" counter, but t=2 is already reasonable, and on low end hardware, you may see t=1. So as per the spec, reducing runtime in order to make whole thing work is going to involve reducing m.
Except bcrypt is already not memory hard, and you've just reduced the only memory constraint in your algorithm.
And entirely possible there are bigger issues I didn't up with two minutes of thinking about it.
Most environments don't have an implementation for it yet, and the ones that do will probably only get it through libsodium for the first few years.
> I've not heard of it until now, but the Wikipedia entry[1] shows that the paper was just released late last year.
Argon2 was the winner of the Password Hashing Competition, a several-year cryptography competition to find a new password hashing algorithm that would be secure against an attacker armed with a large GPU cluster.
The judges included a lot of famous cryptographers and security experts. Of particular note: Colin Percival, the author of scrypt, and Jens Steube, the project lead for hashcat.
I've read the paper and I think Argon2 will stand the test of time, but I could (of course) be wrong.