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

Security incident update

blog.linode.com

Post reply on HN
Print view View original

211–220 of 282 posts

Re: Security incident update

#211

Post by brandon272 »

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire.

This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and what is being done to rectify it. If you are a Linode customer reading this, there is no indication as to whether or not you should cancel your credit card number. You, the customer, are left to decide on your own without all the information.

Does Linode have an obligation to advise their customers to request new card numbers? It doesn't look as if they card information was stored in compliance with PCI-DSS and their systems were breached and private information was compromised. Is "the private key was also compromised but we don't think they can guess it, so let's just move on" good enough?

Customers shouldn't have to read between the lines on security updates like this. I expect the companies I deal with to be up front and transparent, even if it makes them look bad. The reality here is that they messed up, not because they didn't patch a week-old exploit soon enough, but because of the poor security practices they had in place internally that allowed the hacker to get the information they did, and by not being up front with their customers to begin with.

Any company can tell you that they take security seriously and that their customers best interests are their highest priority, but what ultimately matters are your actions. What are your security policies? What is your company culture toward security? How quickly do you announce problems and how transparent are you in those announcements?

Re: Security incident update

#212

Post by lawnchair_larry »

moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

sabat: You are hellbanned, FYI.

Re: Security incident update

#213

Post by lawnchair_larry »

gburt wrote: post #209
lawnchair_larry wrote: post #204

Earlier quoted context omitted.

Doesn't make sense. Who here thinks they typed that in manually for every single CC they got? They didn't, encryption/decryption was automated, meaning anyone could have done it if they had access to the process that normally does. Also, the post says salted sha256 passwords are useless. Evidently, they do not have a clue how to safely store passwords, because that is not useless at all. Finally, it's an outright lie…

It's a private key. You need the public key to encrypt, which is not password-encrypted. Although I still wonder about how they run recurring charges.

I understand this, and any system that needed this information would not work if it relied on a human to decrypt.

Re: Security incident update

#214

Post by dangrossman »

brandon272 wrote: post #211

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire. This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and…

> It doesn't look as if they card information was stored in compliance with PCI-DSS

Why do you say that?

The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as the full account number. All of that doesn't prevent the scenario that happened playing out -- someone gets into an internet-connected server, then can connect from there to the database server with the encrypted credit card numbers.

Re: Security incident update

#215

Post by toomuchtodo »

dangrossman wrote: post #214
brandon272 wrote: post #211

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire. This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and…

> It doesn't look as if they card information was stored in compliance with PCI-DSS Why do you say that? The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as th…

So they violated the whole "only store those encrypted numbers on a system not accessible from the public internet" part.

Re: Security incident update

#216

Post by dangrossman »

ig1 wrote: post #203
ryan-c wrote: post #197

Earlier quoted context omitted.

Cracking even a 1024 bit RSA key would cost at least millions of dollars. Credit card numbers are not worth that much.

Tens of thousands of credit and debit cards, many of which are likely to be corporate cards with extremely high spending limits ?

Worth no more than $1 a card on the black market. It'd be cheaper to buy cards than to try to crack the key. There's more supply than demand for stolen card numbers.

Re: Security incident update

#217

Post by dangrossman »

toomuchtodo wrote: post #215
dangrossman wrote: post #214

Earlier quoted context omitted.

> It doesn't look as if they card information was stored in compliance with PCI-DSS Why do you say that? The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as th…

So they violated the whole "only store those encrypted numbers on a system not accessible from the public internet" part.

No, they didn't... You have to be able to reach the server over a network somehow to be able to store new cards and charge existing ones. The requirement is not that the server have no NIC, just that it not be internet-facing itself. The DB server was only accessed through the compromised web server, not directly through the public internet.

Re: Security incident update

#218

Post by justizin »

windexh8er wrote: post #149
wuest wrote: post #144

Earlier quoted context omitted.

> What is not cool about Perl? Perl is my first interpreted language. It has a very special place in my heart, even if it was awkward at first to get used to it coming from a C background. Perl will always be a cool kid.

I think it's interesting when people tie sentiment to coding choices. As previously stated, I could never wrap my head around the horrid syntax and the feeling that if you didn't know it from the beginning it was going to be a long, hard trek in doing so. As for 'cool' I'm not so sure. Perl will be a niche sandbox for quite a while, but most run-ins with Perl (as of late) have been trying to remove it for something e…

Perl was Ruby before Ruby was around to be the ugly cool kid.

Re: Security incident update

#219

Post by scott_karana »

ryan-c wrote: post #197
corford wrote: post #183

Earlier quoted context omitted.

I'm pretty sure UnoriginalGuy understands that. What he says is correct, the attackers now have the private key file so all that prevents them from decrypting the CC data is the passphrase. They don't know what this is but they can try and brute force it which is why it's relevant to wonder what cipher the key uses, how many bits and how long, random and complicated the passphrase text is. Hopefully, they used 4096 b…

Cracking even a 1024 bit RSA key would cost at least millions of dollars. Credit card numbers are not worth that much.

Nobody needs to crack the key: merely the keyphrase. Bruteforcing is relatively cheap.

Re: Security incident update

#220

Post by brandon272 »

dangrossman wrote: post #214
brandon272 wrote: post #211

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire. This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and…

> It doesn't look as if they card information was stored in compliance with PCI-DSS Why do you say that? The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as th…

The requirements also include responsible storage and management of cryptographic keys so that individuals are not able to access your credit card database and private key, in which case the only thing standing in between them and your customer credit card information is a password.
Post reply on HN