Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linode Security Advisory

blog.linode.com

Post reply on HN
Print view View original

41–50 of 119 posts

Re: Linode Security Advisory

#41

Post by mikegrb »

Sir_Cmpwn wrote: post #12
matt_wulfeck wrote: post #10

> We have been working with federal authorities on these matters and their criminal investigations are ongoing. I cringe when I see companies say this. As if we're supposed to feel like the "hack" was somehow more sophisticated than spearfishing or social engineering because there's feds on the case. There's a hole in your security. Diligently look for that hole. If it's a mistake own up to it fully and apologize. Ma…

Disclaimer: Linode employee Regardless of the severity of the means, the fact is that this sort of attack is entirely illegal and involving law enforcement is a clear requirement.

Isn't any attack illegal?

Re: Linode Security Advisory

#42

Post by fweespeech »

tptacek wrote: post #34
chc wrote: post #32

Earlier quoted context omitted.

My reading was that: 1. Their security partner (whoever that is) didn't see the Lish vulnerability, either because Linode's security team had already fixed it or because they just missed it. 2. Their records weren't sufficient to show the breach itself.

I'm not just trying to be argumentative. Here, let me quote more specifically: no evidence of abuse or misuse of Linode’s infrastructure that would have resulted in the disclosure of customer credentials. I feel like I must be misreading something. Didn't they say earlier that they found secrets from their account credentials database on a customer instance that was used to attack (apparently) PagerDuty? That's not "…

Honestly, it is likely because they are spinning/lying that it is confusing to you.

If you just assume they are attempting misdirection it makes perfect sense for them to insist things are fine.

Re: Linode Security Advisory

#43

Post by threeseed »

ryanlol wrote: post #9
thesimon wrote: post #7

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 confid…

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

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

Re: Linode Security Advisory

#44

Post by dang »

ryanlol wrote: post #8

I'm just going to leave this glassdoor review here: https://i.imgur.com/sJd56AT.png

Please don't post off-topic replies to the top comment. Or to any comment, really, but with the top comment people sometimes do so to get their own post closer to the top of the page, which is not legit.

We detached this subthread from https://news.ycombinator.com/item?id=11136707 and marked it off-topic.

Re: Linode Security Advisory

#45

Post by threeseed »

noir_lord wrote: post #5

Not sure what to think about Linode anymore, on the one hand from a pure reliability point of view they have been bullet proof, had a few issues during the DDoS in December and I've always found their support to be good (the few times I've used them in 7 years). On the other hand they've had security issues fairly regularly and their response to the DDoS was pretty poor. That said if I was a cynic I'd say they probab…

Linode's support is only good if you have basic problems. Anything tricky or that requires them to be honest they simply won't answer.

I have been saying for years people should not be trusting Linode for anything important. The transparency and the honesty simply isn't there.

Re: Linode Security Advisory

#46

Post by maxerickson »

elbee wrote: post #40
msbarnett wrote: post #30

Earlier quoted context omitted.

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

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…

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

Re: Linode Security Advisory

#47

Post by anaphor »

I've been using Linode for years and I haven't had too many problems with the service itself. That being said, this makes me think twice about staying with them. If I wanted to switch, is the only real competitor Digital Ocean or are there any other good choices?

Re: Linode Security Advisory

#48

Post by stephendicato »

TheSwordsman wrote: post #23

Hey There, I'm a PagerDuty employee and am the same individual who made this post on the last HN thread: * https://news.ycombinator.com/item?id=10845985 Unfortunately, there are some facts in Linode's post that are not correct. >On July 9 a customer notified us of unauthorized access into their Linode account. The customer learned that an intruder had obtained access to their account after receiving an email notifica…

> Although, Linode's email isn't what notified is, it was our intrusion detection system.

Are you able to elaborate on this? I understand you may not want to name specific vendors/products in the name of operational security but it sounds like in this scenario whatever is in place actually did its job.

Re: Linode Security Advisory

#49

Post by msbarnett »

elbee wrote: post #40
msbarnett wrote: post #30

Earlier quoted context omitted.

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

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…

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

Re: Linode Security Advisory

#50

Post by mnordhoff »

stephendicato wrote: post #39
msbarnett wrote: post #30

Earlier quoted context omitted.

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

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.

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... https://news.ycombinator.com/item?id=11118720

Post reply on HN