Join GitHub today
Make PasswordHasher use Argon2id #34
Also introduce hash type agility to stay backward compatible.
@@ Coverage Diff @@ ## master #34 +/- ## ===================================== Coverage 100% 100% ===================================== Files 7 7 Lines 142 150 +8 Branches 15 15 ===================================== + Hits 142 150 +8
Looks good to me.
The fundamental question here is: is it safe to call verify() with arbitrary input? And the answer is: yes it is; you've always called argon2 with arbitrary input (the password, directly attacker controlled). Since you're probably storing the password hashes, it's much harder to mess with that record than it is to mess with the password.
So what happens when an attacker does get to mess with that record? Well, you can't find pathological inputs for argon2id anyway, and you're just comparing against that value, so there's no increased DoS risk or something like that by having the hash type be controllable. Obviously an attacker who gets to write to that record gets to set the password, that's unpreventable.
As non-binding recommendations, you could perhaps get the convenience class to not accept keys with a higher (memory, time) cost than you configure to fix the DoS hole, but I think that's a weird thing to exploit. Additionally, you may want to make the types parameterizable and expose the fact that the password is not complaint with the current standard (be it type or either kind of cost) via an API, documenting the way people could upgrade their existing password stores that way. All of these are nice to haves, and none of them should block this PR.
As an aside, I'm not happy that somehow we had a PHC to finally get this right and apparently the answer is "choose between these 3 subtly different things based on specialized knowledge you're not supposed to have". It's why I still recommend scrypt. But I digress :)
Thanks for working on this. Great job!
This was referenced
Mar 23, 2018
I’ve added a blurb reinforcing that argon2_cffi does not expect malicious hashes.
Ironically, it seems like we’ve just arrived there with Argon2id. :)
I made some updates (including stressing some more, that (ye)script is fine. It would be great if you could give it one last glance!
Re: #35, #36: yep, that's a start, but not the entirety of it. One part is "given a token I am willing to accept and a password that hashes to it, should I re-hash the password to these new parameters?". That's #36 and #35 is a necessary prereq. The other question is: "given this token, should I be willing to attempt to validate a password against it at all"? I.e. what happens when the token tells me to allocate eleventy gajillion jiggabytes? That doesn't seem captured in either ticket.
Re: 5ms vs 500ms,more is better, but UX is the limiting factor. Some guidance: