Must have been a coincidence my card was stolen then. At least I don't need to move away from Linode now, hurray.
Security incident update
21–30 of 282 posts
Re: Security incident update
#22Good 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…
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.
Re: Security incident update
#23Earlier quoted context omitted.
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.
Right; this is a common experience with SSL/X.509 signing keys--they're encrypted by default, so any server you configure with your ssl.pem file will prompt for a passphrase on startup, and only keep the decrypted key in memory.
That's why this line, that most SSL providers give in their instructions, is so dangerous:
openssl rsa -in server.key.org -out server.key
Re: Security incident update
#24Should 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.
Re: Security incident update
#25Earlier quoted context omitted.
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.
This is what ssh-agent does, and I could only hope Linode was using something similar. I think the statement suggests they did.
> The private key is itself encrypted with passphrase encryption and the passphrase is not stored electronically
So even if the hacker bragged about obtaining both the public and private keys, the private key was protected and therefore unusable without the passphrase.
At this point, we can all hope linode used a very complex passphrase... My gut feeling is that they did.
Re: Security incident update
#26It seems seclists was affected
http://seclists.org/nmap-dev/2013/q2/3
Re: Security incident update
#27Earlier quoted context omitted.
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…
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...
Re: Security incident update
#28What isn't in this post:
- Any mention of the claim that they had made a deal with the hackers. No attempt to deny the claim.
- Any mention of when the systems were compromised or when they discovered that they were compromised. The post starts with "Yesterday," mentions working "around the clock" and mentions Friday, giving the impression that this is all very recent, when according to the hacker Linode has known for two weeks.
Re: Security incident update
#29Should 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.
Ah, my description wasn't the best, apologies. What I meant was the payment backend, a separate server, could only service write requests from the frontend. The backend itself would possess decryption keys to make charges, but the frontend could only ever ask it to bill a customer or change the information via a write-only API.
Having said that, if the API were provided via ColdFusion it wouldn't have helped anyway.
Re: Security incident update
#30I 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.