Should 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?
Security incident update
11–20 of 282 posts
Re: Security incident update
#12The hacker has claimed the public and private key were both stored on the same machine and both accessible. The only protection left is the passphrase then. Various people have reported fraudulent activity on their CCs. Personally, I think Linode didn't mess this up as badly as many other companies. The statement took a while to appear but it's there. As a Linode customer myself I can neither report anything unusual…
> Various people have reported fraudulent activity on their CCs
Most likely not even related
Re: Security incident update
#13I 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.
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.
Re: Security incident update
#14Good to see some discussion and acknowledgment from Linode, but their treatment of the credit card encryption is distressing. They don't address the claim that the private keys were on the servers' filesystems, and instead focus on them being password protected. If the password is brute-forced, then it's game over.
I think a lot of people are failing to understand how credit card processing works. The private key needs to live on some machine, if you actually want to have any CC requests processed at some point. If the private key itself isn't on the frontend/user-facing server, then instead, when the frontend node is hacked, the hacker will find a shared secret or signing key to auth the frontend node against the backend node…
I suppose it could have been kept only in memory, rather than just chilling on the filsystem in a file called private_key which is basically what happened AFAIK. It's surely within the boundaries of sense to load the key manually each time the app boots.
Thinking about it though, that's basically the role of the key passphrase.
Re: Security incident update
#15Hmm. I'm sort of re-assured, but what's happened to the claim that this was targeting a specific customer?
It seems HTP went after nmap.org machines, so I'm guessing that woudl be the directed customer they picked?
Re: Security incident update
#16The hacker has claimed the public and private key were both stored on the same machine and both accessible. The only protection left is the passphrase then. Various people have reported fraudulent activity on their CCs. Personally, I think Linode didn't mess this up as badly as many other companies. The statement took a while to appear but it's there. As a Linode customer myself I can neither report anything unusual…
With the amount of customers Linode has, I'm quite ready to chalk that up to people freaking out because they use their CC on Linode and not realizing they also use it on 3 dozen other things that might be the cause
Re: Security incident update
#17The hacker has claimed the public and private key were both stored on the same machine and both accessible. The only protection left is the passphrase then. Various people have reported fraudulent activity on their CCs. Personally, I think Linode didn't mess this up as badly as many other companies. The statement took a while to appear but it's there. As a Linode customer myself I can neither report anything unusual…
> Various people have reported fraudulent activity on their CCs Most likely not even related
I've seen two mentioned in each of two recent Linode threads, potentially the same people. Have there been many more?
Re: Security incident update
#18To be honest, I'd rather have my credit card number in the wild than be worrying about my sites/servers being compromised. Obviously neither is ideal, however.
Re: Security incident update
#19It's about time we start seeing some OAuth bank account logins for payments.
Re: Security incident update
#20Good to see some discussion and acknowledgment from Linode, but their treatment of the credit card encryption is distressing. They don't address the claim that the private keys were on the servers' filesystems, and instead focus on them being password protected. If the password is brute-forced, then it's game over.
I agree with you. Besides, how do they use the private key? Are they using a GPG agent o anything like that? Do they enter the password every time they need to use the private key?
Having the private key in the web frontend sounds like a bad idea (as this incident has proved), they should use a backend system that is not accessible from the Internet. I don't know how they system works but the web frontend needs to encrypt CC numbers but I'm not sure it is required to decrypt them as that could be performed in a more restricted environment.
Security incidents suck, but the good news is that they now have a chance to improve their security.