If you didn't cancel the credit card you used for linode.com, now is the time
I have been a victim of procrastination. Since linode have been compromised, i promised my self i would cancel the credit card and get a new one. Well I didn't, eventually I just stopped thinking about it.
On May 28 checked my card account and I see multiple charges for large amounts. (cash converters, groceries, cheese, and so on). Note this is all done overseas.
How do I know this is from linode?
For my online transactions I use prepaid cards that are easy to dispose of, and this card was used solely for linode.
Advice: If you are still on linode and didn't cancel your credit card, well you should.
137 comments
[ 3.1 ms ] story [ 206 ms ] threadIronically, Chase did flag my DigitalOcean charges last week.
I had been thinking of switching banks for awhile, but this ended up being the biggest motivator to finally pull the trigger.
Whenever I've had an actual fraudulent charge, Chase has just overnighted me a replacement card, both with my business and personal cards. They've got wonderful customer service.
I can't be 100% sure that my card was compromised because of linode, but there is a good chance that it was.
Thankfully the transactions were not captured, so I'm not out any money, but it still sucks.
I've been using them for a while now, and can't in a bit fault them.
Probably the only time in my life a bank actually helped me retain my money!
I no longer have any VMs on Linode. It's unfortunate that a company I trusted behaved so oddly and non-transparently over the course of the incident.
Scroll to the "Linode" section of course.
http://www.exploit-db.com/papers/25306/
Haven't found the ShopSafe numbers yet; I'm going to look for that now that you mentioned it.
Overall great card to have, because besides the 2% back on all purchases (if you deposit the money to a qualified Fidelity account) it has a bunch of the perks like rental car coverage, theft insurance on recent purchases, and doubled warranty, up to 1 year.
Downside, none of their service reps even know it exists, even worse they are slowly phasing it out (making it more and more difficult to find) even-though it is a feature I absolutely love.
Visa and MasterCard both have updater services, which are available to some (but not all--I'm not sure what exactly the requirements are for access) merchants that accept their cards. The updater service allows the merchant to inquire about a particular card number and receive back a status that can be one of: no info available; card still valid; card replaced and here is the new card number and expiration date; account closed.
I assume they don't do this if they replace a card that was stolen/compromised...
Now, if you've already had a charge authorized, then yes, the issuers has to allow that charge to be captured, even if you cancelled the card in the interim. But your issuer can certainly tell you if there are any valid authorizations outstanding.
"We were notified by a payment processor that your debit card information, such as your name, debit card number and expiration date may have been compromised. Unauthorized access to non-_____ systems may have occurred through a merchant where you shopped or dined, or by other fraudulent activity. Specific details about the compromise were not reported to _____."
For my online transactions I use prepaid cards that are easy to dispose of, and this card was used solely for linode.
Couldn't the online card issuer be to blame? How do we know you haven't mistakenly used it for anything else? The fact that you use prepaid cards for online purchases seems fishy to me in the first place (which is just as baseless of a claim on my part as yours is here).
groceries, cheese
How do you use a online generated CC for groceries and cheese??
From Linode:
Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically. Along with the encrypted credit card, the last four digits are stored in clear text to assist in lookups and for display on things like your Account tab and payment receipt emails. We have no evidence decrypted credit card numbers were obtained.
https://blog.linode.com/2013/04/16/security-incident-update/
TL;DR - This is unfair to Linode and I think the community (who uses their service quite frequently) would appreciate if you took it up with them first, before you start a smear campaign.
So on one hand we have someone who is careful enough about their finances to use disposable prepaid cards for renting a VPS. On the other, a company that doesn't understand how encryption works and had to be forced to disclose the attack by the FBI.
Which do you believe?
People keep harping on that, but as phrased that's not a problem. Wherever you have your private key, there's no reason not to also have your public key. The issue is if the private key was living somewhere inappropriate.
Consider that "public and private keys in the same directory" is exactly what happens when you run ssh-keygen on any of the typical setups; failing to then remove the public key is not any kind of a security threat.
If the private key is stored in the same directory, then there no effectively no additional security over simple symmetric-key encryption with a passphrase.
In fact, the public key is public meaning it is assumed that anyone has or could gain access to it. It is purposefully published. So keeping the public key separate is meaningless. Since it is assumed that everyone has access to the public key we must assume that anyone who gains access to the private key has access to both. Ergo there is no reason to not store them both in the secure location.
If they had kept their private key where it belonged, we wouldn't be having this discussion because their security alert would have said "...and we have verified that no credit card data was accessed".
1) super secure server which handles only the processing of credit cards, handed off to it through a carefully specified API
2) webserver which talks to that server
Obviously, the webserver needs the public key. There's no reason to delete the public key from the private server, but not really any reason not to.
Now, let's say that, under certain circumstances, system 1 itself needs to add encrypted records. Now you need the key there too. You could 1) generate a different key-pair and track which key touches which, but for records generated by system 1 you're generating a keypair that might as well be a symmetric key, which you've objected to; or 2) you could encrypt those records with a symmetric key, but now you've got additional code paths to audit and maintain; or 3 you could send off a request to an external server but that seems to add more complexity and vulnerability not less. Just using the existing public key to encrypt those records doesn't seem like a bad idea - it's a message to the server in the future from the server now, and messages to someone get encrypted with their public key.
Now, you've got a system where you have the public and private key sitting on the same server (and being used on the same server), and if someone does manage to get into that secure server (never impossible) the description I initially complained about would be equally applicable to this setup as to the setup Linode had.
1. The public area - meaning anyone has access.
2. The application context (server, etc) -- should be a "secured" location, meaning few people or processes have legitimate access, and measures should be taken to prevent unauthorized access.
The private key should never be present in location 1, public area. The public key is expected to be available here. However, the problem would not be that the keys are together, but that the private key is available here at all, paired with the public or not. To be clear: I am saying the private key should never be available in context 1.
The typical assumption in most scenarios is that context 2 is secure, and by that I mean secure enough to house the private key. After all, the actions taken in context 2 usually require the private key. So it is reasonable to say that we consider this area secure enough to house private keys, and then take adequate measures to protect it. In this case, if the public key is also stored here it is irrelevant, as the public key is already available in context 1. If you have made the decision that context 2 is safe enough for the private key then there is no reason not to also store the public.
However, we have seen that in a typical deployment scenario context 2, the application context, is often compromised. This leads us to create context 3:
3. Dedicated secure key storage. This often comes in the form of an HSM or similar device. See http://en.wikipedia.org/wiki/Hardware_security_module
The purpose of having an HSM is that instead of doing the cryptographic work (which requires the private key in clear) in context 2 , you send a work request to the HSM saying, "Here is the data I need you to work on, here is the cryptographic operation I need performed, and here is the private key identifier representing the private key I want you to use," the HSM performs the crypto operation, and returns the result. Importantly, the private key is never known outside the HSM. Even in this situation, there is no reason not to also store the public key in the HSM. In fact, it is very common to store both the public and private key parts in the HSM so that you can use the same API in your code (the key id) to reference both. Many crypto APIs have limited or no support for cryptographic operations using a key supplied from the outside (outside the HSM). This is on purpose. So often you have to keep the public key in the HSM too if you want to use the HSM for the crypto.
> It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless.
No. No. No. It is true that you must publish the public key for others to use it, but that does not mean you cannot also store it in the secure location. As I have explained above it is often required that it also be present in the secure location.
> This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key.
No. You are not understanding what you are reading. I am saying that anyone who has access to the private key also has access to the public key, so there is no reason not to store them together in the secure location. I'll say it again: If you have the private key, you might as well have the public key. You would never distribute the private key. Period. And just because you store the public key in the same secure location as the private key does not mean you have to give everyone access to that secure location. You could, I don't know, make a copy of the public key to distribute by itself.
It doesn't matter if someone can derive the public key from the private key. That's not what's being argued here. The problem is that there is a place where the public key was stored, and Linode also stored the private key there, which is insane.
And I agree with you for things are are truly high-security, but there are tons of people using PKI in this context 2, because it is not worth it to them to invest in dedicated crypto hardware. I would argue most webservers are in this category. When you spin up a virtual machine in the cloud to be your web server, do you also put together an HSM in your private data center (because you can't really trust a co-location center either) to house the SSL keys? For most people the answer is no. Most web setups have their SSL private key on the same box as their application code, because the web server will need to have access to the private key in order to serve HTTPS traffic.
> you don't want someone with access to the public key to also have access to the private key,
This is false. Specifically, the key pair owner will have access to both by virtue of the fact that they are generated together. So the key owner is a "someone with access to the public key [who also has] access to the private key". To be clear:
Therefore, the key owner has access to both the public and private keys. Therefore it is safe for the owner to store the public key alongside the private key. You do not want everyone with access to the public key to have access to the private key, true. But there is at least one person with access to both: the owner. So it is false to say you cannot store them side-by-side. You can store the public key with the private key in a secure location if you want. You can store the public key anywhere you like. You will need to make the public key available to others outside the secure location so they can use it.> It doesn't matter if someone can derive the public key from the private key. That's not what's being argued here. The problem is that there is a place where the public key was stored, and Linode also stored the private key there, which is insane.
It is only insane if that place was not secure, and if it was public. We do not that place was insecure or public. All you said was:
> The fact that Linode stored the public and private keys in the same directory is strong evidence that they do not have any competence in security.
The fact that the public key and private key were store together by itself tells us nothing. If they stored the private key in a public place (next to the public key or not), then they are beyond stupid. But that fact the keys were stored together means nothing on its own.
Suppose I have the following:
1. A secured HSM containing both the public and private keys. 2. A public-facing webserver serving the public key.
This is a secure setup, and it is true that "the public and private key were store (sic) together"
Putting your private key where your public key belongs is bad. Leaving a copy of your public key with your private key where your private key belongs is meaningless.
It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key.
Edited to add:
"It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key."
Right, it doesn't matter in what should be the overwhelming majority of cases where "the public and private key are stored in the same directory" so it's a piss-poor test for whether things are obviously being done horribly wrong.
- Prepaid cards impose an upper limit on what can be spent, so that if the card details leak out you are protected against losing more money than is on the card. They can't plunder your entire bank account.
- Some people don't like the idea of having debt. By using a credit card you immediately have a debt whether you like it or not.
Credit cards are only debt if you treat them like debt. I use the shit out of mine, but pay the full balance pretty much every month. There's a lot of convenience, I'm fully protected from fraudulent activity, and I have a stupid amount of points/miles/whatever for free (or at least cheap) travel, to boot — I flew to .au a couple years ago for free on that basis, for example.
It doesn't. The GP comment is FUD.
So things like car loans and mortgages could be bad, since they start at 100% and go down.
Here (Singapore) card conditions were recently changed so that you would only be liable for the first $100 of fraudulent transactions (assuming you can prove it wasn't you). I think the bank can still hold you liable for more if they find you were negligent about guarding your card details.
Prior to these condition changes, I remember being told by the bank that you would be liable for all charges incurred before you had reported the card physically stolen or lost.
If you cancelled your credit card after the Linode breech, you potentially saved yourself some hassle, and you saved some merchant somewhere the trouble of a chargeback and lost merchandise, but that merchant wasn't properly verifying cards anyway, so it's still on them. You didn't save yourself a penny.
All of this assumes that all the cards were actually compromised. One report of suspicious activity -- no matter how tightly constrained this person was with their usage -- does not prove that CCs in the Linode database were compromised.
Personally, I don't really care. One of the great things about credit cards is that you're protected from fraud (no really, that's one of the big sales pitches they make). Linode says the cards were encrypted and the private key had a strong password. I have no impetus to inconvenience myself until there is some material reason.
If you know of some method by which merchants are able to reject fraudulent card use of the sort alleged to have resulted from the Linode breach, please do tell.
This post strikes me as nothing more than fear groundless fear mongering.
It doesn't seem unrealistic that someone could take valid creditcard details and put them onto a physical card to swipe.
Given all the big data stuff on my 'work' cards (like gas card which is only used to buy fuel) it should be instantly obvious if a charge is bogus coming from a non-gas station. But I digress.
I wish someone would set up a 'whitelist only' type credit card where I could first do a small test charge, then I could authorize that source with my bank, and then their regular charges would go through. But if the number was compromised any attempt to use it anywhere that I hadn't pre-approved would be rejected.
I've also noticed the same pattern with compromised cards: a couple of small auths to test the waters, and then increasingly large charges coming from decreasingly likely places. I regularly log onto my online banking and inspect the recent activity looking for exactly that kind of activity.
I've long wished for the same, "whitelist-only card" type thing, too. I think I might smell an opportunity...
[1] https://blog.linode.com/2013/04/16/security-incident-update/
In practice, either the Linode data was properly encrypted and keys properly managed, or it wasn't, rendering the encryption worthless. There's very little middle ground.
If you can break properly encrypted data, you have way bigger opportunities than carding.
If it's a prepaid card, I'm assuming that you have to load it with money. Since you're just using it for Linode, you couldn't have loaded that much money on it (unless you're paying for huge Linodes). I'm wondering how large these large amounts were and why they didn't simply empty out the amount on the prepaid card.
Besides my confusion (if I were using your system, I would load $20 or whatever onto the card each month and then the maximum I could lose if the card was stolen was $20), I would also like to point out that while prepaid cards are easy to dispose of, Credit Cards typically provide better fraud protection.
With credit cards, there is normally a $50 liability if the card is stolen and no time limits around reporting it. With debit cards, there are time limits around reporting the card being lost or stolen. With prepaid cards, they are not subject to the jurisdiction of the FDIC and consumer protections are voluntary on the part of the issuer.
Why do merchants really need to store CC numbers? From the consumers' standpoint, there would be no difference if, during the first transaction, the merchant is issued some alterate key with which to charge the account. Each merchant would be issued their own key, so there would be no risk of a security breach spreading outside of the merchant.
Depending on your payment provider, you will be however locked in and can't change anymore.
One of the things you pay payment providers for is for taking on the risk of the higher levels of PCI compliance.
They need to store them transitionally to use them, but in general you don't really want to keep it around. The only legit reason is for subscription/recurring based charges, but if you're doing that you want to make damn sure you're not stupid with how you store them.
Stripe makes it super easy to never even see a CC, so I use them for a bunch of stuff, you can even do reocurring charges pretty easily. If you have any doubts about storing data safely, DO NOT DO IT.
I don't know why this is getting downvoted. This is a perfectly valid explanation for why your card got charged that contradicts your reasoning that Linode's encrypted card database got cracked.
Your explanation is certainly possible, but it doesn't contradict the Linode explanation. You might say that the former is much more likely than the latter, but that doesn't rule linode out.