Hacker News new | comments | show | ask | jobs | submit login
If you didn't cancel the credit card you used for linode.com, now is the time
133 points by ibudiallo 1323 days ago | hide | past | web | 129 comments | favorite
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.




Please provide a little more evidence than starting a flame war. Although it could in theory be true, it's a fairly baseless claim until you present a little more evidence.

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.


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. Their reluctance to disclose the compromise of their customer's passwords and financial data is evidence that they are not trustworthy.

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?


"stored the public and private keys in the same directory"

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.


The entire purpose of having separate public and private keys is for the private key to be stored in a secure location. That way, when your data-writer is compromised, none of the previously written data is at risk without an additional compromise of the key bastion.

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.


You missed dllthomas's point. The private key should never exist outside a dedicated secure location, the "key bastion" as you say. dllthoms's point was that it doesn't matter if the public key is also present in the secure location. There is no reason the keys have to be stored separately. That is orthogonal to the actual requirement that the private key is private aka. secret.

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.


What he might not realize is that SSH can generate the public key from its "private key" file, so there is literally no good way to have a private key separate from a public key.


  > There is no reason the keys have to be stored
  > separately. That is orthogonal to the actual requirement
  > that the private key is private aka. secret.
It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless.

  > 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 private key
  > separate is meaningless.
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.


A public key is a file. It can be stored in more than one place. For example, you can generate both inside the key bastion, and then copy the public key to the public servers, while leaving a copy on the bastion.


But that's not what Linode did. Linode put the private key right next to the public key, where anyone who compromised their web frontend could get at it.

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".


And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.


How does storing the public key on the key bastion make it useless?


The public key is used by the webserver to encrypt credit card data. If it was stored in the key bastion, it wouldn't be available to the webserver.


Okay, say you have the following scenario:

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.


Generally, you will have many copies of the public key on many servers.


You do realize that if you have the private key then generating the public key is trivial? As in you can run a single command with OpenSSL that does it?


I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved:

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.


  > The typical assumption in most scenarios is that context
  > 2 is secure, and by that I mean secure enough to house
  > the private key.
I disagree. An application server is, by nature, running a lot of untrusted and unaudited code exposed to a (semi-)public network. It should not be considered trusted, because it will probably be the first system to be compromised in any attack.

  > 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
And I'm saying that you don't want someone with access to the public key to also have access to the private key, so they must not be stored in the same location. Do you see the difference?

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.


Putting the private key somewhere that antagonists could read it was insane. The fact that the public key was also there didn't do any extra harm, and removing the public key wouldn't help at all. Any attacker has (or can get) your public key, because anyone interested can, that's its purpose.


> I disagree. An application server is, by nature, running a lot of untrusted and unaudited code exposed to a (semi-)public network. It should not be considered trusted, because it will probably be the first system to be compromised in any attack.

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:

  1. *Everyone* has access to the public key.
  2. The key owner has access to the private key
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"


A private key must be stored in a secure location. Every participant in this conversation agrees on that (I would guess). The presence of the public key in that location doesn't do anything to harm security - if it did, the attacker could just bring a copy.

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.


"You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point."


Consider someone learning their way around this stuff, but not yet well versed. They've heard people on HN talking about how "storing public key and private key together" is bad. Would you recommend they 1) move .ssh/id_dsa.pub to a different directory, or 2) make sure .ssh isn't world-readable? The issue was insecure storage of the private key - presence or absence of the public key is entirely irrelevant.


I'd recommend they not store the private key next to the public key; that is, they shouldn't do "scp .ssh/id_dsa* remoteserver:"

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.


Is the issue that you somehow believe "stored with" is not a commutative relationship?

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.


Right. The private key file format typically contains everything needed to regenerate the public key (at least the crypto parameters anyway).


You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.


Er, what? I thought the keypair was supposed to be generated in a secure location (such as your 0700 mode ~/.ssh directory), and then only the public half ever leaves.


As others have said: a private key should never be in an insecure location, or it's no longer secure. You have to generate it in a secure location, and since you're generating the key-pair, you'll have both your public and private keys in the same (secure) location until you remove the public key, which I don't see any strong reason to do.


twbrownaw is exactly right. If the private key is already in a secure location then there is no need to move it to a secure location. So, any report that the public keys were stored with the private keys means nothing by itself.


You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point.


How is it missing the point? It tells us that having "both keys in one directory" is, by itself, no evidence of insecurity by Linode.


Encryption 101.1: move signatures and ciphertext, don't move (non-public) keys.


And if you have the private key, you can generate the public key! You should never store the private key anywhere!


