[elbee]

Waiting until login until you upgrade to bcrypt is a requirement is compotent password storage. At this point in time all Linode should know is SHA-2(password) and they can't use that to derive bcrypt(password).

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.

[msbarnett]

> Waiting until login until you upgrade to bcrypt is a requirement is compotent password storage

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.

[elbee]

That will work as a way to strengthen the hashes (a few other people pointed that out as well).

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.

[msbarnett]

> 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.

[eatonphil]

I don't see anything to indicate they are converting directly from sha2 to bcrypt. When the user logs in next, if it matches the sha2 hashed password, insert the bcrypt hashed password in the bcrypt hash password field and use that from now on.

[stock_toaster]

  > 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.

They just could make the intermediate step bcrypt(SHA-2(password)) via some lockstep code/db backend update. Then on next user login after verifying against bcrypt(SHA-2(password)), update the db to the more straightforward bcrypt(password). At the very least this would increase the difficulty of brute forcing in the meantime.

[maxerickson]

Why can't they bcrypt(SHA-2(password)) right away and then update to bcrypt(password) on the first login?

[ryanlol]

>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.

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?