What's crazy is that we've had public key encryption for over 40 years, and we're still publishing magic numbers on little pieces of plastic that give whoever sees them the power to take all our money without our consent.
Talk about the power of inertia when attempting to change consumer behaviors.
Also, we still haven't had an easy to use open tool set to make usage of Public Key Cryptography friendly to average Joes. No, GnuPG doesn't count - it's hard to use and cumbersome to configure it securely. You need to be a cryptographer or a mathematician to pick the right parameters in order to stay current and secure. Definitely not friendly even to most programmers.
IMHO, Keybase is the best example of a friendly tool for public key cryptography. It's really a shame that Zoom acquired them. I still think their stitching together a secure identity based on the aggregation of people's social media accounts is a great approach. Maybe that idea will be incorporated into other tools eventually.
One thing we’ve been able to leverage with cryptocurrency is that the “wallets“ have standardized some public-private key cryptography.
So some aspects of our products dont “need a blockchain for this” but the proliferation of standardized signing tools and size of the niche has made it extremely viable to cater to that market.
PGP had 30 years to get anywhere, and all we have are some pretty bad, cumbersome businesses releasing poorly integrated signing software on modern OS’ that even privacy advocates can barely tolerate for their email and other messages. People want to try to say the same thing about cryptocurrency over half of a decade or a whole decade but they’ll just have to wait for the Ivy league business school case studies to start coming out about the rest of us that have already figured this out for business.
Turns out changing consumer behavior isn’t hard when there are economic incentives to do so that benefit the consumer.
The problem isn’t the tools. It’s that there is no such thing as an operable PKI. The best PKI (by far) is the CA system, and the CA system is not a good PKI. It has so many holes, and the PKI evangelists don’t like it anyway, because it uses trusted authorities. The only other examples of remotely useful PKIs in existence are things like Signal/WhatsApp... and those are even worse PKIs, because TOFU PKIs are in practice authenticationless PKIs.
That only works because it’s hidden from the user, and can only work on highly regulated approved devices. Try giving a user a private key for making CNP transactions, and all you will have achieved is replicating the user experience of bitcoin.
Nah, I guess you've over simplified things. We can take card number/account number as address but again, you will need something to identify yourself to the bank as the genuine account holder and that's exactly where all kinds of sh*ts happens: uid/pwd are neither safe nor convenient; sms/text msg are not much better than uid/pwd; hardware token/csp which is much more secure but trust me, no one really want to go there as there are simply too much environment related quirks.
Then it doesn't reflect my experience of cardless transactions with a private key. Everyone uses it here to sign bank transactions online, for a popular phone-number based transaction service and for government official purposes, like signing your tax declaration form. I have it on the phone, and other apps can request a signature via an API, at which point I get prompted with information on who and what I'm signing for, and for my six digit PIN.
Onboarding is elaborate to avoid fraud, but not really complicated, and basically a necessity if you don't want to have to go to a bank office to manage your account and make transactions.
Except for drawing the rest of the owl... Getting a wallet, the knowledge of keeping it secure, transferring real money to crypto, knowing which crypto system to choose/use.... There's a lot of layers of "bullshit" before you get to "Just hit send".
I think most of the PKI trust issue, at least with regard to financial transactions, could be solved with government involvement. Governments could sign, or issue, PKI keys when they issue identity documents and business licenses. There's much less room for impersonation fraud if the keys used by businesses and people to identify themselves electronically are tied to their foundational identity documents.
Obviously, using government-controlled PKI for communications would be unwise, but there's very little risk to using government PKI for financial transactions as governments already have warrantless access to this data.
What are the downsides of EIDAS? They’re widely accepted and used in my home country and I personally have a great experience, although I wish there was a way I could generate my own private key and or at least acquire it so I could script my own solutions rather than depending on third party providers
Most of EIDAS is quite fine, but there are really stupid ideas in there. Remote signatures are signatures where the key user is not the key owner. The key is located with some service provider who signs with the user's key on request. The security of this is as useless as it sounds, but for many situations here in Germany it is the only option because there are no officially accredited providers for signature card certificates anymore. Therefore it is all the bother of digital signatures with the insecurity of analogue signature stamps...
Oh yes that is exactly what I meant by not having access to the keys, I use one of such services myself. I do however consider them a bit more secure than signature stamps as should the provider become compromised, their upstream certificate would be revoked, to my understanding this would invalidate all of the signatures. The same as any CA
I think a government controlled PKI authority, especially one that required real identity authentication, would possibly be the solution that would make the least number of people happy.
Even if you don't have to show government ID for every financial transaction, you need to show government ID (and, often, a lot more government paperwork) to open a financial account that can be used to make transactions. Your ability to move money is entirely predicated on the banks knowing who you are by linking your accounts to a tombstone government identity document.
Using PKI controlled by government to authenticate identity for transactions doesn't give government any more control over your affairs than it already has. All it does is add one more layer of authentication to the transaction process by allowing all parties involved to verify that their counterparty is the legal entity they claim to be.
I'm afraid if the government ID becomes ubiquitous, there's a danger of abuse that all systems will require it for everything and I doubt government will certify pseudonymous IDs. I'd say have banks as independent CAs, one or several keys per bank.
without even broaching conspiracy theories or secret organizations it's not like government has a stellar track record of dealing with data it promises will be kept secret and single-purpose (for example SSNs).
There would be huge room for impersonation fraud even with a government run PKI. Hackers would steal private keys from individuals and businesses using the same malware and phishing attacks that they use today for stealing credit card numbers.
The important difference is that credit card details are a shared "secret". You can't use your credit card number and CVV with Amazon without giving those numbers to Amazon, which is the exact same thing a crook would try to trick you into doing.
Whereas the whole point of a public key system is that nobody needs your private key. So we don't need to provide individuals and businesses with a way to give their private key to somebody else. The only reason you'd give your private key to somebody else is because you want them to seamlessly impersonate you forever, so there's no need to make it any easier than, for example, giving your kidney to somebody else.
Concrete example: A WebAuthn/ U2F "Security Key" offers no way to get the Private Keys out. If you want to "steal" the credentials used to get into my GitHub your best bet is to somehow trick me into physically packaging up the USB authenticator itself and sending that to you by FedEx or something. Or maybe you could try putting a knife to my throat or something?
I'm guessing "the CA system" refers to the Web PKI†. Any Public Key Infrastructure has a Certificate Authority role, so attempting to distinguish the Web PKI by the existence of this role makes no sense.
This also makes your next sentence nonsense, anyone advocating for PKI is advocating for a technology that has trusted authorities, that's how it works, it's as though you claimed computer evangelists don't like mathematics because it uses symbol manipulation.
And then it makes your next sentence nonsense, something like Signal isn't a PKI, it has no CA role, who "Janet" is on Signal is only a matter for you and Janet. Signal also isn't purely TOFU, you can insist on manually verifying every identity just as you can on SSH.
But even though I believe the Web PKI is the only successful public PKI there are plenty of other PKIs in use that are successful in a narrower sphere, and we're already in a discussion thread about such a sphere, the global banking system.
† The Web PKI isn't strictly just a PKI for the World Wide Web, it's actually a PKI for TLS services on the Public Internet. But it exists only because Netscape built SSL, and in practice its oversight is from the major browser vendors (most notably Mozilla but of course also Microsoft, Apple and Google). There was once a good chance the only TLS client implementation you had with any useful PKI enforcement was your web browser, today it's likely other tools on your system also do this... but always relying on the Web PKI.
Yes it's very close. The only reason it will fail for private citizens is the device needs to be easily auditable for correctness. The auditing process needs to be at least simple enough that children in public schools can be taught how to assess their PKI dongle to make sure it's real and trustworthy.
> What's crazy is that we've had C and other higher level languages for over 40 years, and we're still maintaining banking and industry backends in Cobol or other old tech.
The thing is something that works, and works well is hard to displace. Especially when it makes money. And when you are running a business and you have to choose:
- keep making money
- update system that is making money and hope it will work and it will stop making money
What really is the sane option here?
Also one other point the credit card companies are way better option for customer over say paypal.
Passphrases for credit card numbers, maybe? It'd be easier to remember "bobcat reissue onscreen crook" than a series of 15-16 numbers and you'd have essentially unlimited versions.
You'd have to limit yourself to a set of reasonably well-known words (and potentially weed out words that sound too alike). If we're very optimistic and assume the final set has 10,000 words, then one word has the same amount of entropy as 4 digits. Therefore four words and 16 digits are the same size of address space. You'd need at least five words. And you're quickly getting to the point where it's getting problematic to print these on the card in a font size that everyone can read (elderly citizens with bad eyesight included).
Card numbers are there for a reason: transactions without presenting the card, which actually are not a big problem as there are strict rules to follow and if frauds do occur, card holders are backed by charge-back policies. I guess all your concerns should really go to magnetic strip cards as there is virtually no way to tell fake card from genuine cards and that's the reason of EMV/PBOC card migration which just as you said, put strong cryptography into the chips on cards. But again, you still need card numbers to support transactions without presenting the card.
There's far better ways to do it if you can use online - I submit my card number to them, they pass the card number, their account number, and the amount to my provider, I authorise they payment with my provider.
If you're doing it over the phone though things like public key won't really work - to be long enough would make the numbers impossible to read out reliably, let alone the calculation I would need to do with my private key to prove I own it.
> There's far better ways to do it if you can use online - I submit my card number to them, they pass the card number, their account number, and the amount to my provider, I authorise they payment with my provider.
Visa does support this scheme and I hate it when it happens. I try to use my bank password the less possible. I also believe it's a huge phishing risk as people don't look at the URL.
I personally prefer that the bank assume the current risk. It's not like it's making them bankrupt to do it right now...
Nah, think again, in either the merchant's or bank's perspective: how can they tell you are really who you claimed to be? That's the core question and why all the hustle. And again, even some design can perfectly solve that problem, there are additional problems to resolve: how to implement that change with reasonable cost, within reasonable time frame and with good user experience? And most importantly, does not break existing facilities. That's exactly how we get into the current situation, there are simply too much historical burden and while someone is trying to make things better, there maybe more organizations are putting sh*ts into it. For example, I really don't know if there were any banks ever used 5 digits PIN, but there are POS machines only accept 5 digits.
Isn't what the GP mentioned how the "verified by Visa" works? You enter your card details, and you're redirected to your bank's site to authenticate the transaction. You use whatever (normally 2fa) method to login to the bank's page, OK the transaction, and are redirected back to the merchant's site.
Online you don't have to prove your account ownership to the merchant, just the bank. The merchant tells bank "I want $50 from account 17", the bank then says "Hey user, prove you own account 17 and are happy to spend $50", the user says "yes that's me", the bank tells the merchant "transaction approved".
How does that chip work online? As far as I know, CCs around the world still depend on numbers.
For what it’s worth, in the US, chip is pretty much everywhere. Main difference is that it’s chip and signature vs chip and pin. I wish we’d switch to pins as well, but it’s not like it’s the dark ages or anything.
Except that 3D Secure is opt-in by the merchant. All you need to do is find a web store that is more than 2 years old and you can use stolen/skimmed cards all day long.
My primary card declines all non 3D Secure internet purchases unless I click the scary sounding "Open card to all internet purchases for 60 minutes" button in the bank app.
That's brilliant! May I ask where you're from? Our national processor was one of the first to implement 3D Secure but none of the banks I know about offer that kind of protection (even on my company card).
Not for long, it will be mandatory in the EU from the end of the year under the PSD2 regulations (though the deadline has moved back into 2021 for some countries, including the UK which is adopting them despite Brexit).
Issuers will start to decline card transactions for any merchants that submit payments that haven't gone through 3DS.
Hell yeah! Now we just need to get banks to stop using SMS 2FA and embrace an open 2FA standard like TOTP and our money (!!) will finally be almost as secure as our Facebook accounts have been for 5 years...
Instead banks should use WebAuthn. WebAuthn's credentials are directly bound to the DNS name. So anything that involves fooling the human like a phishing site can't work. The only site your authenticator can give the real-bank.example credentials to is... real-bank.example.
SMS 2FA can also be phished, so TOTP would still be better and WebAuthn is such a complete paradigm shift that it would take many years for banks to implement it. TOTP is so stupidly simple they could roll it out in a month, audits and all.
Not to mention that in order to have a decent WebAuthn experience, you need a Yubikey with NFC, which go for 30-60$ if I remember correctly. Cost of authenticators is why everyone switched away from RSA SecurID.
WebAuthn for relying parties (what the bank is in this scenario) just isn't very hard. And you don't end up with any long term secrets at all, so that makes the security story easier. But I sadly do not expect banks to adopt it anyway.
I don't see what a Yubikey with NFC is getting you here. For a laptop/desktop user any of the Security Key products in an appropriate USB form factor (USB C for some newer laptops otherwise USB A) would be suitable.
The high end phones are or in the case of the iPhone very shortly will be WebAuthn platform authenticators, there's nothing extra to buy. Apple released a video of the pleasant UX journey they want to promote, obviously being Apple it doesn't actually say this would work on non-Apple devices but I use it already so I know it does.
My bank never used SMS as 2FA. They supported mobile signature for… I do not even remember how long, at least 11 years now. TOTP was supported even before that and is phased out in favour of https://www.smart-id.com/
Yes, 3D secure leads to a different liability layout. Stores that don't implement it face liability on chargeback, whereas stores that do use it are protected, and the banks themselves take liability.
At least that's my understanding of it, might not be that clearcut.
Oh wow, now I'm even more amazed that more stores don't support it. I guess chargebacks aren't common enough to be worth paying a dev to upgrade their systems...
Nah, if the really card holder make a complaint to the card issuer, there will be a full charge-back by the card issuer plus a investigation fee and the store will have to cover the loss.
It may be annoying if one is not used to take care about own transactions safety and is willing to shift this responsibility to some other entity - of course this convenience has a cost.
Well, I already moved to Paypal whereever I'm forced to do this dance. It is also completely unusable for me when travelling, because I like to keep the stuff to authorize unlimited transactions from my bank account at home.
Use using credit card numbers is IMHO a very conventient way of paying with the liability for fraud being setup exactly in the right customer-friendly way.
I have two options, both provided for by the bank.
1. I have a dongle that creates a number code when prompted.
2. My phone is set up for 2fa, again through the bank. The screen shows the same keyword as the website and I enter a pin into my phone to authorize the transaction. I can't remember if I need to use the fingerprint option on the phone or if that's just for the bank's app.
For my bank, I scan a QR code in the bank app. Then, on the phone it shows me who I'm paying, how much, and an appove or deny button. It also allows me to select the account that the money will actually come from.
Yeah, I actually need to login to my online bank to confirm most of my online Visa transactions (at least for the first time with a particular merchant).
I used to think the same thing, but it turns out it actually makes sense (at least in the US): the vast majority of credit card fraud is counterfeit cards, not stolen cards. Requiring a chip which can’t be counterfeited from a list of lifted CC numbers (and sometimes track codes) solves most of the problem as far as card present purchases are concerned. That and shifting more liability to merchants if they don’t support chip readers.
My card has a PIN but the PIN is actually quite dangerous. If someone gets my PIN, then it fraudulent transactions become my problem. Whereas a stolen credit card number is a problem for the bank or the merchant.
My bank has programmable pins. So one pin goes to account X, and the other goes to account Y. It's super handy when travelling so we can have our "per diem" attached to one pin, and then have another pin for things that would fall outside of that purpose.
PIN is not going to help you as transactions made with PIN will be deemed made by you and you are most likely going to cover the loss if fraud did happen.
At least in the US, to be fair, they don't really take your money but rather the bank's money. Credit cards tend to be much more lenient and generous with fraud protection (among other benefits) in the US than in some other countries in which I've had cards.
The prevalence of credit cards has baffled me for decades now. I admit I have one, but the only thing I need it for is to buy things from webshops that don't cater to the Dutch market. Every webshop that's vaguely aware of the Dutch market supports iDeal, which is specifically designed to handle internet payment and doesn't involve sharing any sensitive information with merchants or other unknown parties; my bank handles authorization of the payment, and I tell my bank to authorize the payment.
I admit the ability to reverse a credit card payment is nice, but that mostly means that it's also a risky form of payment to accept for the merchant. They might send the goods and still have the customer challenge the transaction. And of course you still pay for this; credit card transactions are relatively expensive.
Yes, because the banks are not the ones who should be protecting the consumer. There are consumer protection laws in place to do the same thing the credit card companies seem to take care of from my POV :)
Just curious, what exactly are these laws? Unreversible transactions front loads the burden of verifying inauthentic sales/services onto the consumer or government, doesn't necessarily provide a mechanism for returning a consumer's money when inauthentic merchants do show up, and restricts consumer choice either through having to be more discerning than a credit card user or relying on a government program to oversee merchant authenticity.
I absolutely agree that banks should not be the ones discharged with consumer protection but unreversible payments are not nearly as beneficial for consumers even if insured in some ways by the government.
Protecting the consumer with chargebacks or regulations quickly becomes "Only big corporations can afford the risk of selling to consumers, small businesses can't risk losing 15$ on every transaction (on which they also pay 3%)"
I'd rather have a market protecting me with verified reviews and as close to zero costs for sellers. Not unlimited refunds that put small sellers out of business, leaving only Amazons and eBays.
But if the seller doesn't fulfil their end of the bargain, the bank will do a refund AND the seller will be kicked out of the system or prosecuted if they're actually defrauding people.
Banks have developed and signed off on the ideal system; THEY are saying the system is safe, therefore THEY are responsible if something goes wrong with your payment.
You should use a credit card for online purchases when you can in The Netherlands. With IDEAL you don't get the ability to do chargebacks, and most webshops will charge the consumer the same amount of money for an IDEAL and a CC purchase.
Not using a CC is just leaving insurance money on the table for no reason. I've done chargebacks after getting fraudulent goods transferred over with relatively little hassle, and would probably never managed to reverse a bank transaction.
Counter intuitive, IDEAL is not protecting you but the merchant: you still need something to convince your bank that you are the account holder, and those credentials for sure can be lost for some reason and then ...
I'm of the opinion that the EU should work to make all these national payment systems cross-compatible. They've already done it for regular money transfers (SEPA). They've already done it for government identification (eIDAS). Now it's time to put an end to the national insularity of online payment systems (NL: iDEAL, BE: Bancontact, DE: SOFORT, SE: Swish, PL: Przelewy24, ...)
Honest question: What's the point of even having these online payment systems when there is SEPA? When I pay by credit card, they send me through a UI flow where I authenticate with my online banking (from the bank who issued my CC). Why can they not just do the same with SEPA and redirect me to my online banking to have me authorize a SEPA money transfer?
That UI flow doesn't exist for SEPA transactions, which is exactly why these systems came to be. Some of these systems already existed before SEPA came to be in 2014, which necessarily made them national systems (before 2014, cross-border transactions used to be complicated and cost money, even if both countries used the euro).
IIRC, SOFORT used to just ask you for your banking credentials, and then it would just log in to your online banking and put a regular transfer through.
Amazon.de does a nice job by offering direct debit: you put in your IBAN and they automatically debit your account, which works across SEPA. But this seems very fraud-sensitive (you could put in anyone's IBAN), which is probably why it's not more common.
Steam supports it, as do the big local webshops, like Bol and Cool Blue. (No idea if Amazon does; I haven't checked there in ages. I don't think Amazon.com ever did.)
I was shocked to hear that my mastercard which I always use with CVC and 2FA or PIN actually works like a normal third world mastercard in some places. So while the security problem is kind of solved where I live, if someone stole my CC details they can still skim my card!
Obviously I can block it for all transactions abroad but that doesn't seem like the best idea either.
The only working solution is to generate temporary card numbers for international transactions, but that leads to the shortage issue.
Isn't that a feature to make sure you can use it when you travel? Not everywhere supports chip and pin, do they? Has it ever been rolled out in the US, for example - or is 2FA something everyone can get? (I know it wasn't generally a thing before I moved).
Chips are widespread in the US (as well as contactless). US banks don't bother with PINs, but most of the PoS systems deployed to deal with chips can support PINs if the card requires it.
thanks. I've not been back for over 7 years, and that could have changed. I worked retail, and a few banks supported contactless at the time, but not many people actually had it (or perhaps not many used it).
That's what you get with security that's been patched on after the fact. It's basically optional security, which isn't real security at all. We need something that's been designed from the ground up with security in mind.
Right now all of the burden is on the credit card companies. Any fraud is their liability.
If we switch things up, and implement something like passwords or pins, WE get the liability. That’s worse than our current situation. And given how badly people get hacked or phished, all it means is that consumers lose.
Right now, those “magic little numbers” work great, and in the case of fraud, we are protected. I don’t want the situation to reverse itself and have us the first to suffer from fraud.
Sure, but this is fundamentally the same deal as insurance: we distribute the cost across the whole population at a constant, low cost rather than ask individuals to take a big hit with low probability.
Unless you can eliminate fraud, those are basically your two choices.
Which is exactly the purpose of good security measures.
Bad or nonexistent measures and an insurance against fraud slapped on all prices is a local maximum. Good security measures which really push back the fraud and allow prices to drop the insurance premium is obviously a better local maximum.
You also don't have to eliminate 100% of fraud, just make it so rare that you can basically ignore the risk because it happening to you is as unlikely as being struck by lightning (or any other risk of life that people are comfortable to ignore due to it being vanishingly small). The classic credit card fraud with magstripes was the exact opposite of that: there was almost no credit card owner who didn't get hit by it, and while people generally didn't lose money due to reimbursement by the cc companies, they still lost time and nerves over some stupid interruption in their lives that was entirely unnecessary in the first place.
I myself had one of my cards suddenly deactivated by the bank because of alleged fraud (it wasn't even real fraud, just some heuristic going crazy over an actually intended payment). I was on a cruise ship in the Caribbean sea when it happened and all of a sudden couldn't pay my beers with my ship card anymore. Fortunately I had a second card with me that was working so I continued using that, but in order to switch my onboard expenses account over to it I had to spend some time at the customer service desk on the ship, where there was a row of passengers standing at phones, occasionally speaking with someone in various languages, but most of the time they seemed to be waiting in silence for some kind of response. It took me a few minutes of overheard conversation until I realized that these guys were in the same spot that I was, but less well prepared; they didn't have another credit card with them and thus had to call their banks back home in order to get them to unlock their accounts again.
The liability is usually with the card issuer (bank), unless the merchant fails to meet liability shift requirements - like processes a card via the manually entered numbers or magstripe, rather than the chip in the card if the terminal supports it.
This the way card networks have encouraged migration to systems that support tokens and cryptograms to limit fraud.
For card-not-present transactions (i.e., all online credit card transactions) the liability is the merchant's. There is no recourse for a merchant who is a victim of a stolen card, the money is simply removed from their account.
then those merchants should use the widely popular 3d secure system, which lets you enter a pin. by using it, they are protected from reversals by the terms of service.
so a system that prevents them losing a gazillion dollars is available, and they opt to instead lose the gazillion dollars. it's their fault, and they should lose that money. we don't need to tell them anything -we just need to point and laugh.
See quelltext's response. Or, have your customers ditch you for the convenience of Target/Walmart/etc. who can afford to eat the losses rather than make the checkout process more painful.
And then see customers complaining about the annoying extra steps. 3D Secure affects conversion rates adversely which means customers are generally happier without it and don't mind the fraud risk (as is consistent with the rest of this discussion on the thread).
Really? In Russia I haven’t seen a single store without 3D Secure for a loooong time. And they are doing quite fine. Maybe it’s just that US customers are lazy?
> Again I think this perspectivve is US centric and not global (?).
I'm not in the US or talking about the US per se.
I as a customer want 3D Secure because I don't want to deal with fraud at all but AFAIK it's not that liked among users. And I did run into issues where the 2FA setup my bank offered took a physical letter to initialize/reset and I couldn't actually buy flight tickets I quickly needed (ended up changing cards). So I can sort of see how people can get a bit annoyed as long as 3D Secure is a bit frictionful.
Online businesses would like it if it helps them avoid fraud as well. The problem is that conversion rates drop and so only few businesses implement/enforce it unless it's the law (see EU). Given how simple it is for a customer to ask for a chargeback I don't think there's a clear winner here for using 3D Secure except for acquirers and brands. Issuers don't really gain anything either given their already strong position when handling chargebacks.
There is next iteration of 3DS rolling out right now. Many countries adopted it already. It's designed, among other things, to minimize the friction for the buyers.
This is not strictly true in all parts of the world. While this is the “default” way a credit card works, in my country chips and additional two part authentication has been mandatory for many years. Any transaction over a certain amount has to be verified via OTP (often over SMS) or other authentication software.
Virtually every country other than the United States uses a cryptographic NFC and/or chip and pin system for in-person credit/debit transactions.
In most countries, the card number is only used for online and phone transactions. There's probably no way to do better than this without abandoning cards entirely in favor of some kind of device (or app) that has enough of a user interface to do a human-readable challenge response.
Practically all online VISA/MC card transactions at domestic online stores here in Finland are verified by 2-factor authentication using bank credentials (3dsecure etc.), it has been this way for over 10 years now.
the us has had nfc and chip for years. we still support swiping too. your statement was true for a few short years when europe did chip first. which was much easier there, since credit cards were not as common, and didn't exist since 1950 like in america.
we don't use a pin, because that doesn't help with fraud. most fraud is either online, or someone at the store, who can easily skim or see your pin. online you can use 3dsecure, which has a pin.
processing a transaction doesn't mean your money's gone. you can dispute any fraud charge for 2 months. so the pin doesn't do anything. and for bank accounts, where it's debit, and your cash is immediately taken out, we've had a pin since before europe had an atm card.
The USA is still rolling out chip support, with a date of 1 October for the remaining holdouts to use it.
The rest of the world reached that point around 15 years ago, including countries with high credit card use (UK, France) and high debit card use (Northern Europe).
In my small town I use only NFC via my watch, phone or tapping my card. If every place accepts NFC payments in this little town I would assume it's more widespread than you think.
I think it's just not widely known about/common usage in the US even though the infrastructure seems to be widely there.
Credit card fraud, as in transaction fraud, usually online. It's a lot less common for your physical card to be the issue in a fraud situation, so improving security there is moot
At that point why even show the number? It would be useless without the encryption. And if you have some way to enter the numbers so online transactions still work, then what is the point of the encryption?
I don't believe the majority of fraud is stolen physical credit cards
> And if you have some way to enter the numbers so online transactions still work, then what is the point of the encryption?
Why not allow plugging the card into the computer just like a yubikey for online payments? It would be quite difficult to pull off, but credit card companies can save a lot on fraudulent transactions if it is implemented.
Seems ridiculous to have to buy a device just to use my card. I would have to carry it around as well otherwise I wouldn't be able to use my card online
If you were able to do this I think you’d find card readers built into laptops would be much more ubiquitous. It’s very commonly an option on business laptops already (probably thanks to the US government making heavy use of contact smartcards).
And as for transactions on mobile phones, most of them have NFC as well; contactless payments could work there too.
There's no reason that with chip technology as ubiquitous as it is that card readers shouldn't be more widespread. The fact that they aren't right now shows that the market isn't there
It's honestly the issue is the card form factor. If you ditched the card form factor you could use USB or other common interfaces. The card form factor limits or requires it's own interface. Current cards with chips or contact less payment use a form of connection that PCs and Phones don't have integrated.
In Estonia the government issued ID works like that. This allows you to log in to your bank too. Although you do need your PIN codes on top of the card.
Something not clear from the article: The tech already supports longer numbers. Diners, Discover, UnionPay cards already allow up to 19 digits officially. The problem could be in the custom forms which think 4x4 is the right format, but the back-end should "just work" with them.
What I really don't understand is why the article makes it seem like a national problem given the prefix is assigned to the companies, rather than countries as such. (Although companies will get ranges and then assign specific IINs countries normally)
It seems that IINs are undergoing changes anyway and April 2022 is a deadline for everyone to support 8-digit prefixes correctly.
If twenty years of fighting banking websites has taught me anything, I'd never assume that the backend would "just work". In fact, if any bank decides to roll out a longer number scheme, I'd probably want to make sure that I wouldn't need their service for a few coming days, just to be safe.
Banking websites are not the backend. Backend here is what the card issuers do / how the payments are routed. The level of scrutiny between those is very different.
I’ve run into multiple issues already with poorly designed forms on sites that claim to accept Amex that freak out when I enter my 15-digit card number, I would love to see the mess that adding longer numbers would cause.
LOL, I guess their payment processor might be able to handle AMEX but they have no idea that some cards can be 15 digits or 19 digits so... Anyway, that seems to be reasonable some how. You guess what, I encountered some POS machines allow only 5(i typed it right, it's 5, not 4, not 6 or 8) digits of pin and unfortunately, my bank requires 6...
We still have a long way to go--my friend's bank called him up to say that his six-digit bank PIN was "too long" and that he should change it to four digits "for security".
Yeah officially the Mastercard and Visa networks support 6 digit PINs.
In reality there are so many POS devices out there that don’t support 6 digits, it actually ends up being safer to use a 4 digit PINs because the 6 digit PIN fallbacks are completely insecure and unreliable.
Doesn't AmEx own Diner's Club? If so, their CCV is usually 4 digits instead of 3. So the number becomes the 14 on the front of the card plus the 4 of the CCV for 18 total.
>the company decided to take makeshift measures such as reusing credit card numbers of discontinued cards after a certain period had passed since cardholders canceled their memberships. However, there are considerable risks of fraudulent usage
What are the risks here, and why aren't they already present by someone generating credit card numbers with a RNG? AFAIK credit card transactions are authenticated by at least expiration date and cvv, so there isn't a risk of reusing credit card numbers.
>and a source close to the credit card industry said, "Increasing the number of digits is the only real way to deal with the problem. There will likely be a shift toward increasing the number of digits in the first half of this decade."
They would need to EOL over-the-phone payments to do this. People have horrible diction and it's hard to tell the difference between b, c, d, and e when a particularly lazy lipped person says these letters (in addition to non-hex letters like g, p, t, and v). Then they use their own ambiguous phonetic system (b as in ball, c as in call, d as in doll will confuse anyone trying to distinguish between the three). Oh and this compounds on ambiguous sounding digits like 13 and 30; 14 and 40; 15, 16, 50 and 60; 17 and 70; 18 and 80; 19 and 90). It can't be done with DTMF digits anymore either.
All in all not a bad direction to go in. I wouldn't really miss phone payments.
Why don’t we teach schoolchildren the NATO phonetic alphabet? Seems like it wouldn’t take that long, and it would be a useful skill for their whole life.
But it'd take at least 3 generation to use in non-english speaking country since in different languages same letters might be pronounced vastly different. Then you have immigrants and foreigners who might now know this alphabet so clerks would still be able to recognize ad-hoc and NATO alphabet. In the end, it would extend requirements while not providing universal benefit.
Brazilian here. There is an equivalent alphabet in Portuguese, with different words for each letter, better adapted to the Portuguese language. It's ubiquitous in the Brazilian armed services.
Phone service is always in a specific language, I don't see why the use of such alphabets would be harder in non-English-speaking countries than in English-speaking ones.
Not every country even uses Latin alphabet. That’s for one. And you wrote “such alphabets” whereas OP specifically named NATO one. If each country would have their own implementation it would be even more effort consuming and wouldn’t solve anything beyond what we already have.
"each country would have their own implementation" would not mean anyone has to serve all countries. Services only available in English today would only need to learn the NATO alphabet to remain fully available in English.
We should. There are so many adults who think it's cute to make up their own phonetics not realizing the whole purpose is to reduce ambiguity, not make it fun to spell things aloud.
As an adult who tries to remember the NATO phonetic alphabet but can't because I only use it once per month, I don't make up words "for fun" or "to be cute". I do it because I can't remember the NATO word. Compared to just saying the letters, the words I choose certainly do reduce ambiguity, even if using the NATO alphabet would go even further.
Some good advice I got from a HAM was to read license plates in your head using the NATO alphabet. Their letters are mostly random so you tend to see each letter at roughly the same frequency and it can be done daily without taking away time from your schedule. Being random also prevents you from just remembering the order of the words and actually associating them with their respective letters.
After doing that for a week or two (I was bike commuting at the time), I had it pretty much memorized.
This is mostly fine if only done for ambiguous letters and if the understanding is that it is done to reduce ambiguity. There is a contingent of people who painstakingly spell out every letter with a phonetic from their own system and it requires the listener to do a lot more decoding to the point of actually increasing ambiguity. "My name is Michelle that's M/N as in Nail/Mail! I as in Icecream! ..." Nichelle is confused about why we use words to spell out certain letters.
DTMF is actually 16 digits: 1 2 3 A 4 5 6 B 7 8 9 C * 0 # D. While most keypads don't have A B C D buttons, * and # are pretty much everywhere, and easy to distinguish, so adopting base-12 would be relatively easy.
To addresses? Mostly pointless. To a larger number space that had non-numeric representation, genius and probably inevitable.
If we allow for the representation to be 0-9 and then another ten letters selected for uniqueness and clarity, overlapped with appropriate non-roman pictographs, etc, the same 16 characters jumps to 600 quintillion range, or about 60 bits by napkin math.
That's more than realistically enough for hundred billion people to each have millions of real payment IDs with millions more one-time use ones that contained some sort of transaction hash for authorization.
Which conveniently fits in a 64 bit word with some left over. I suspect someone involved in the payment space already figured that out a long time ago, but no cataclysmic event has yet happened to de-rail the existing money train.
If you wanted to do that in IPv6 you'd still have the upper 64 bits left over :)
> What if they switched CC numbers TO IPV6 addresses? Insane or genius?
Depends upon how it is implemented as could go full on 1984 very fast without that ever being intended.
The whole aspect of a static fixed CC number you share with people is what really needs to change. A One Time CC per transaction would be more useful and negates many potential issues in a way that protects the customer and in turn the bank itself.
> A One Time CC per transaction would be more useful and negates many potential issues in a way that protects the customer and in turn the bank itself.
That's what Google pay does. It generates a new credit card number for each transaction that charges the CC you have on your account. It's kind of like a password manager for credit cards.
To what end? You want your card to be internet addressable?
Also, I'm not enthusiastic about trying to communicate an IPv6 address over the phone to the wage slave working at the pizza joint. You'd have to implement one of those address-to-word setups, which would make for some amusing card "numbers". How would you like getting a card with "chinky challis uta ablow wiry rehaul a carotin" on the front?
Credit card numbers can be easily generated, there are tons of generators online.
The right solution is not to have a number that you give out to random people who then gain access to your money. Also the righ way is not to trust the few giant credit card corporations to move all the money in the world
The right way (EU is introducing it) is that you get a payment request that you can paste into your bank app and there authorize it. See SEPA or PSD2
That isn't specific EU regulations. SEPA is both the way payments are cleared and EU rules so works cross boarder. It is the foundation (interbank infra) upon which PSD2 layers a requirement for what amounts to having APIs, and a requirement to make the API open-access, in the sense they can't privilege their own systems over these APIs. They solved (or at least it seems like they might) one of the bigger blockers of building fintech solutions: a level playing ground.
It's pretty easy to make a secure payment method for one-off payments or fixed-price regular payments. A lot of the value of credit cards is that you can use them to pay for things that do usage-based billing, without having to do anything after the initial setup.
That's what direct debits (Avtalegiro in Norwegian) are for. Works fine here. I only use my credit cards for buying things in shops or one off things online. And my credit card gets paid by direct debit.
Indeed, and in the Netherlands there is something similar to Avtalegiro as well, since more than 20 years ago. And depending on your bank, they even make it easy to reverse a charge up to three months after it has been made if you don't agree with it.
Direct debits have all of the dangers of credit cards and then some - you have to give out a numeric identifier, and unlike a credit card that number allows pulling directly from your bank account.
"Direct debit" can mean multiple different systems. In this case the Norwegian system the parent talked about sounds similar to the Finnish Finvoice system that can be used to (auto-)pay practically all bills in Finland - the system is known to users as "e-invoicing" (e-lasku) or, if used offline, as "direct payment" (suoramaksu).
The customer manually creates the billing agreement with a specific invoicer at the customer's online bank, and can set payment limits, notifications, and either automatic or manual approvals.
These are distinct from the "SEPA direct debit", which is not used in Finland domestically. Due to their rarity I think "SEPA direct debit" payments are usually/often disabled or each payment requires a specific customer authorization via their online bank (so IBAN of such an account cannot be used to get money out of the account).
How so? Avtalegiro is offered by the creditor via my bank. I click a box to allow it and I can also specify a maximum that they are allowed to take. Every time the creditor requests a payment I am notified before it is paid. I can cancel it or in some cases, such as a credit card monthly payment, alter it.
I can't stand it. Amex have implemented Express List to deal with this, and you can automatically add any new sites that you use your card in to the list. It doesn't even automatically trigger 2FA.
There's a risk. Have you ever had your credit card number expire? If a merchant has repeat billing, you don't even need to update with the new date and cvv. Code changes must now be made to make sure I don't end up responsible for someone's else bill because my card expired and someone issued the same card number with a different expiration date and cvv.
This is a simple issue to solve if you have all the issuers in line/on the same page.
Issuers simply need tabs on this.
This means, a) they only allow this for merchants that have had previous transactions.
b) They reset this when a card is reused (owner of the number changes).
Ultimately you just need a system that turns on stricter checks when reuse-induced issues are likely.
Once a card is reused the issuer simply needs to turn off the recurring billing laxness until the card gets close to expiration
again, i.e. a few years, which should suffice to detect any sort of problematic patterns.
This wouldn't affect the customer at all as any legitimate transaction would have been made with up to date expiry and CVV.
That isn’t true. Most banks don’t support the updating services that exist.
These subscriptions are supported by look at if the payment appeared as a “card-on-file” payment, and many banks will just keep accepting charges to expired cards.
If you’re lucky they’ll be using the PAN + expiry date to uniquely identify the card the payment belongs too.
The CVV isn’t stored by the merchant or their processor, and is only used for the initial checkout flow.
In most countries as a customer you’re not liable for fraud that occurs as a result of your banks failures.
In the EU this sort of behaviour is now heavily frowned upon, and with the slow roll out of Strong Customer Authentication will become unacceptable. With banks needing to prove that they’re compliant.
As for the rest of the world, regulators don’t always act with the interest of customer in mind. The US has a few notable examples of regulators protecting companies rather than consumers.
Also ivp4 in the sense that they have 16 digits, but have reserved 6 for card type and similar minutia. If they used all 16 digits, they'd have billions and billions of numbers available.
Assuming the last digit is a checksum and the first six are taken by the routing information, that leaves them 9 digits or a billion possible numbers per credit card issuer. Japan has a population of about 125 million. Are Japanese people cycling their numbers so frequently? Or are they big on ephemeral card numbers?
Is it not possible for an issuer to get a second prefix if they run out of digits?
I also wonder if credit card numbers aren't living on borrowed time anyway. Instead of adding more digits it might make sense to remove the digits entirely and only allow token based transactions. This does assume we figure out a way to do online purchases not using the digits.
> Assuming the last digit is a checksum and the first six are taken by the routing information, that leaves them 9 digits or a billion possible numbers per credit card issuer. Japan has a population of about 125 million. Are Japanese people cycling their numbers so frequently? Or are they big on ephemeral card numbers?
Credit cards - and payment methods generally - are in their Cambrian explosion phase right now in Japan, particularly given the pandemic. Every company, big or small, is pushing their own. I recently had to open a new credit card because the gym I wanted to join only accepts payment via their partnered credit cards. It came with a linked electronic money card (as well as having native integration for a different electronic money format) that has what looks like its own 16 digit credit card number, presumably for internal payment infrastructure reasons, and an offer to apply for a separate linked credit card for shopping in China, three other kinds of linked electronic money cards (one for a supermarket chain, one for a local transport network)...
Every shopping mall is pushing their card. My phone provider offered two olympic tie-in cards and a regular version (that would actually save me money if I could face going through the application). A theatre troupe I follow has a deep partnership with a card issuer and has their own branded cards. Bands have their own cards. Virtually any outfit with a loyalty/membership card is trying to turn it into a credit card. And so people can easily have multiple cards that they never use, because their loyalty card became a credit card but they're still only using it as a loyalty card.
Seconding this. I have multiple cards by SMCC, some basically given to me.
There's also a lot of "virtual credit card" offerings right now to pair with peer-to-peer payment apps. I imagine that those need to get cycled through frequently.
I wonder how big the incentive is, and if anything changed to enable this. As for the incentive, I'd guess they get transaction fees cut from some ~2.75% to 0.5%ish with their own card, and then some kind of additional cash (maybe $50-$300?) from the issuing bank for gaining a customer?
I don't know why it's exploding, but it also appears poised to explode here in the US too. I recently got a recruiter in my inbox for a startup "Guild Credit" that makes loyalty CC cards easy to issue for small businesses. Not sure what has changed recently.
> that leaves them 9 digits or a billion possible numbers per credit card issuer.
Issuers won’t issue every number, because that would make it trivial to enumerate valid card numbers. I know that PANs are printed in plain view, but they’re considered sensitive.
> I also wonder if credit card numbers aren't living on borrowed time anyway. Instead of adding more digits it might make sense to remove the digits entirely and only allow token based transactions.
It’s already happening! The tokenisation tech that powers Apple/Google pay can now be used by merchants. Buts it’s currently got very low uptake.
In the US retailers don't want to lose customer tracking they can do with fixed card numbers. This is why you see nonsense like "Kroger Pay" and other store specific payment apps. The hardware exists in nearly every terminal that supports EMV (Chip and pin/signature), the retailers just haven't turned it on.
Meanwhile, with my Samsung phone and its mag strip emulation, I can use my phone nearly everywhere anyway even if the store doesn't want to support NFC.
Tracking is traditionally done with discount cards, and they are compatible with all payment methods. And there are applications that aggregate those discount cards in software: a discount card is just a short ID, nothing fancy.
For consumer commerce, between the contactless and the smart chips this should be solved.
Someone else said the number is 'hidden' from the users but it's not hiding versus not hiding that's the problem. It's that for e-commerce the human has to transcribe the number by hand. You can't hide it, except via another system.
It's more of a no-pin limit. Payments above AUD100 can still be contactless, the POS terminal asks for the card's pin. I'm not sure if there's a hard limit at all to NFC payments. I've done some >$1000 transactions contactless.
The identifier is hidden from the user so if it's huge and complex that is no problem. My point is that we're talking about putting a lot of effort into overhauling the system to support a scheme that is arguably already obsolete. If we're putting in the effort we should just remove the old insecure digits entirely and focus on a cleaner modern solution.
The problem with that is the purpose of a credit card system is convenience, especially the convenience involved in being able to represent the identifier in an easily compact manner. When it's a few groups of digits, I can print it onto a card or piece of paper, and just plug the digits in whenever I need to validate the number and run a transaction. You can't do that with a token. What happens when I want to use my friend's computer to pay for something on Amazon but I haven't saved my card number? Or when I get a new card? I get that the current credit card system is monolithic and outdated, but it's purpose isn't to be modern, it's to be reliable, convenient, and adaptable, and it does a swell job at those things. There's absolutely no need to spend astronomical amounts of money to replace this system with something more modern.
That's an ideal. You have to be reasonable with the expectation that people are going to want to use their card in places where it isn't securely convenient to do so. Otherwise, you will end up creating a niche with no mass market appeal, and there's really no point in developing out infrastructure unless you're replacing the old one completely. Again, credit cards exist for convenience. If it's security you're aiming for, you're targeting the wrong market.
Chip cards are already secure because they use proper cryptography. But online payments are done without any cards whatsoever. For example paypal and webmoney are payment methods of their own.
With the EMV skimmer fraud is dropping. With 2FA on big transactions other frauds can be decreased. Some provider have a mobile app to accept the transaction and/or send a message after a transaction.
We could use nfc or some other protocol for submitting online payments via the physical card. This should help reduce fraud. Each token could be randomly generated based on some data stored in a chip on the card, time, etc.
Semi-off-topic, but does anyone know about the "churning" culture in Japan vs the US? What are the numbers? Here in the US you can generally expect sign up bonuses of a few hundred dollars, and a return of around 2% on your transactions, with category bonuses up to 5%. What do people get in Japan? I've just Googled it, and apparently some cards get 1 mile per 100 JPY (approximately 1%) - do some get more than that? What about sign up bonuses?
To give the European perspective, there's much less "churning", available, partly because of laws that limit transaction fees. Sign up bonuses are usually around $50-$150, and many cards have no benefits _and_ an annual fee. Cashback, if you do get it, is usually 1% or less, with exceptions going up to 1.5% or so.
For no annual fee card, Signup bonus without paying is around 1000-9000 JPY depending on running campaign. Some cards also offers bonus with paying, rate is vary but around 4-20% and max bonus is around 2000-10000 JPY.
I'm not very familiar but for annual fee card, signup bonus without paying is around 5000-30000 JPY and bonus with paying is similar rate and max is around 10000-100000 JPY.
To get max bonus, you should use cashback sites.
For transaction bonus, 0.5% return is basic (card from bank, gold card, random shop's card), 1.0% is standard for return-oriented card (like Rakuten, d-card), 1.2%-1.5% is top return-oriented card (like Recruit). Most return-oriented card is no annual fee.
* Now 3% is super prominent top return rate by LINE Pay card (that's no annual fee) but it's run by campaign until 2021/05.
Cards for airline is different story, maybe 1mile/100 JPY is good return on annual fee card (I'm not familiar but IMO airline card isn't majority due to less people travel to overseas).
Transaction fee for merchant is rumored below 2% for big player (like 7-11), around 3% is standard for real shops. Old contract may charges much more fee.
Big difference with US is that Most cards is monthly-clear style so less revenue from revolving credit fee. Card issuers trying hard customers to using revolving payment.
Beyond assigning IINs more judiciously, credit rating systems could drop the concept of "more accounts = better credit". It would discourage people from opening 7 credit cards to raise scores, when 1 or 2 would do.
Here in Japan there's no "more accounts = better credit" mantra (but zero card is bad for credit if you're not young). Oppositely "more account = reduces credit limit for new card" is mantra for credit card mania people.
I have mine with automatic payments on setup on them and a couple reoccuring bills on each so there is consistent activity and is paid in full before the end of the billing period for just this reason.
Credit scores are not a thing in Japan. Unless you already have a significant amount of debt, a shaky payment history or other risky factory they will give you the card.
I assume that it could work as a temporary solution but the article hints that this problem will likely become global soon. So, instead of moving numbers, it's easier to add some and increase the possible combinations.
15 digits can make for 1,000,000,000,000,000 different card numbers, leaving 16th digit for checksum. This is a completely made-up problem, caused by chopping the number into card type, bank id, etc.
I think it's better (for Japan) to force it into a global problem than a domestic problem. Then more people will care about fixing it and the issuers will retain international interoperability.
The first digits are a header identifying the type of the card, (visa, mastercard...) and probably other characteristics.
The main problem is that in Japan everybody has like 5 credit cards, because every big company has its own financial branch and issues cards (maybe to profit from a "reservoir" effect of the accounts?). So you have a credit card linked to your clothes shop, one from your supermarket, one from Rakuten (Japan's Amazon), etc. You get points when you buy things from the company linked to your card. I don't know how it is in US, but it certainly isn't like that in France for example.
"everyone" may be a bit extreme. There seems to be a national goal of going more cashless, but right now they're one of the most cash-based countries: https://www.statista.com/chart/19868/share-of-cash-payments-... Japan had 82% cash transactions compared to 14% in South Korea. From personal experience it's relatively normal to find a food place in Tokyo which has no card reader at all.
Everyone has a bunch of cards, they just don't use them.
We have a credit card for a mall, only for the free parking at said mall. We never actually pay anything with it, only scan it in the parking garage.
That said, cashless transactions have gone way up in the past year though, though the introduction of PayPay QR code payments (which means that waaay more small mom&pop stores accept a cashless payment system since adopting it is basically free), the government 2-%5% cashback cashless incentive that ended earlier this year, and the coronavirus.
It will be interesting to see the new cashless usage numbers next year.
I was going to agree it's a lot... but then realised every one of my grocery gift cards has a PAN attached, which means I'm going through 2-3 numbers a month myself. (Not in Japan) Then again, I expect the shop to recycle those faster than Visa.
> The main problem is that in Japan everybody has like 15 credit cards
This is a fascinating departure from my expectation, because when I was in Japan, I distinctly noticed that credit cards were not accepted everywhere. One could load money into Suica/Pasmo cards and use those at convenient stores, but I learned that carrying cash was imperative -- Japan seemed very much to be a cash-oriented society.
No your observation is correct. Japanese people have many credit cards but also pay a lot in cash, and small restaurants for example do not accept cards.
So they are now in the absurd situation where they do not have enough credit card numbers, but still many shops do not accept card payment.
(I edited my previous comment for realism: it's more 5 cards/person than 15)
You forgot that these 16 digits have a structure, with the 4 or even 8 first ones being determined by the type (visa, mastercard) and the bank/country, etc.
"The first six digits represent the country, brand, and the type of card issuer and other elements". The last digit is a check digit so it's actually only 1 billion.
If you can't give folks a number from SIXTEEN digits - something is wrong with the folks giving out the numbers.
Some answers to the excuses. The 6 digits at front, if a company legit runs out of numbers, ask for another prefix.
The reality. Instead of using the numbers properly (random ID to tie to a user account) they are probably putting some kind of structure into the digits that results in very inefficient use.
These are the 10 digits available PER PREFIX!
1,234,567,890
Even with a check digit you are at a billion numbers PER PREFIX! You can't get 125 million folks into this address space?
Your comment is ridiculous. The number has structure, you don't get random IP addresses if you're a company. You get a block, likewise card issuers get a block (BIN - Bank Identifier Number) then add in the checksum, that definitely means you can't just assign random number. Imagine you have a random number. Visa get's the number and a charge for $20. Who owns it? They now have to search through all possible issued card number to find the card issuer. However with the BIN, they can do a pattern matching and send the info to the card issuer to determine if the card is valid. Think of the implementation details, those before you are not idiots as much as you may think they didn't think things through.
My thoughts of this made the parallelism with IP addresses. Japan's issue can be solved by "buying some numbers" from much smaller countries.
The solution to reuse a number is bat shit crazy. Perhaps they can use expired cards (and not cancelled).
In the long run the sensible solution (just like IP addresses) is to move from a "IPv4" system to a "IPv6" that will largely multiply the available numbers per country/bank/entity and will solve the problems, for the next many decades.
What the OP said was that even with a 6 digit BIN and 1 digit check, you have 9 digits available per BIN.
For example, Mastercards start in the range 51 to 55. That leaves 4 digits of the 6 digit BIN to allocate to MC issuers. So that's a total of 50K issuers of MC world wide, then each of those issuers can have 1 billion cards.
So each issuer of a MC in Japan can issue a card to each member of the population and only use an eighth of their allocated range.
The problem isn't the individual card account ID, from the article, it sounds like Japan has been allocating too many BINs.
Assuming your calculations are correct, this means an issuer can only emit 8 cards in average to the total population.
Cards have an expiration, people lose them, break them, they change and come back to banks. For the main issuers it’s not ridiculous to have to issue 20 or 30 cards per account to a user in their lifetime.
Then people have multiple accounts (e.g. my mortgage was on a separate join account).
There’s just enough normal circumstances to run out of numbers, not even considering freak cases.
You understand that every possible prefix / range has a billion numbers minimum? That japans population is only 125 million?
And actually - you can near randomly assign numbers if you wanted, looking up card issuer is not difficult. Can basically issue card numbers in blocks of 100 if you wanted to reduce lookup tables a bit. This is already happening and available actually. Visa and other (apple) offer tokenization services to randomize your card number. Every phone number uses this type of system to enable number portability as well (you can take your phone number from t-mobile to sprint).
With 16 digits (1,234,567,890,123,456) you have 999 trillion numbers you can assign. As my original comment pointed out, the idea that we are running out of credit card numbers is absolutely ridiculous.
This story is ridiculous for another reasons. I worked for card payment (implemented credit card terminal application, internalized couple thousand pages of requirements).
The worst that will happen is that Visa/Mastercard will issue more BINs to those organizations. There isn't going to be a shortage of credit card numbers.
Not really that silly. For example, IPv4 address space was initially mostly partitioned in huge blocks to couple institutions and companies without regard for the future.
The difference is that Credit Card numbers are much easier to manage. The routing tables for Credit Cards are distributed by Visa/Mastercard to acquirers in the form of BIN files and it is extremely easy to add arbitrary mapping. So if someone gets an unnecessarily large prefix like "1" then the next day you can change it easily to ten prefixes "10", "11", "12" and so on and have a different organization for each.
Wouldn't the Luhn algorithm checksum [1] limit the available digits? It is specifically there so a one-off error doesn't result in a charge going to a valid other account.
You're talking about services like Google/Apple Pay right? Aren't these credit card numbers rotated by Google/Apple, and they just keep some mapping of userIds, transactionIds, and rotated cardIds?
My Citi card comes with a desktop app that can generate new numbers for online payments all the time. Beyond one-time use, I can generate a number that will work only with ‘x’ company for ‘x’ number of months. When I saw that, I assumed Citi+MasterCard must have at least 10,000s of times more numbers than customers
Yes, but in this case you can actually rotate those numbers easily without running into any issues, and on top of that they usually consume just one BIN per service.
‘/s’ usually means sarcastic when you see it on this site, but you’ve used it in a comment where you meant what you said (you do think it’s good we’re not wasting IP addresses in the same way). That’s why it’s confusing.
Amex for example have got only 6 digits per prefix. 15 digit card number, 6 digit BIN, 7 digit account number, 1 digit representing which card it is (1 for the first, and it gets bumped up with any replacements), and 2 digits for the position on account, allowing you to have 99 supplementary cards on account that can then be identified.
Obviously this is just Amex and it's an absolute non issue for them seeing that they own the entire 37 and 34 range, but I can assure you that virtually no financial institution actually use all of the 9 digits like that.
> If you can't give folks a number from SIXTEEN digits - something is wrong with the folks giving out the numbers.
I hate saying this but I'll say it anyway, as someone who has spent considerable amounts of time trying to get things done in Japan, I would say that you're right.
There is likely some ridiculously inefficient process which obviously requires changing but for cultural reasons it's hard to change things so they're stuck in this strange situation.
>In the case that the number of card digits will be increased, it is necessary to discuss within the industry whether the 16-digit cards that already exist should all be changed into new cards as well, or if the two types can exist alongside each other.
This is literally a non issue. Amex cards have 15 digits and a 4 digit CVV I've literally never had any issues with it.
It doesn't have to literally be incremented, my thinking was just that you can't really run out of numbers.
But then again if they used something like a 32 bit int and don't us sequential numbers, I suppose retrofitting for a 64 bit int might take a decent amount of work.
I've been doing exactly this for years with Revolut premium (and I'm sure many other "online banks" have the same service). It's like using a password manager, you don't have to worry about how your card details are stored anymore.
It is very neat although I got into strange situations a few times when I needed to prove I was the card owner for a refund or for insurance claims.
Don't you already get this with Verified by Visa and MasterCard SecureCode? You don't need new credit card numbers to do this.
But merchants don't implement it... because it's an extra step and consumers don't like it. The very last thing a merchant wants to do is put an extra step in front of someone just about to buy.
I don't understand how you think you can get a new number for each transaction without any extra step getting in the way? How does your card issuer know you want a new number and how much to set the limit?
Do you go to an app? That's a separate step. Consumers demonstrably don't want extra steps.
Do you integrate it with the merchant and do it automatically? Then it's no safer as there's no authorisation.
I wonder how this became a problem. Your CC number is not just 16 digits long. It's 16, plus expiration, plus the 3-4 extra security digits, plus your name, plus your zip code. That's quite a lot of entropy.
That's not true. The number is just the number, though it can be more than 16 digits. The initial six digits identify the card issuer. Expiration and CVC/CCV are security checks, but only work in combination with the number. Name is generally not verified, though is often used in fraud assessment. Address verification is uncommon, and almost unused outside the US.