Not even the ram of the crypto module doing the work!


Why is using prepaid cards for online purchases fishy?

- 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.


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.


Your balance is irrelevant - your available credit line is debt, as at any moment you can be liable for up to that amount.


Your available credit line is not debt, and I can't recall ever hearing of anyone being held accountable for fraudulent purchases made against their account. Does this happen?


In the US, you have zero liability for fraudulent charges made on your card without a valid signature, by law.


Credit card terms vary from country to country.

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.


I wound up being held accountable for a small amount because I missed a deadline in the follow-up paperwork. So yes, it happens, but only when it doesn't matter much.


If I have a $10,000 credit limit and $0 balance, my debt is $10,000? At any moment I can be liable for up to $10,000? How does that work?


How does that work?

It doesn't. The GP comment is FUD.


It is, however, an element of your credit score.


In that your credit score has a factor of actual debt to total credit. Someone with $1000 of debt on $100,000 in credit is much better off than someone with $1000 of debt on $5,000 of credit.

So things like car loans and mortgages could be bad, since they start at 100% and go down.


Credit utilization is another element though. It's bad if you have too big a line of credit, but good if you have a historically low ratio of (debt/available credit).


If you're uninsured in the US and break your leg, yes, your debt is now $10,000.


Or much higher, but this is unrelated to credit cards.


"A credit card would give me the ability to instantaneously take on $10,000 in debt. I don't want this." is a responsible and admirable position for someone to take.


Agreed, but once again irrelevant, as that's not what anybody in this thread of conversation has said.


...which is utterly irrelevant to credit cards.


The debt argument is perfectly valid, but in the US, you're not liable for fraudulent charges on your credit cards. The maximum liability is something very small, like $50, but I've never had a bank hold me liable for a single penny in fraudulent charges. This is because the banks simply charge the fraudulent transactions back to the merchant. The banks are not on the hook for the money, so why would they care?

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.


What do you mean by "that merchant wasn't properly verifying cards anyway?"

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.


The tech required to write data onto a physical card is pretty inexpensive, and the standards for how magnetic stripe data is stored is widely known.

It doesn't seem unrealistic that someone could take valid creditcard details and put them onto a physical card to swipe.


I'm with you.

This post strikes me as nothing more than fear groundless fear mongering.


To be fair, that still doesn't mean it's from linode 100%. I recently had a fraudulent charge on a Chase Freedom card that I never once used anywhere (their fine print when it arrived showed they mislead me in the rewards I was promised). I had even shredded it when I got it so its not possible someone took it from my place. When they called me about the possible fraudulent charge, they guy explained that various government/creditor databases contain these cards and sometimes malicious employees use them for fraud.


You are right, i cannot say it's linode 100%, maybe 99%. however it is still a good idea to cancel those cards.


Maybe if they are debit cards, but the hassle of changing cards everywhere combined with the protection against fraudulent charges banks give, I don't plan on doing anything just for the heck of it. IE, lets say your correct and I start seeing fraudulent charges? I call my bank and they reverse them all immediately, it's not a big deal.


If you don't mind my asking, how did Chase mislead you about the awards available? I've had my Chase Freedom card for almost a year now and I love it, but I don't recall running into any sort of fine print issues so I'm curious what you ran into.


Signing up for on-line services is a good use for "virtual account numbers". This is a feature offered on some Citibank and Discover credit cards (maybe others) that allows you to generate a separate credit card number that's billed to your original account. The nice thing about them is that once a virtual account number has been billed by a vendor, it does not accept any charges in the future except from the same vendor. So if the account is compromised, the credit card number is useless to the person who steals it.


I've got an account with Bank of America and they have that feature as well.

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.


Could you point me in the direction of finding this feature? I always thought BofA did not have this and would like to use it while I can.


If you have a Bank of America credit card you will find ShopSafe under "Information and Services" tab when you click on the card in question.


The other downside is that it is Bank of America.


I wish other banks offered that functionality. I am not a fan of Citibank.


NetSpend is free and it doesn't cost to generate a Vitual Card. BTW, it works great for netflix....every month ;)


Get the Fidelity Amex from FIA (aka BofA). It's one of the few genuine 2% cashback cards, has no annual fee, no forex fees iirc, and lets you create "ShopSafe" numbers.


It has a forex fee, just called about it before a trip. Something like 2.5 or 3.5%; my CapitalOne card didn't so I just used that instead.

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.


Are you sure it is the amex card that supports shopsafe? I thought Amex discontinued their similar product _years_ ago.


