"Despite the uselessness of these hashes"... Hrm.
Security incident update
31–40 of 282 posts
Re: Security incident update
#32Should CC info even be stored in the customer database? I would have thought that information should be write only. Does PCI allow that to happen with only PKI in place?
I agree to your position of not storing the CC in the consumer database. However, it cannot be in a write-only state since usually consumers have to billed periodically without having to ask for their number.
Thankfully, you leave it up to someone else to vault your PCI if you keep having intrusions.
Re: Security incident update
#33The update has quite a frank and an apologetic tone to it. Especially the concluding paragraph gives it a very empathetic touch. It must be truly tough for the ops folk at Linode to have suffered an attack due to a third party 0-Day exploit. It could happen to any of us really. On a side note, I am not sure of the "some occurrences of plaintext Lish passwords". Seems like quite a goofup on Linode's part.
It's not really a zero-day, if a patch has been out for a week though.
Re: Security incident update
#34I really wish they would officially comment on the 'cover up' aspect. Security breaches happen, and are forgivable. But attempting to broker a 'silencing' deal with the intruders and hoping your customers will never be the wiser is not. All this update does is restore my faith in their ability to store my information correctly. It does nothing to reassure me that they won't try to cover anything up again.
> All this update does is restore my faith in their ability to store my information correctly How is your faith in that regard restored, when they just said they stored passwords in plain text? They didn't store passwords in plain text by accident, they chose to. They knew the risks and didn't care.
"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are."
Sounds like it's not stored in plaintext.
Re: Security incident update
#35Earlier quoted context omitted.
> All this update does is restore my faith in their ability to store my information correctly How is your faith in that regard restored, when they just said they stored passwords in plain text? They didn't store passwords in plain text by accident, they chose to. They knew the risks and didn't care.
"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are." Sounds like it's not stored in plaintext.
"There were occurrences of Lish passwords in clear text in our database."
Re: Security incident update
#36Ahh, they still don't mention if even their ex-customers are affected by this. Now, I'm really paranoid! Let's just hope for the best...but when I read about 'storing passwords in plain text' I did get a little turned off. I know the Linode team is very technically strong, infact, they've aided me so many times. It hurts to see them make such a silly mistake :(
Re: Security incident update
#37Earlier quoted context omitted.
From their description it appears encrypted CC numbers were in the database amongst the other customer information. Sure, the data has to live somewhere, but the apparent situation of CC, customer, private key all accessible to the frontend looks sub-optimal.
there's a difference between obtaining the private key and the private key file , which according to Linode was protected with a (hopefully strong) passphrase...
It might have been encrypted, but surely it must be exposed to their system somewhere to enable them to make charges? Is it feasible, if that was the case, that the attackers could use that to exfiltrate decrypted CC info?
I suppose this wild speculation isn't helpful or conducive and waiting on more information might be a better idea. I think the reputation damage has already been done, judging by the comments on the previous post though.
Re: Security incident update
#38I really wish they would officially comment on the 'cover up' aspect. Security breaches happen, and are forgivable. But attempting to broker a 'silencing' deal with the intruders and hoping your customers will never be the wiser is not. All this update does is restore my faith in their ability to store my information correctly. It does nothing to reassure me that they won't try to cover anything up again.
I feel like there is a fine line between a "cover up" and a "grey hat disclosure". Reading the IRC logs from #linode [0], HTP hacker ryan* seems to say that they made a deal of "we don't tell if you don't tell" but then Linode broke the deal by reporting them to law enforcement.
You could see this as a cover up or you could see this as a disclosure from the crackers to Linode. I see it as a cover up, since Linode should tell us anyway that servers were broken into, but I could see how it could have been seen as reasonable disclosure.
In any case, if what ryan* is saying is factual, then Linode reneged on the deal, a shady one in the first place, HTP has credit card hashes and evidence that Linode stored Lish passwords in plain text (a log maybe?), and the only thing separating them from credit card numbers is the passphrase on the private key, which is hopefully a strong one.
[0] http://turtle.dereferenced.org/~nenolod/linode/linode-abridg...
Re: Security incident update
#39Earlier quoted context omitted.
> All this update does is restore my faith in their ability to store my information correctly How is your faith in that regard restored, when they just said they stored passwords in plain text? They didn't store passwords in plain text by accident, they chose to. They knew the risks and didn't care.
"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are." Sounds like it's not stored in plaintext.
And then "There were occurrences of Lish [the Linode Shell] passwords in clear text in our database."
Re: Security incident update
#40Earlier quoted context omitted.
As these situations, especially on the internet, come out as "he said, she said", I think it's probably more important to keep focused on what directly affects you.
Sure, but in this case it wasn't Linode who initially came forward - it took a public announcement from the intruders for Linode to notify us.
Devils advocate: preparing a press release from a company after plugging holes and auditing that makes the appropriate admissions and apologies probably takes more time than writing up a successful hit after attacking a page.