6 ms·

It seems like the post creates more questions than it answers, but it's great that they are sort of transparent. I guess it's due to ongoing investigation. But

It seems like the post creates more questions than it answers, but it's great that they are sort of transparent. I guess it's due to ongoing investigation. But it is quite surprising that someone was able to acquire the key for the token generation and they seem to have no explaination for it. And wow, they only started tokenizing credit cards now? And SHA-2 for password hashes? THB, after reading this post my confidence in them hasn't really increased. It feel like: "We fucked up, but are not exactly sure why but will fix some issues nevertheless".

ryanlol 11y ago
>completely transparent How so? Either they're 100% clueless or they aren't being transparent.
- thesimon 11y ago
  Agree, edited. It feels like they have no clue at all how it happened, but want to fix some issues nevertheless. I'm not sure if they thought this would bring confidence back. Because if so, they failed hard.
- threeseed 11y ago
  > How so? Either they're 100% clueless or they aren't being transparent. Linode has a long, long history of being less than honest and less than transparent.
msbarnett 11y ago
> 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.
- stephendicato 11y ago
  To add to that, bcrypt is not the best recommendation if choosing a password hash today. In theory they should be adopting Argon2 (or maybe scrypt). 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.
  - mnordhoff 11y ago
    All three are good choices, with their own advantages and disadvantages. Argon2 may be clearly the best choice a few years from now, but both the algorithm and software implementations are immature. It's makes sense to be conservative and go with the more battle-tested options. (Also last I looked Python has no good scrypt bindings.) https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 https://paragonie.com/blog/2016/02/how-safely-store-password... https://news.ycombinator.com/item?id=11118720 https://news.ycombinator.com/item?id=11118720
    - stephendicato 11y ago
      You're right. I agree. In practice I'd heavily weight the decision based on whatever is best supporting in the Python libraries they are adopting.
  - technion 11y ago
    they should be adopting Argon2 I'm saying this as a proponent of Argon2, who has invested a lot of time trying to improve the codebase[0]. 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?author=technion https://github.com/P-H-C/phc-winner-argon2/commits/master?au... [1] https://github.com/P-H-C/phc-winner-argon2/issues/61 https://github.com/P-H-C/phc-winner-argon2/issues/61 [2] https://github.com/P-H-C/phc-winner-argon2/issues/87 https://github.com/P-H-C/phc-winner-argon2/issues/87 [3] https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e7b05b0361fa489ea416c71d860b2e0 https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e...
- elbee 11y ago
  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.
  - maxerickson 11y ago
    Why can't they bcrypt(SHA-2(password)) right away and then update to bcrypt(password) on the first login?
  - msbarnett 11y ago
    > 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 11y ago
      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.
      - 11y ago

ryanlol 11y ago

>completely transparent How so? Either they're 100% clueless or they aren't being transparent.

thesimon 11y ago
Agree, edited. It feels like they have no clue at all how it happened, but want to fix some issues nevertheless. I'm not sure if they thought this would bring confidence back. Because if so, they failed hard.
threeseed 11y ago
> How so? Either they're 100% clueless or they aren't being transparent. Linode has a long, long history of being less than honest and less than transparent.

msbarnett 11y ago

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

stephendicato 11y ago
To add to that, bcrypt is not the best recommendation if choosing a password hash today. In theory they should be adopting Argon2 (or maybe scrypt). 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.
- mnordhoff 11y ago
  All three are good choices, with their own advantages and disadvantages. Argon2 may be clearly the best choice a few years from now, but both the algorithm and software implementations are immature. It's makes sense to be conservative and go with the more battle-tested options. (Also last I looked Python has no good scrypt bindings.) https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 https://paragonie.com/blog/2016/02/how-safely-store-password... https://news.ycombinator.com/item?id=11118720 https://news.ycombinator.com/item?id=11118720
  - stephendicato 11y ago
    You're right. I agree. In practice I'd heavily weight the decision based on whatever is best supporting in the Python libraries they are adopting.
- technion 11y ago
  they should be adopting Argon2 I'm saying this as a proponent of Argon2, who has invested a lot of time trying to improve the codebase[0]. 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?author=technion https://github.com/P-H-C/phc-winner-argon2/commits/master?au... [1] https://github.com/P-H-C/phc-winner-argon2/issues/61 https://github.com/P-H-C/phc-winner-argon2/issues/61 [2] https://github.com/P-H-C/phc-winner-argon2/issues/87 https://github.com/P-H-C/phc-winner-argon2/issues/87 [3] https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e7b05b0361fa489ea416c71d860b2e0 https://github.com/P-H-C/phc-winner-argon2/commit/37e031213e...
elbee 11y ago
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.
- maxerickson 11y ago
  Why can't they bcrypt(SHA-2(password)) right away and then update to bcrypt(password) on the first login?
- msbarnett 11y ago
  > 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 11y ago
    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.
    - 11y ago