It's not an Amex issued by American Express, it's a card issued by Bank of America that is processed on the Amex network.


Interesting. Thanks for the info.


Linode stored the encrypted credit card numbers in our [linode's] database ... we have no evidence decrypted credit card numbers were obtained. [1] To me, this implies that the attackers did indeed get the encrypted data. This would be a mighty juicy target to focus your decryption efforts on! In my mind, it was only a matter of time. Regardless of whether OP's story holds water.. get your card re-issued if this applies to you!

[1] https://blog.linode.com/2013/04/16/security-incident-update/


> This would be a mighty juicy target to focus your decryption efforts on!

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.


Attackers claimed that the keys were stored in memory and that they retrieved them: "We proceeded to breach Linode and acquire their in-memory keys." http://straylig.ht/zines/HTP5/0x02_Linode.txt


I just got an email yesterday from Amex about suspicious activity on my account. The card was used to make purchases from at least three dating sites, groupon, Microsoft, hidemyip, and a handful of others.

This card is tied to Linode, Amazon, and one or two other large merchants. Sure looks like Linode CC numbers were breached.


Bank Simple actually reached out to me and asked me if I wanted to cancel my card. I did. But I was impressed that they saw that I'd had charges from them and knew about the security issues.


I also use Simple and I've been very happy with their customer support. Not having checks has been a pain in a few cases, but I definitely prefer it over a brick and mortar. I have a few invitations on my account if anyone is interested.


Hi Osiris would you mind sending me an invite ? Email is hn username at google's mail service dot com. Thanks !


I cancelled mine for an unrelated reason, but was about to anyway once news about the Linode compromise got out. Linode themselves have admitted that the only thing between HTP and the credit card numbers is a passphrase (of unknown quality).

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.


The Linode write-up from HTP which may be relevant to this.

Scroll to the "Linode" section of course.

http://www.exploit-db.com/papers/25306/


Tangentially:

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.


Mostly they don't. The payment provider stores this and provides that and the truncated PAN (the card number with digits masked by asterisks).

One of the things you pay payment providers for is for taking on the risk of the higher levels of PCI compliance.


Hetzner, which was hacked today, did so. They got a unique id back from their payment provider which they stored in their database in order to bill.

Depending on your payment provider, you will be however locked in and can't change anymore.


> Why do merchants really need to store CC numbers?

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.


This creates lock-in with whatever company is storing the cards. Let's say you let PayPal store all your cards and you only had tokens. Now, you want to switch to Stripe, but you'd have to re-acquire the cards from all your customers to do so. If you're doing recurring billing, you're going to lose a significant percentage of your revenue doing this, perhaps so much that it's not feasible to switch even though you're unhappy with your current processor.


OP, I'm confused how your system for paying for things online works.

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.


I would also like to add that the same thing happened to me. Except it happened on May 30th.

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.


FirstDirect cancelled my Linode card for me, after the first three fraudulent charges. Luckily, they were easy to detect, as they were made in physical locations in the US, while I was in the UK at the time.

Probably the only time in my life a bank actually helped me retain my money!


What do you mean by "cancel"? If you mean have your card issuer give you a new card with a new number, and stop allowing charges using the old number, that isn't necessarily sufficient. You may have to close your underlying account.

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.


There is absolutely no risk that this would happen if you call and report your card as stolen. None.

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.


> card replaced and here is the new card number and expiration date

I assume they don't do this if they replace a card that was stolen/compromised...


Is there a difference if you report your card lost (just ask for replacement) or stolen?


I just had to cancel my card due to a large, unauthorized purchase at Walgreens states away. I don't know that it was from Linode, but it was the same card that I had when Linode was compromised.


WF opted to send me a new card out of nowhere, without explaining why they're sending me a new card. I suspect it's due to the linode breach.


My bank does this to me from time to time, without bothering to notify me. It seems incredibly insecure to me - I do have to call to activate it, but there are no "secret" questions asked during this process, just the last four digits of my social security number, and my zip code (and guess where the card gets sent to?)


I believe you only get that streamlined activation if you call from the number they have on file for you, which makes it more secure than it seems.


I suspect it isn't as a fellow WF customer and Linode customer.


I just got notified by my bank about a fraud notice, and they cancelled the debit card I use for Linode.

It's a huge pain, but I'm inclined to give Linode the benefit of the doubt. I've done enough stupid things in my life to not cast the first stone. Hopefully they'll learn from this, and beef up both their approach to security and their transparency. Strike one.


My credit card was recently reissued without my request. The accompanying letter said it was being reissued to prevent fraud, as a merchant had recently disclosed a compromise. It did not say which merchant, but not I suspect it could have been linode. Has anyone else had this happen?


I'm not positive that it was Linode, but I received this email from my bank about the card I used for Linode (bank name removed):

"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 _____."


Thanks, I was thankfully canceled my card. Is there anyone else here that has had their card compromised?


I haven't had anything odd yet.

Ironically, Chase did flag my DigitalOcean charges last week.


Chase notified that a 3rd party was breached and my credit card was at risk. They sent me a new card two weeks ago. Figured it was because of linode.


Funny, that's about when I cancelled my Chase card. When they asked why I told them an internet company I do business with had been compromised. I have a monthly charge from Linode on the card.


A few months ago I had some trouble with BofA flagging my card for "suspicious activity." I had to go in and get a new card twice over two months. The only change I can think of is that I switched hosting to DigitalOcean.

I had been thinking of switching banks for awhile, but this ended up being the biggest motivator to finally pull the trigger.


My Chase cards seem to get compromised somewhat regularly but it's never been an issue. I get a robocall that asks me to press 1 if fraudulent, 2 if legit. Obviously I indicated that the DigitalOcean charge was fine.

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 have seen a $780 purchase in one of my card (which is only used online in App Store, PayPal, Amazon and Linode) on April 27th. I dispute the purchase and request reissue of the card immediately. Since I also use this card physically few times (all before Linode incident) I wouldn't say for sure that Linode was responsible. (I'm not located in US but the purchase was from online store in US, I suspect it might be compromised online by some means.)


