> SHA-2 for password hashes
They're moving on from them, but they're going to leave SHA-2s sitting there and wait until everyone logs in to upgrade to bcrypt hashes at rest.
Not getting a super competent vibe off of these folks.
They're moving on from them, but they're going to leave SHA-2s sitting there and wait until everyone logs in to upgrade to bcrypt hashes at rest.
Not getting a super competent vibe off of these folks.
In practice, I suspect that either the bindings for Argon2/scrypt don't exist or aren't easily adoptable given their use of ColdFusion. They do exist in Python.
Either way, it seems like a sub-optimal decision.
(Also last I looked Python has no good scrypt bindings.)
https://paragonie.com/blog/2016/02/how-safely-store-password... https://news.ycombinator.com/item?id=11118720
they should be adopting Argon2
It currently isn't ready in large production. Efforts to stabilise the API are being spearheaded by someone apparently outside the project[1]. If you're reading this @lucab, thank you.
In the meantime, my Ruby bindings have been broken on three separate occasions due to API changes. You could easily say "Don't track master", but the one release has a tag of 20151206, and it's just an arbitrary a tag as any particular commit id. There is no branch from which you could apply "bugfix only" updates.
Two separate commits broke compilation. This commit[2] was a shambles.
Most importantly, they have commits going in two days ago that change the test vectors[3]. That means if you update your library, verifying existing passwords breaks. The hash identifier doesn't change ( in the way that bcrypt had $2, then changed it to $2a then $2y when they changed the algorithm) which means you can't just write an "upgrade hash" function. I can't find any documentation relating to this change.
It's important to note that none of this means your passwords are easily broken, or that it's insecure, which is the implication I often see thrown around when discussing Argon2 being "new".
[0] https://github.com/P-H-C/phc-winner-argon2/commits/master?au... [1] https://github.com/P-H-C/phc-winner-argon2/issues/61 [2] https://github.com/P-H-C/phc-winner-argon2/issues/87 [3] https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e...
The way upgrade should work is that the user provides their password, which is verified with SHA-2 and then hashed with bcrypt and stored again.
In order to do this without people logging in Linode would have to bcrypt hash the SHA-2 hashed passwords and then keep doing that for all password validations.
It's not even remotely competent. This blog makes it clear they're not even sure how their secret key was stolen. These hashes could be walking out their backdoor as I type this. Keeping vulnerable hashes at rest is insane.
It would be far more competent to bcrypt the SHA-2s, so that at least when the hashes wander out the backdoor they haven't really found, peoples passwords aren't trivially attackable.
> In order to do this without people logging in Linode would have to bcrypt hash the SHA-2 hashed passwords and then keep doing that for all password validations.
No, they'd just have to replace Bcrypt(SHA-2(password)) with Bcrypt(password) once the customer finally logs in.
It's an immediate net upgrade to the resistance of at-rest Hashes to brute force attacks with zero downside.
My point was that if you have a system which can go straight from SHA2(password) to bcrypt(password) then the system must be storing the plaintext of the password, which would be very bad.
Yes, I understand that. It's just completely irrelevant to the question of whether or not it's competent practice to store vulnerable hashes indefinitely, awaiting customer log in.
Again, it is not a competent practice. Wrap vulnerable hashes in strong ones immediately; they're a huge liability to leave sitting in your storage even when you don't have evidence that there's a backdoor in your systems that you cannot seem to find.
> At this point in time all Linode should know is
> SHA-2(password) and they can't use that to derive
> bcrypt(password).
> ...
> In order to do this without people logging in Linode would have
> to bcrypt hash the SHA-2 hashed passwords and then keep doing
> that for all password validations.
Er no, forcing email password resets and blocking the old passwords is the only way you should ever handle breaches like this.
to the downvoter: do you think it's cool to fuck over every single one of your customers that hasn't logged in recently?