I use Privacy.com, which basically turns every card I use with them into a canary. The first time you charge on one of their virtual cards, they become merchant-locked. No other merchant can charge to that number, and if someone tries, I get an alert.
I have uncovered flaws in online merchants this way, and notified them. They were usually grateful, especially so since the fraudulent charges failed.
I'll give you a warning about them, they won't issue a chargeback for anything. Even blatant fraud. They'll give you a vague response about rules with their processor.
I used them for a purchase, the company then blatantly lied about everything (tweeted that "everyone's order was shipped" 2 weeks before I even got a tracking number).
They asked me for the following:
- Order receipts
- Email communication with the company
- Tracking numbers
- FedEx investigation (consumers can't open these, only the shipper)
I showed them the chat history with FedEx refusing to open a claim, and provided the other information.
They then proceeded to IMPERSONATE ME to FedEx live chat "to prove I was lying." The sent screenshots only showed them asking if a tracking number had been delivered, not any of the actual data around the tracking number.
Needless to say, I've never used them for anything again and post this everywhere I see them mentioned.
That‘s really no longer true for most debit cards these days. Issuers can process disputes for debit and credit cards in the exact same way (at least for transactions on Visa and Mastercard, i.e. practically for all online payments).
Higher tier credit cards often have additional insurance that goes beyond what the chargeback mechanism is designed for, though, but for fraud, you shouldn’t need these.
It kind of kills me how badly understood this is in /r/personalfinance.
I think something like 85%+ of banks now offer next day refund of fraudulent charges from debit card charges. But that statistic is kind of meaningless in that, if your bank offers it, there's not a lot of extra protection a CC card grants you unless there's a specific value-add to the card that is meant to retain you as a customer.
> with a debit card you don't get that spending power back during the process.
At least for consumer debit cards, that's not the case. Regulation E requires provisional credits (until the investigation and/or chargeback process is complete) in essentially all instances of fraud.
> And if it's international dispute raised after 14 days you might get no where.
Where do you get that number from?
At least in the US, federal law limits liability for lost and stolen cards to $50 (when reported within two business days) or $500 (within 60 days after receiving your statement). For non-lost/stolen cards, which covers all online fraud (due to stolen card numbers, compromised merchants etc.), there is no such time limit, as far as I know.
And these are just the legal caps on consumer liability: Most issuers go far above and beyond that, and extend zero liability for effectively all scenarios, just like for credit cards.
You know I've no idea where I got 14 days from. But I'm not US based and the last time I disputed something was in the EU at the start of the pandemic.
It's also frankly absurd that no such service exists for European customers. I've been looking the past few days for someone who does something like this and it's just not available, for what I can only assume are regulatory reasons.
Revolut has single use credit cards as part of their offering. You can either choose to create a new one for each transaction (disposable card) or a virtual credit card that you can use more than once but discard if something happens to it.
Because both types are virtual prepaid type cards, some services (e.g. car rental) will not accept such cards.
Its my understandingn that Visa does offer the service to banks, they just haven't implemented it. There is to my knowledge no regulatory red tape, it's just not seem as profitable.
The banks here in Denmark har just less competitive and more entrenched than in the US
I wouldn't say that banking is particularly competitive in the US when it comes to technological/product features such as this. Out of several of my cards, only one issuer offers virtual/one-time use card numbers themselves.
My Swedish bank (Swedbank) had this service from some time in the 00's up until 2017 when they discontinued it. So they were way ahead of the game but for some reason dropped it.
Regulations are indeed the reason that Europe does not have proxy cards, but pretty indirectly:
In the US, debit card interchange is heavily regulated for most issuers (to an extremely low rate of 0.05% plus a flat 0.24$ per transaction, which can be frustrating for microtransactions, but that's a different story).
Some issuers are exempt from this requirement, though – very likely including the one that Privacy/Lithic use. This gives them a very nice arbitrage opportunity which can pay for the product and even return a profit.
In Europe, there is no such exemption, so a proxy card can even theoretically never be profitable (you earn 0.2% but also pay 0.2% per debit transaction, and after network fees, you're in the red).
What would be possible is to offer single-used debit cards that are funded from a bank account via direct debit, which is effectively fee-free (but decidedly not risk-free). Privacy offers that option as well in the US.
But given the direction into which the EU is moving (heavily guided by regulation), which is to effectively mandate 3D Secure for almost all online transactions, it's questionable how much demand for such a product there really will be, going forward.
My understanding was that privacy.com is just a “detached service” implementation of something that many European banks offer natively as a feature of having a credit card (or even just a chequing account) with them; and that privacy.com was only viable as a business because, for some reason, American banks are (or were at the time) totally unwilling to build anything like this, so people were willing to settle for a (strictly worse from a “privacy” perspective) third-party-MITM-proxy card if it meant having this feature.
I’d suggest, rather than looking for a “detached service” that does this, look at what (probably larger) European banks besides than your own offer their customers built-in.
My Indian Bank, HDFC offers this since 2008, virtual cards with custom amount, one time use. On creation, the amount equal to limit gets set aside. If merchant charges less than max limit, the excess comes back.
Thier at-time debit cards were good only for domestic transactions, but this virtual was good for international, & used to come up as Visa Prepaid. I used it for registering domains & amazon international shopping.
Credit card shouldn’t need to be shared with all and sundry. The concept is very old fashioned. We wouldn’t share out side project github keys like this!
Quite the opposite: It should, in an ideal world, be perfectly safe to share your credit card number with everyone, because all it should be is arguably an account number.
Payment initiation or confirmation can be an entirely separate layer (such as chip + PIN or 3D Secure).
This is actually the goal of European regulators right now (with some carve-outs for low value and low-risk transactions).
At the moment you need to provide a complete "private key" to each processor, who up the ante to: CC Number + Expiry + Security Code + Name + Address. They all ask for it, so any of them could leak it, or it could be phished.
The system works because it's mostly reversible. If my card gets leaked and someone tries to use it. I just disable my card in the app, contact the bank, they refund the money and issue a new card. Perhaps sometimes the bank has to eat the loss but it works out perfect for the consumer.
What's absurd is that this is something I have to pay for or find a particular issuer of a visa/mastercard. It should be free and included with every visa and mastercard. They should demand that every issuer of their cards needs to offer virtual cards and 3d secure. If they don't then their fees should be significantly higher.
Issuers effectively do need to offer 3D secure, since they are liable for all fraud that happens on 3DS-enabled transactions. It's just their choice on whether they choose to require authentication at all, some, or no transactions.
The US has more of a free market approach here, and experience has shown that the conversion rate hit is often much more severe than the reduction in fraud. Consumers will just use the most convenient card, and that turns out to be the one that just lets them buy (almost) everything without additional challenges.
The EU is taking the approach of forcing all issuers to challenge cardholders for most (higher value/risk) transactions. Given that the rules are the same for everyone, cardholders have nowhere to "escape" to – and issuers finally were forced to invest into making their implementations more usable.
Capital One offers it on their certain credit cards. Somehow Google Chrome, when you save Capital One card in it, offers to generate virtual directly from Chrome.
How is that absurd? There is approximately zero consumer demand for stuff like this. Remember when chip cards were deployed 10 years ago and everyone was annoyed at how chip readers forced them to have the card out longer? Or how Amazon often doesn't check CVV numbers because doing do would increase attrition?
Of course a few of the largest banks find it worthwhile to add a page to their website where you can generate virtual card numbers, but it's not a huge win for them by any means even when they're liable for stolen cards.
I've only used this for the sketchiest of vendors though. Chargebacks are pretty easy for the once-a-decade event where I get billed for something incorrectly.
I wanted to use Privacy.com for virtual CC #s on a checking account, but the enrollment process requires credentials for the linked account's online banking login.
Not just ACH information from a check for the linked account, which is all they should require.
No, despite supposedly being privacy-concerned, they require credentials (or auth token, hopefully) that gain access to everything the login has visibility into. I have multiple accounts at these places, the checking account is a tiny fraction of what's available with creds in hand.
That tab was promptly closed and effort abandoned.
Bank of America used to have this feature with virtual cards and I was using it a lot. They killed that service few years ago and I was really sad they did that. Not sure if other banks are offering virtual cards for free. I might give Privacy.com a try.
I had heard of this service before and assumed it costed money, but thanks to your comment checked it out, and apparently they have a free tier allowing you to create 10 cards per month. Cool!
The only downside which stops me from using privacy.com us that I will lose the chance to earn points or Cashback, as privacy charges directly to your checking account (understandably).
Does anyone have a good alternative to Privacy.com where your virtual credit card transaction data isn't sold to Wall Street? If you're unfamiliar with what a "virtual [credit] card" is here's the page from Privacy.com's website: https://privacy.com/virtual-card I use the Privacy app on my mobile phone to create virtual cards (primarily for work subscriptions). Pro-tip: since each Privacy card can have its own name put a tag such as `[WORK_RECURRING]` into the card name and then you can search your email inbox for `[WORK_RECURRING]`, quickly and easily finding all of the transactions / charges that you may want to submit to your workplace for reimbursement.
Privacy is owned / created by Lithic, but if you look at Lithic's investors you'll see that the plurality of the company's investors are in the private equity or VC space: Bessemer Ventures, Tusk Partner Ventures, Index Ventures, etc. You can see the Privacy.com / Privacy mobile app's funders here:
https://www.crunchbase.com/organization/lithic-pay
Thus, I have no doubt that my transactions on cleverly-named Privacy app are being gifted or sold to Wall Street so that hedge funds can squeeze out a few addition drops of 'signal' from consumer purchase pattern data that would otherwise remain dark. (I'd imagine that many folks use the Privacy app to buy things that they'd rather not have show up on their regular credit card bills: 'adult websites', marijuana or tobacco products, etc.
So, two questions:
(1) Does anyone have a privacy-respecting alternative to Privacy.com's virtual credit cards?
(2) Does anyone know of a recent blog post where these virtual credit card services are compared / contrasted by
- the services that they offer,
- the cost: free, paid, etc.,
- the terms of service: how your data is re-sold / who your data is transmitted to
It doesn't block wall street knowing about what you're buying, but at least it's likely got one (or more) fewer middlemen looking at all your transactions.
Once I saved Capital One card in Google Chrome, Payment Methods in Chrome Settings offers a radio button Virtual Card On/Off. If switched on, Chrome directly generates a virtual card, removing the need of Eno extension.
I can confirm this works pretty well. The Capital One mobile app will also give you a single virtual card number (without the merchant lock or any other extra features) if you don’t want the browser extension or just need it once.
Citi also offers unlimited virtual card numbers for credit cards, and it is a bit easier than Eno since you can manage directly from the website without needing to install anything.
Capital One lets you manage them on their website as well. They just really seem to be pushing their extension and Chrome integration, which I both don't care too much about, but the functionality is there (albeit well-hidden).
I would bet that all of your electronic transactions end up in some pool of data, no matter what you try. I believe only cash at a swap meet while wearing dark sunglasses and a hat is really private.
And even if you can both track them down and hand evidence of wrongdoing on a silver platter to law enforcement in their jurisdiction, often the places these criminals operate out of were selected specifically because their justice system is corrupt and easily bribed. Often, these fraudsters can even talk local politicians into seeing their (cover) businesses as “important local industries, employing local citizens, generating taxable income, and making charitable donations.”
This is the strategy used by the harder-to-kill scam call-centres in India; certain cities in India (I believe Hyderabad?) have been repeatedly handed damning evidence of criminal acts by scammers operating there, but it gets swept under the rug every time. When a big-enough stink is made that it makes their own local news, they just give the criminals a slap on the wrist or lest (e.g. an arrest on low bail that they easily afford to pay, with the case then being dropped before it ever goes to trial, as soon as it’s out of the news.)
The US has the power to really cause damage to India (and well any other country). They can cause a stink on the UN front and if that does not work, escalate financially like they do to countries like Iran. Its just not that important for the extremely old and corrupt leadership at the top to care about though. I suspect once someone from the internet generation takes the presidency, there will be some chance of something changing.
Bounty hunters are not really a thing in the way you’re thinking - they can’t just go to Japan, investigate someone, arrest them and bring back someone from there for instance. They’re for returning someone already arrested who jumped bail somewhere. And they typically don’t work internationally, as their legality is dubious even within a specific jurisdiction.
For something major, it’s generally already possible to investigate and get someone extradited already, for instance, when the cultural gaps aren’t too large and the cultures have a common agreement on what a ‘major crime’ is and looks like. Murder, for instance.
The issue is the bar for ‘major enough’ gets higher and higher the more jurisdictions/cultures you cross, and it is super easy now to scam across a large enough gap there that no one is going to arrest or participate in investigating all but the largest and most blatant scams.
Good luck getting someone arrested in Russia, Nigeria, China, etc. for wire fraud, for example.
You wouldn’t send a bounty hunter to Japan. You’d hire a Japanese bounty hunter who operates in Japan. Or, more specifically, you’d put up a bounty for someone’s arrest in Japan, and one or more Japanese bounty hunters would “take on” the bounty.
Also, the goal of hiring a bounty hunter, presumably, wouldn’t be to get them arrested for things that are crimes in some other country, but rather to get them arrested for things that are crimes in their own country (or in whatever country they happen to be hiding it.)
Bounties in the US are issued by the court. You can’t issue one as a private person.
For it to be legal for a bounty hunter to do anything, they need to comply with some laws while doing it. Otherwise, it’s false arrest and/or kidnapping.
Which I’m sure with some work, and a lot of money, some folks would be willing to do for you. However, I doubt it would go well for anyone, and certainly wouldn’t result in the person being taken going to jail if all they did was scam someone.
Targeted International kidnapping (human trafficking?) is one of the ‘quite serious’ things likely to get whoever initiated it tracked down and thrown in jail though.
Near as I can tell, only the Philippines has a similar system.
It gets a lot of press and there are a lot of legends around it, but it isn’t what you think.
The formal system for having someone arrested and sent to another county is extradition, and it works rather differently. It’s slow, expensive, and rarely used outside of serious crimes.
Having someone arrested, tried, and penalized in another country for committing a crime against you somewhere else is also not easy.
1) often the courts in the attackers country will say they have no jurisdiction to try them, as the crimes were committed elsewhere. This can also happen if you try it in the victims country.
2) you run across all sorts of ‘meh, don’t care’ issues when the attacker is bringing in good money locally and the victims are seen as ‘not here/not anyone we care about’
3) good luck collecting evidence, making a case, getting them arrested, etc. in a foreign county, speaking a foreign language, with a legal system that you don’t understand. It’s hard enough doing it when it’s local.
4) if the local legal system is known for corruption, good luck figuring out which buttons to push. The attacker almost certainly is already familiar with them.
Not impossible. But the costs can easily be > $100k, sometimes in the millions.
I'm also interested in knowing which law-enforcement divisions are actively interested in taking on fraud cases -- if the community finds it, which divisions and prosecutors are fired up about chasing down online fraud?
Seems like a great way for an ambitious team to make a popular difference in the world.
I’m dying to know how they implemented this. In order to have Visa or MasterCard process this transaction, they’d need to have a bank partner to issue the credit credit card with an issuer processor. There’s usually a large cost to keeping open credit cards on file, even if there’s no line of credit.
This is tangential, but still related: a few years ago I could buy disposable VISA cards which were these vouchers you bought in a store and were preloaded with a fixed amount. They didn't even have to be in your legal name.
I put the numbers on e-crime forums for people to snap up, and it was funny watching what kinds of transactions were being made. Most people were using it to buy cryptocurrency.
Most of the transactions were vague though and didn't mention the merchant in question, but with a bit of digging I discovered they were so called 'Discreet Billing' companies which are largely used for adult websites and used to mask the fact you were buying porn to people casually glancing at your CC statement.
Very interesting tool. I'm going to write the canary CC onto a physical card and swipe it first when shopping. If I ever see it randomly accessed, I'll know my 2nd card (actual payment card) is burnt.
>Credit Card Rate-Limiting currently in place. Please try again later.
Hmmm … I like the idea but my hunch was that disposable card numbers would fail at POS because the network knows that card should never have been issued physically?
If you run this experiment, would you do a tell HN ?
> Savvy attackers may start looking for patterns in the bank identification numbers (BINs) that we issue, and proactively deleting or excluding them from their dumps. For this reason we are in discussions with a number of banks to onboard their BINs to the system too, further mixing in legitimate cards with tokens.
> It’s a compelling argument: “Would you like attackers to first remove your bank’s cards from dumps they steal?”
I've thought about something similar for spam calls: I can play whack-a-mole blocking individual numbers, but it won't scale fast enough and scammers will always get to me. I can rely on iphone's "scam likely" notification and just not answer those, which helps.
If the latter (and whatever similar feature android has) were somehow perfect, scammers would have a bad time. But.. if they convinced (paid) some (more-)legitimate companies to have their outgoing calls show up as the same number as the scammers use, people would eventually learn that they have to pick up scam calls or else miss calls from their bank/pharmacy/whatever.
> if they convinced (paid) some (more-)legitimate companies to have their outgoing calls show up as the same number as the scammers use
In the US the STIR/SHAKEN[1] protocol adds source-verification. If/when this finally gets fully rolled out, spoofing caller ID without it being blocked is going to get much harder.
But, I'm sure the next step for them is to just go after the millions of small-medium business IP telephony systems that are either poorly configured with default/guessable passwords, or have wide-open security holes.
Many canaries are avoidable if you pay perfect attention - but people slip up, and even if they don't, paying perfect attention does increase the cost for the attacker. (And e.g. throwing out all Amex corporate credit cards (one example of the "banks" they use) as you suggest does reduce the value of stolen data too)
I wonder if the BIN/IIN (Bank/Issuer Identification Number[0]) of canary cards give it away. For this to work against sophisticated attackers, I'd expect a canary card to be indistinguishable from a regular one, though I still love the ingenuity of it.
edit: They mention this in the article, I missed it.
I think this service isn't aiming at individuals but at companies who want to know, sooner rather than later, if they've been breached (by storing Canary CC numbers either in with their actual CC numbers or on an internal honeypot).
This is a very shortsighted and short-lived idea - cyber criminals will find out the first digits of all these canary credit cards and never bother to test them. Even if multiple prefixes come into existence, unless they are mixed with normal credit cards, this won't ever make practical sense.
"Savvy attackers may start looking for patterns in the bank identification numbers (BINs) that we issue, and proactively deleting or excluding them from their dumps. For this reason we are in discussions with a number of banks to onboard their BINs to the system too, further mixing in legitimate cards with tokens."
True. But this only mitigate the problem, doesn't solve it. Whatever BINs they use, there must be some noticeable patterns, simply because these cards are NOT regular cards.
I've been trying to use this technique to alert banks (in Belgium where I live) of online fraud for a while but failed.
We are getting lots of phishing by text, email and hacked IMs. They use a bunch of redirections to get you to "login to your bank" with our security devices. In reality, they'll use MITM it and transfer money to some mules.
If we could have people fill in some canary bank account that would trigger a fraud alert at the banks, we could stop those payments a lot more easily.
The banks don't really seem to care because the payments are signed with the card and PIN of the owner, so they refuse to refund it. No loss to the bank, no action. :(
I used to do this all the time by hand when I was actively dealing with phishing sites. I'd submit credentials to the site and watch for it on our account login page to identify the perpetrator.
This is a late-2000s story but: I once worked for a small-time credit card emitter and the only money leaving us was the money from the transactions themselves.
It was quite interesting, AFAIK we had a range of CC numbers that we could use, and we had to "answer" to an API call (a "lower-level webhook", it wasn't HTTP) that provided all the user data for verification, and we had to authorize in a maximum amount of time (hard real-time). The verification happened entirely on our side, so it was even possible to reuse numbers by changing the CVV or expiration date, for example. At least that was how it was explained to me, someone could chime in and correct some mistakes here! :)
This feature later enabled some banks to allow the customer to change their "credit limit" as much as they wanted, or to block/unblock the card using a toggle in the app. But "real time confirmation" wasn't possible because of the hard-real-time constraint we had. I remember we had to reply very fast at the time, and could get punished if we had too many timeouts.
This might not be the reality on every country or region, but by giving everyone a dummy credit card in those conditions, the costs would be only of servers + personnel.
Of course, a partnership with zero dollars worth of transactions would make zero sense to the partnering bank, so they would obviously complain. But this here seems to be a special case where there's a previous agreement.
The Canarytokens service is clearly more or less an advertising expense for them. People that know and use it are more likely to buy their commercial offerings.
I'm wondering if you could build something similar with Starling Bank. They have virtual cards [1] and an API [2]. This is something I will have to explore later.
This idea has an obvious problem. It's a lot of hard work. How many people are going to be diligent in planting canaries etc? And if you are, can you be diligent for the next 1, 2, 3 decades? That's a lot of time spent on this.
You know what would be better? If every bank provided as a service/feature the ability to create single-use (and single-merchant!) debit cards. Revolut can do it, why can't huge banks do it as well? (BTW if you know one that does, let me know.)
Capital One does still have these: https://www.capitalone.com/digital/eno/ though caveat the feature is only available via a browser plugin, I assume because they want to be able to scrape your shopping habits/history in the process.
Now its available through their own app, and if/once you save actual card in Google Chrome, its directly available from Chrome in any credit card box. No need of Eno now.
Capital One can generate single/repeat use virtual cards, although it's for number-only transactions (online only?). I don't know if there's way to use them for tap/swipe transactions.
> Revolut can do it, why can't huge banks do it as well?
FWIW, I use Revolut and am a fan of their service. However, the one time I tried to use the single-use feature it just didn’t work for some reason. So I had to enter my “permanent” card details instead in order to proceed with payment.
Do you think companies avoid storing this data? There's no reason for them not to, so they do it. Look at the target hack for an example of real word credit card info stored.
Also, tons of companies have one-click payment options (ever order something from Chipoltle or Dominos app?)
Edit: It should be disincentivised, but look at any "punishment" for a data leak and it's cheaper for them to just lose the data
PCI-DSS compliance auditing is not cheap. There’s the incentive right there.
Individual retailers have no need to store actual cardholder information. All the payment platforms provide ways to persist cardholder information, in a way that allows it to be reused but never read.
There's a tradeoff. Card numbers in your db are a lot easier to move between payment platforms than tokenized card numbers. So many merchants get screwed by payment platforms that lock them out right in the middle of a large sale because the sudden increase in transactions looks like fraud. You gotta look out for number one.
> Why do you have a database containing customer payment information?
To seed with canary credit card numbers! But seriously, for widely implemented (i.e. not-proprietary) databases of CC numbers it would be great if there were more automated ways of seeding them with CC canaries. Sort of a "LetsEncrypt for CC databases." E.g. for CCs saved by your browser, I'd like to see a plugin that lets you use one click to seed that DB with a few random CCs.
The whole idea would be to reduce the burden on the end user, who we all know will probably not take the time to do this manually.
Interested in exactly when it becomes impractical. Personally I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for.
Honestly shocked by how much pushback I've had on this on this thread. I feel like I made a fairly innocuous comment that, essentially, was just suggesting that it's probably best practice to avoid storing customer card details in your own database. That seems to me about as uncontroversial as saying 'you should not be storing plaintext passwords', but apparently, judging from the replies I've seen, it's hopelessly naive, and you can't actually handle payments without storing CC numbers.
Which comes as a bit of a surprise to me, as in my day job I work on an e-commerce system that handles a billion dollars of credit card transactions a year, including stored payment methods and processing recurring billing - and we haven't got a single credit card number in any of our databases. So I kind of suspect it can be done.
> Interested in exactly when it becomes impractical
A couple examples where the Stripe model and scale of tokenization breaks down today:
- You're an airline and you need to have a digital wallet that stores payment details so you can buy your ticket on web, upgrade your seat on mobile, and buy a drink in-flight using the flight attendant's POS device
- You sell a product at high-risk of chargebacks that is not permitted by the major tokenization providers' terms-of-service (there are some surprises here that rule out several Fortune 100 use cases!)
- You're a $10B+ retailer where the difference between a 2.9% payment processing cost and a 1.6% payment processing cost pays for an entire team of people to focus on minimize processing costs by routing different payments to different gateways depending on fees (eg American Express goes one place, Visa goes another)
Now: if you are a mom-and-pop scale DTC shop selling only via web, you should probably be taking advantage of tokenization instead of storing credit card data yourself!
The PCI-DSS council does give guidance on how you handle credit card information securely when you cannot use a tokenization approach, and a lot of it boils down to what we'd consider foundational software engineering practices. (Don't let engineers have access to production data! Rotate your credentials periodically! Log events and maintain those logs so they can be audited!) It does increase your costs, complexity, and talent needs but it's also not an antipattern and there is relatively straightforward guidance on how to do so securely.
> Interested in exactly when it becomes impractical.
Having multiple payment service providers, for example (or the plan to do so in the near future).
Another example would be complex legacy systems (especially in the travel segment, constellations between various service providers get complex quickly).
> I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for.
No objections there :)
> you can't actually handle payments without storing CC numbers.
Now you're putting up a straw man. It's definitely not impossible, but in some circumstances, it can be very hard.
Also, somebody will have to store the PANs in a database in the end, even if it's just the payment service providers themselves. There are much less payment service providers than merchants out there, but by the same logic, that makes them a much more valuable goal for attackers.
> Mix it in with your store of saved card data or on payment gateways. An attacker who plans to test the cards (as they normally do when obtaining them) or attackers who try to use them will immediately advertise their presence, and your response team can spring into action.
Spring into action, to shut the barn door after the cows already got out?
Getting alerted is good, but it's unfortunate that infosec practice still has so much band-aids, theatre, and reacting after that doesn't work.
It's not a replacement for any prevention you apply first. It's not a band-aid. It's one more layer of what you can do and it is valuable to know when you were breached.
It's basically an answer to: do you want to know that things went bad shortly after they did, or months later?
It is, but not nearly all merchants accept Apple Pay or Google Pay.
Apple also seems to have no interest in letting other browsers on macOS use it, and I do most of my shopping on my mac, so I end up using my plain card number in almost all cases.
If the merchant seems particularly sketchy about security or not charging the card for more than what was agreed on (or makes it very hard to cancel their service), I need a one-time use card number anyway, since Apple and Google Pay don't yet protect against the latter.
The fact that the Payment Card Industry association hasn't been pushing this for decades, and it's up to some random infosec nerds to invent it, is yet more evidence that our entire payment infrastructure is fundamentally flawed.
Well to be honest Honey Tokens is being used since beginning of the 2000s, https://en.wikipedia.org/wiki/Honeytoken. I personally implemented them in a Bank, 20 years ago, generating some fake credit cards number (and other information) and having them being monitored in AV, IDS, IPS, Antifraud solutions like browser extensions, google search and etc.. So maybe we can say that I'm a random infosec nerd, but i guess, I'm not the only one, just that people and companies preferred to make it in silence, to actually catch the bad guys out there. We actually were able to catch internal people selling data and we could understand some ways data used to flow and work pretty tight with the Police to intercept and bust criminal groups.
Yeah, trust self important HN commentators like myself248 to imply incompetence throughout an entire industry while being completely ignorant about said industry.
people normally imagine that finance and specially banks, are just COBOL, mainframe and legacy, and even though it is part of their BAU, there are lot of innovation there, specially in the infosec/antifraud segments.
How would the operator of an ecommerce website have gotten their hands on these things to seed their data with them? Is this something they would've known to ask for?
So either you generate some fake but valid credit card numbers (i.e with credit card number generator) and set some monitoring on them or even better, you generate a credit card number with something like revolut, and as soon you get some transaction on that number, you know your database was leaked.. not hard actually to setup something like that.
I wouldn't say this is much of a solution to the problem, though. There's no guarantee that anyone will attempt to use your canary card before they use your actual card. For one-time purchases, a better approach is to generate ephemeral cards that can only be used for a short amount of time, where it doesn't matter if the card gets leaked. And plenty of credit cards do offer this service.
Think about it at the population level: nobody is impervious to theft but it lowers the window for an attacker to quietly steal money considerably and forces them to slow down their activity trying to avoid canaries.
To use a physical security analogy, real world bank robbery is a fool’s game now because of many measures which do not perfectly prevent theft but effectively reduce the profits & odds of avoiding capture. If attackers can’t get enough money to be worth the risk & effort far fewer people are going to try even though it’s still possible.
I'd say this is still putting the burden on the wrong party, though. For this to serve as a useful deterrent in general, canaries need to be quite common. Rather than hoping that thousands of customers will choose to use a canary and monitor individually, any company that stores credit cards should instead contract with an outside auditor, whereby any time a user stores a real credit card in the system, the auditor generates a canary and stores that in the database as well. This way it happens transparently in the backend, without having to ask users to do it, and immediately turns any credential leak into a minefield where you have a 50% chance of getting only one card before a canary goes off.
I don’t think those options are mutually exclusive: merchants should definitely be doing it but note also that many of the scenarios are things where you might want to verify your personal data storage or deal with internal business security.
I find it crazy that making a payment requires giving your full details. Using a credit card is less writing a cheque, more handing over a chequebook and saying "help yourself".
I dream of a payment system where payment generates some token, which the intended recipient can redeem, perhaps bearer ones for casual transactions, with support for periodic payments, revoking existing tokens or placing per-token limits.
Well, that was a rabbithole. I learned that (BME - Bolsa y Mercados Espanoles - Spanish stock market) is owned by a Swiss company. It blows my mind that countries sell off such important infrastructure, even if in this case to a friendly country.
It’s a common marketing point but people aren’t using blockchains because they cost more, take longer, and have no fraud protection. If someone steals my credit card, I’ll likely lose nothing other than some mild inconvenience updating numbers - and I don’t even need to do that with the modern systems like Apple Pay which use unique per-merchant identifiers.
That makes quite the contrast with the large sums routinely and irrecoverably stolen from blockchain users. If you want people to buy your random hashes, spend your time unbreaking the system instead of marketing it.
> If someone steals my credit card, I’ll likely lose nothing other than some mild inconvenience updating numbers
You might not lose money when someone steals your credit card, but someone does: either your bank or the merchant will suffer a fraud loss.
Consumer fraud protections with regards to credit cards are necessary because credit cards are fundamentally insecure technology and would be unusable if issuers didn't take on so much of the fraud risk themselves.
> and I don’t even need to do that with the modern systems like Apple Pay which use unique per-merchant identifiers.
Apple Pay is a big improvement over standard credit card technology. It's also closed and proprietary, and requires special equipment to use, on both the merchant side and the consumer side.
> spend your time unbreaking the system instead of marketing it.
Are you criticizing me for writing this comment on HN because I am not at this very moment writing code? In your mind, people can't even talk about a project they may be interested in or working on until the project is finished?
> If you want people to buy your random hashes
Are you sure you are not confusing stablecoins and cryptocurrencies? These are very different things. Stablecoins are transferrable sovereign currency obligations the balances of which are recorded on a blockchain.
Stablecoin tech can be used to allow consumers and merchants to interact with any type of monetary account as might otherwise be embodied by a debit or credit card, with similar business terms.
> That makes quite the contrast with the large sums routinely and irrecoverably stolen from blockchain users.
No doubt blockchain security needs to be substantially improved. It will happen, though!
It’s mitigation, not a perfect prevention, but those are extremely useful for security: if the attacker trips a warning after hundreds of charges are approved that still allows the bank to take action before the number is in the thousands of cards and makes it possible to retroactively revoke the transactions which were just approved. In the common case where someone is making purchases using stolen cards that allows goods never to leave the warehouse, and if the attacker slows their usage rate to avoid that they’re getting much less profit.
The responsibilities don't end when the breach happens. And while the cat is out of the bag, knowing it has happened is also important to contact customers, fulfil legal disclosure with regulators (eg. GDPR), and for triggering investigations and forensics.
I have uncovered flaws in online merchants this way, and notified them. They were usually grateful, especially so since the fraudulent charges failed.