I had some issues with a card several months ago that was used for very few things, including Linode. Security on one of the other services I used was actually pretty bad, rather than inadvertently bad: they resent me my own password, and I canceled immediately, so it may not have been Linode, but it's impossible to say.


The card I used for Linode was used for fraudulent online purchases on May 13. However, I also used the credit card at many other places besides Linode, so I'm not certain that Linode was responsible.


Haven't seen any fraudulent charges on my card yet. I only have like 3 different monthly charges that go to that card so they'll be easy to spot and to contest if I need.


I have not noticed any odd activity. My card has been with Linode for years.


Yes, ours was used fraudulently the week before the breach was announced.


Anecdata to the contrary, I've seen no suspicious activity on my Linode-associated card.


Yet? One of the things I've learned by reading Danchev and other blogs on the scourge of credit card fraud is that 'carders' seem to have waaaaaay more cards than they need so the turnaround time between having it be made public and having it used can be quite long. So far for me every time one of my cards has been compromised there was a small charge that went through before the bigger charges came in. And my bank has been pretty good about effectively freezing things as soon as that small charge hits.

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.


Fair enough. "Yet."

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...


It should be easy to prove you did not make the purchases and instantly have your funds credited back to your account OP.


I canceled my card the day I saw the issue relating to linode.com. I'm glad I did!


Do you use Windows? If so, you are infected with Malware that stole your card number and it finally got used.

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.


The way you phrased it makes it sound as though, if you are a Windows user that experienced fraudulent charges, then the _only_ possible explanation is malware.

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.


I haven't seen anything yet, and I tend to keep pretty close watch on it.


I haven't seen anything yet either. All of my accounts have some policy in place where they call us. It actually got annoying when my wife was "couponing" and we hit 5-6 stores in a couple hours. Always got a call. Comforting. Any charge in another country is set to be a flag. When we travel we make a call and let them know so it doesn't get flagged.


Guess they really did leave the private and public keys on the sevrer.


They admitted that at the time. They assured everyone that the password on the private key was secure, even boasted about how long it was on twitter.


BoA actually cancelled it for me, I didn't even have a choice!


Are there any other alternatives out there for VPS service?


I've tested close to a dozen providers, mostly found via http://www.cloudorado.com/ or http://serverbear.com/, and there are many who can match or exceed both Linode and Digital Ocean (who seem to be all over every story here that even touches on VPSes) according to every possible criterion. Personally I went with Host Virtual when I left Linode (shortly after having left Rackspace), but the choice was largely dictated by physical location. Another day it might have been Ramnode. There are others too. The real point is that it's just not hard to find a better VPS host. It's a crowded space.


Sounding like a broken record, but I'm partial to DigitalOcean. The coupon "SSDTWEET" nets you $10 of account credit.

I've been using them for a while now, and can't in a bit fault them.


that card tied to a lot of things :(, probably a bad idea in general. but for overseas charges at least, my bank will block transactions and notify me.


This isn't because of Linode. Both the hackers and Linode themselves have shown that no credit card information was stolen.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: