Your Credit Cards Will Never Be the Same Again: Meet Card 2.0(mashable.com)
mashable.com
Your Credit Cards Will Never Be the Same Again: Meet Card 2.0
http://mashable.com/2010/09/17/card-2-0-dynamics
73 comments
What you are proposing, while great for the consumer, will not happen any time soon, due to the inertia of millions of merchants and their existing POS terminals, and also due to the fact that very few people have smartphones.
Also, how widespread is the problem of people handing over their credit cards to pay for something, and the merchant types in a bigger amount than you want to pay? It doesn't happen, or happens negligibly often. The bigger problem is not that merchants get to ask for as much money as they want when you are there at the store paying for something, but that they now have your credit card number and can, if they are malicious, use it later, or sell it on the black market.
In comparison to your proposal, the new card being proposed can work today without any merchant making any change to their equipment.
And this new card will become very useful once they add something akin to SecureID: That is, after every swipe of the card, the credit card number automatically changes to a new one. This is done on the card, and on the credit card issuer server, so that when the user makes their next purchase, both the card and the card issuer agree what number is being used.
This would make it useless for people to steal credit card numbers. And having this built-in to your credit card, instead of having to go online every time, like some existing systems, makes it extremely convenient and easily adopted by users.
Basically, this would mean no change on the part of users, no change on the part of the merchants, and only change on the part of the card issuers (they need to upgrade their servers and issue new cards), which is great because it is the card issuers that are most impacted by credit card fraud, so they are the most motivated to make a change.
Also, how widespread is the problem of people handing over their credit cards to pay for something, and the merchant types in a bigger amount than you want to pay? It doesn't happen, or happens negligibly often. The bigger problem is not that merchants get to ask for as much money as they want when you are there at the store paying for something, but that they now have your credit card number and can, if they are malicious, use it later, or sell it on the black market.
In comparison to your proposal, the new card being proposed can work today without any merchant making any change to their equipment.
And this new card will become very useful once they add something akin to SecureID: That is, after every swipe of the card, the credit card number automatically changes to a new one. This is done on the card, and on the credit card issuer server, so that when the user makes their next purchase, both the card and the card issuer agree what number is being used.
This would make it useless for people to steal credit card numbers. And having this built-in to your credit card, instead of having to go online every time, like some existing systems, makes it extremely convenient and easily adopted by users.
Basically, this would mean no change on the part of users, no change on the part of the merchants, and only change on the part of the card issuers (they need to upgrade their servers and issue new cards), which is great because it is the card issuers that are most impacted by credit card fraud, so they are the most motivated to make a change.
That's true, there's still a security concern once you've swiped a payment, but in terms of this secure card, the fact that you need the correct PIN to even see what the credit card number is would make me feel a lot better about losing my wallet.
I've got no data on this, but I'm personally more concerned about a lost/stolen card being intentionally used by someone else rather than a merchant screwing me over.
Is it world changing? No, probably not. Is it a significant improvement? In my opinion, yes.
I've got no data on this, but I'm personally more concerned about a lost/stolen card being intentionally used by someone else rather than a merchant screwing me over.
Is it world changing? No, probably not. Is it a significant improvement? In my opinion, yes.
Most (if not all?) credit card companies will not hold you liable in the event your card is stolen. They also require you to get a new credit card number and report the old as stolen in order for this protection to exist.
Now the question is, are you going to trust that just because you have this security card you don't need to report the card as stolen / get a new card?
Now the question is, are you going to trust that just because you have this security card you don't need to report the card as stolen / get a new card?
> Now the question is, are you going to trust that just because you have this security card you don't need to report the card as stolen / get a new card?
No, but I'm going to trust that it's harder for the thief to make any charges in the time between stealing my wallet and me reporting it stole.
Also, if my credit card is stolen, I'd need to get a new one.
No, but I'm going to trust that it's harder for the thief to make any charges in the time between stealing my wallet and me reporting it stole.
Also, if my credit card is stolen, I'd need to get a new one.
No, I'd still report it missing because I would assume it would be possible to crack even though it appears secure to me. I don't know enough about encryption to say how likely, but of course I'd still report it. The point is that unless the thief has my code as well, there are no charges to wonder who's liable about. Your answer seems to suggest that you'd prefer the current method where some of your money gets stolen but it's OK because the CC company picks up the tab.
Except of course with the new super secure card it can't be the banks fault because it's secure - so any fraud must be your fault and so you are liable.
That's what they tried here with chip+pin cards
That's what they tried here with chip+pin cards
Actually I'm fairly sure it's only legal for them to hold you responsible to ~50 dollars in case of ID theft. Don't you think the CC companies would want to make you liable? Of course they would.
These are the same banks that denied phantom ATM withdrawals were possible and prosecuted people who reported losses for bank fraud.
Within days of introducing chip+pin (where you enter your atm PIN at the checkout to use the debit card) it was discovered that pin readers at all Shell gas stations, and a couple of major supermarkets had been compromised and were logging all the card details and pin of your ATM card.
The T+C of the card claims that since you must have revealed your PIN to somebody it's your liability. Until there was a massive public outcry.
The T+C of the card claims that since you must have revealed your PIN to somebody it's your liability. Until there was a massive public outcry.
In Switzerland, you get a 6-digit PIN, a chip in the card, and SecurID to log into online banking, but you are held responsible if unauthorized transactions go through.
Just if the transactions went through with your personal secret pin code. And even then it's certainly a case by case basis.
There's little need for your bank to double-check with you for credit cards, IMO. In fact, in the few instances where my bank has checked with me, it's been a pain in the ass. (Travelling or otherwise making unusual purchases.)
If you don't agree to pay a merchant, you dispute the charge after the fact and the onus is on the merchant to prove that you agreed to that amount and that they delivered the product/service satisfactorily, etc.
In 2 decades, I've probably disputed 5 or 6 charges. In every case, it took less than 15 total minutes of time, and averaged under 10. So, in 2 decades, I've spent an hour dealing with credit card issues that smartphones might solve. And believe me, I'm not shy about using the plastic, averaging $30K+ per year in purchases on the card to get the 1% cash back.
I'm just not sure I care about better security for my CC information, and I'm sure I'm not alone...
If you don't agree to pay a merchant, you dispute the charge after the fact and the onus is on the merchant to prove that you agreed to that amount and that they delivered the product/service satisfactorily, etc.
In 2 decades, I've probably disputed 5 or 6 charges. In every case, it took less than 15 total minutes of time, and averaged under 10. So, in 2 decades, I've spent an hour dealing with credit card issues that smartphones might solve. And believe me, I'm not shy about using the plastic, averaging $30K+ per year in purchases on the card to get the 1% cash back.
I'm just not sure I care about better security for my CC information, and I'm sure I'm not alone...
[deleted]
Looks like they've integrated a processor and keypad on the cards. Sounds like the problem you describe could be solved with an upgraded POS terminal, where the PIN is typed on the card, and transmitted thru the terminal[1] to the bank (with end-to-end encryption from the card to the bank).
[1] - Probably still need to rely on the terminal for the data transfer; smartphones aren't ubiquitous/convenient/permanently-data-connected enough. The card could either communicate with the POS terminal wirelessly through Bluetooth/NFC, or be attached face-up while entering the PIN code.
[1] - Probably still need to rely on the terminal for the data transfer; smartphones aren't ubiquitous/convenient/permanently-data-connected enough. The card could either communicate with the POS terminal wirelessly through Bluetooth/NFC, or be attached face-up while entering the PIN code.
Why not type in the pin code at the POS terminal?
All Credit cards (smartcards) in Europe (Visa, etc..) already have a chip integrated . So whenever you do a purchase in the store, you have to enter your pin into the terminal, to complete the transaction. No pin, no transaction.
I don't think that this credit card 2.0 is solving any problem at all.
Maybe the founder have never been to Europ and don't know that this exists here... imagine. hehe.
All Credit cards (smartcards) in Europe (Visa, etc..) already have a chip integrated . So whenever you do a purchase in the store, you have to enter your pin into the terminal, to complete the transaction. No pin, no transaction.
I don't think that this credit card 2.0 is solving any problem at all.
Maybe the founder have never been to Europ and don't know that this exists here... imagine. hehe.
That doesn't solve the problem Cushman mentioned (and clarified several times to thinkcomp in this thread): giving up all your credentials including PIN/"password" to the merchant's hardware, and trusting the merchant and its hardware.
What's needed is a device you own and control directly communicate with the bank. Cushman suggested using one's smartphone, but I think the card itself could serve that purpose. The card has a display, a processor, and a keypad: everything except a data connection.
What's needed is a device you own and control directly communicate with the bank. Cushman suggested using one's smartphone, but I think the card itself could serve that purpose. The card has a display, a processor, and a keypad: everything except a data connection.
That's just like a computer without even having the possibility to reinstall.
Just imagine catching a trojan horse on the phone, stealing your credit card info.
I prefer paying by PIN. The POS Terminal doesn't connect to the internet.
The way I see it is that it's helping with "wallet bloat". It's a gizmo the end consumer buys to convert a stack of cards into a single card. Everything else is icing on the cake that I don't really care about.
I would pay $15 for this device.
I would pay $15 for this device.
I agree. I'm biased, but I think phone-based technology is clearly better.
(I run http://www.facecash.com)
(I run http://www.facecash.com)
It's a step in the right direction, but (please correct me if I'm wrong) your system still seems to be merchant-initiated. I'm using my phone as a glorified piece of paper; the merchant scans my barcode and processes the transaction on their hardware, the same way they would with plastic.
That still seems ridiculous when my phone itself is a device capable of handling the transaction, yes? I should be scanning the register's barcode. I should be able to see what I'm paying for on my phone as it rings up. I should be able to authorize the payment using whatever securities I want on hardware that I own. I should be able to complete the entire transaction and walk out of the store without ever giving the merchant any information besides what bank I use.
All of that is completely possible with today's tech. Who decided that the future of electronic payment is a debit card in a different form factor?
That still seems ridiculous when my phone itself is a device capable of handling the transaction, yes? I should be scanning the register's barcode. I should be able to see what I'm paying for on my phone as it rings up. I should be able to authorize the payment using whatever securities I want on hardware that I own. I should be able to complete the entire transaction and walk out of the store without ever giving the merchant any information besides what bank I use.
All of that is completely possible with today's tech. Who decided that the future of electronic payment is a debit card in a different form factor?
Downsides of your idea:
1. Not everyone has, or wants, a smartphone. My phone doesn't even have a camera. People who work in certain high-security environments aren't even allowed to own phones with cameras.
2. Supposing hypothetically that I'm gonna have to "upgrade" to a smartphone at some stage, do I want to carry it around all the time? I always take my wallet, but I don't always take my phone. A phone is a much larger, heavier thing to carry around than a credit card.
3. When I do have my phone with me, it always seems to run out of batteries at an inconvenient time. I'd hate for the "completely uncontactable" problem to be compounded by the "you don't have any money" problem.
4. What happens when my phone (which I am now forced to carry around all the time and religiously keep charged) gets stolen? What authentication system proves that the person holding the phone and scanning the register is actually me? There's always "Enter your pin..." but that brings me to the next problem:
5. People paying with credit cards is slow enough already... I think your system would probably slow transactions down even more.
Anyway, to me it seems you're trading in a small, light system that works adequately for a heavy, bulky one that may be less secure.
1. Not everyone has, or wants, a smartphone. My phone doesn't even have a camera. People who work in certain high-security environments aren't even allowed to own phones with cameras.
2. Supposing hypothetically that I'm gonna have to "upgrade" to a smartphone at some stage, do I want to carry it around all the time? I always take my wallet, but I don't always take my phone. A phone is a much larger, heavier thing to carry around than a credit card.
3. When I do have my phone with me, it always seems to run out of batteries at an inconvenient time. I'd hate for the "completely uncontactable" problem to be compounded by the "you don't have any money" problem.
4. What happens when my phone (which I am now forced to carry around all the time and religiously keep charged) gets stolen? What authentication system proves that the person holding the phone and scanning the register is actually me? There's always "Enter your pin..." but that brings me to the next problem:
5. People paying with credit cards is slow enough already... I think your system would probably slow transactions down even more.
Anyway, to me it seems you're trading in a small, light system that works adequately for a heavy, bulky one that may be less secure.
Assuming for the moment that by some bizarre turn of events my system were implemented...
1. Why is this a problem? Obviously legacy systems will have to stay in place until smartphone adoption is as ubiquitous as credit cards are today, and the only person you're inconveniencing by using them instead is yourself.
2. My iPhone is smaller than my wallet, and is more indispensable for travel (and would be vastly moreso if I could use it for even a small portion of payments.) I guess this one is just a culture difference, but it looks like the world is moving my way.
3. In keeping with the above, you could still carry around your debit card if you want the backup. (Your phone could even act as a passive RFID backup, so you don't have to carry around the card.) But since it wouldn't be your primary method of payment, you would be able to up the security on it such that every payment must be signed for, and signatures actually validated. A bit kludgy, but that's how it is supporting legacy technologies.
4. What happens right now if your debit card is stolen? Except without the "Enter PIN" part.
But seriously, since this technology is customer-initiated, the security of it will continue to improve as security features on phones improve. Whatever my new phone supports — fingerprint, face recognition, geolocation — I can use to authorize payments, and the merchant never has to worry about it.
5. There's a tradeoff between security and speed, here as in all things. Maybe this system would wind up being a little slower than our current one, which provides almost no security... I guess that's a fair tradeoff for me. After spending 20 minutes finding my groceries, whether it takes me five seconds or 45 to authorize the payment isn't a big deal. And as smartphones improve, it will get faster and faster.
Anyway, if you think what I'm proposing is the heavier, bulkier, or less secure option, I'm not sure if you've thought about what a debit card transaction actually entails.
1. Why is this a problem? Obviously legacy systems will have to stay in place until smartphone adoption is as ubiquitous as credit cards are today, and the only person you're inconveniencing by using them instead is yourself.
2. My iPhone is smaller than my wallet, and is more indispensable for travel (and would be vastly moreso if I could use it for even a small portion of payments.) I guess this one is just a culture difference, but it looks like the world is moving my way.
3. In keeping with the above, you could still carry around your debit card if you want the backup. (Your phone could even act as a passive RFID backup, so you don't have to carry around the card.) But since it wouldn't be your primary method of payment, you would be able to up the security on it such that every payment must be signed for, and signatures actually validated. A bit kludgy, but that's how it is supporting legacy technologies.
4. What happens right now if your debit card is stolen? Except without the "Enter PIN" part.
But seriously, since this technology is customer-initiated, the security of it will continue to improve as security features on phones improve. Whatever my new phone supports — fingerprint, face recognition, geolocation — I can use to authorize payments, and the merchant never has to worry about it.
5. There's a tradeoff between security and speed, here as in all things. Maybe this system would wind up being a little slower than our current one, which provides almost no security... I guess that's a fair tradeoff for me. After spending 20 minutes finding my groceries, whether it takes me five seconds or 45 to authorize the payment isn't a big deal. And as smartphones improve, it will get faster and faster.
Anyway, if you think what I'm proposing is the heavier, bulkier, or less secure option, I'm not sure if you've thought about what a debit card transaction actually entails.
As much as I hate to link to a competitor, Cushman's idea is similar to what Cimbal is doing:
http://www.cimbal.com
Cimbal has all of the same downsides you describe here (and more--it's only on iPhone and no merchants accept it). FaceCash, which uses a consumer-side 1D barcode rather than a merchant-side 2D barcode, solves all of them.
1. We let you print your barcode (like a boarding pass) on a piece of paper that you can cut to business-card size so you can carry it with you in your wallet. No phone required, which also means no cameraphone required.
2. See 1.
3. See 1.
4. Your account is linked to an image of your face that shows up on the register whenever it's used, and it's pretty unlikely that a random phone thief will be mistaken for you.
5. It's the same speed as credit cards or faster.
http://www.cimbal.com
Cimbal has all of the same downsides you describe here (and more--it's only on iPhone and no merchants accept it). FaceCash, which uses a consumer-side 1D barcode rather than a merchant-side 2D barcode, solves all of them.
1. We let you print your barcode (like a boarding pass) on a piece of paper that you can cut to business-card size so you can carry it with you in your wallet. No phone required, which also means no cameraphone required.
2. See 1.
3. See 1.
4. Your account is linked to an image of your face that shows up on the register whenever it's used, and it's pretty unlikely that a random phone thief will be mistaken for you.
5. It's the same speed as credit cards or faster.
This is the first I've heard of your product, but I agree it does solve all the problems I mentioned.
I'm actually curious as to what the point of the phone-based side of your product is, then... surely pulling a barcode out of my wallet is quicker than loading up the facecash app on my phone?
I'm actually curious as to what the point of the phone-based side of your product is, then... surely pulling a barcode out of my wallet is quicker than loading up the facecash app on my phone?
> This is the first I've heard of your product, but I agree it does solve all the problems I mentioned.
That is what every startup founder wants to hear. :)
That is what every startup founder wants to hear. :)
The phone lets you do a lot of things paper (but mostly plastic) can't. Some we've released...
- Standardized electronic receipts with line item data available in real-time
- Instant and free peer-to-peer money transfers (you can use Bump)
- Set the tip on the phone when you're at a restaurant
- Storing multiple account numbers for frequent flier programs, insurance companies, school IDs, etc.
...and some we're still working on...
- Bill splitting
- Location based offers (coupons), automatically-applied when you pay
So there are a bunch of advantages to using the phone.
- Standardized electronic receipts with line item data available in real-time
- Instant and free peer-to-peer money transfers (you can use Bump)
- Set the tip on the phone when you're at a restaurant
- Storing multiple account numbers for frequent flier programs, insurance companies, school IDs, etc.
...and some we're still working on...
- Bill splitting
- Location based offers (coupons), automatically-applied when you pay
So there are a bunch of advantages to using the phone.
Your idea sounds great from a consumer perspective, and it's an absolute nightmare from the merchant's perspective. Merchants have a lot more money sitting in their bank accounts (on average) than consumers. The last thing they want is everyone knowing their account numbers.
Besides, the issue of who scans whose barcode is a red herring. Either way, the barcode (or RFID signal, or bluetooth signal, or whatever) establishes a bi-directional transaction, and at some point your account number will be transmitted to the merchant. How else would they know whose account to debit?
If you are simply suggesting using your bank as a proxy to hide that number, then you should look at NACHA's SVP:
http://securevaultpayments.com
No one uses it because the general problem of security isn't totally solved by introducing the bank as a proxy, and may actually just put more accounts at risk depending on the implementation because the bank has to be that much more open with the API.
You can see what you've paid for on your phone after it rings up with our system, which no other system lets you do. As it rings up, why not just look at the register?
Until consumers foot the bill for merchants' IT projects, I'm afraid what you're talking about just won't happen.
Besides, the issue of who scans whose barcode is a red herring. Either way, the barcode (or RFID signal, or bluetooth signal, or whatever) establishes a bi-directional transaction, and at some point your account number will be transmitted to the merchant. How else would they know whose account to debit?
If you are simply suggesting using your bank as a proxy to hide that number, then you should look at NACHA's SVP:
http://securevaultpayments.com
No one uses it because the general problem of security isn't totally solved by introducing the bank as a proxy, and may actually just put more accounts at risk depending on the implementation because the bank has to be that much more open with the API.
You can see what you've paid for on your phone after it rings up with our system, which no other system lets you do. As it rings up, why not just look at the register?
Until consumers foot the bill for merchants' IT projects, I'm afraid what you're talking about just won't happen.
"How else would they know whose account to debit?"
I hate to pull a single sentence out of context like that, but this misunderstanding is exactly the problem with the current system. Why should the merchant be debiting my account?
When you write someone a check, do you sign it blank, hand it to them, and then make sure they wrote in the right thing when it shows up on your statement? When you pay in cash, do you hand over your wallet, let the cashier remove the appropriate number of bills, and then look to see how much they took? That's what you're doing every time you use your debit card.
The reason we do it that way is because it's attached to this legacy system of what used to be literally credit cards. I* would purchase something "on credit", handing over my card so that the merchant knew I was vouched for by a reliable creditor. They would copy down the number and bill my creditor for the money later.
It almost makes sense for that kind of relationship. Debit cards were the first misstep, but at the time it was necessary to get around the logistical nightmare of checking my exact balance and debiting my account on every transaction. But now we're moving on to personal computers, and for some reason if I want to pay someone I still need to give them my bank account details. That's dumb and broken, and I can not believe that telling my bank to deposit an amount of money into someone else's account instead is a massive logistical hassle for retailers.
*I was born long after it stopped working this way, of course.
I hate to pull a single sentence out of context like that, but this misunderstanding is exactly the problem with the current system. Why should the merchant be debiting my account?
When you write someone a check, do you sign it blank, hand it to them, and then make sure they wrote in the right thing when it shows up on your statement? When you pay in cash, do you hand over your wallet, let the cashier remove the appropriate number of bills, and then look to see how much they took? That's what you're doing every time you use your debit card.
The reason we do it that way is because it's attached to this legacy system of what used to be literally credit cards. I* would purchase something "on credit", handing over my card so that the merchant knew I was vouched for by a reliable creditor. They would copy down the number and bill my creditor for the money later.
It almost makes sense for that kind of relationship. Debit cards were the first misstep, but at the time it was necessary to get around the logistical nightmare of checking my exact balance and debiting my account on every transaction. But now we're moving on to personal computers, and for some reason if I want to pay someone I still need to give them my bank account details. That's dumb and broken, and I can not believe that telling my bank to deposit an amount of money into someone else's account instead is a massive logistical hassle for retailers.
*I was born long after it stopped working this way, of course.
>But now we're moving on to personal computers, and for some reason if I want to pay someone I still need to give them my bank account details.
For what it's worth, paying bills in Europe works with the Giro system (http://en.wikipedia.org/wiki/Giro) which is the opposite of the US system. When a company wants me to pay a bill, they give me their giro number and an invoice number, and I deposit money in their giro account. They never get to know my bank account number, and I never get to know theirs.
I just came home from eating out, and the restaurant had a portable chip&pin reader, which is increasingly common. The waiter enters the amount in the reader, gives it to me, I insert my card, enter additional tip, enter my pin code, press ok, take my card, and hand the thing back to the waiter. We both get a receipt, and the restaurant gets my money without ever knowing my card details. It sort of solves the underlying problem.
For what it's worth, paying bills in Europe works with the Giro system (http://en.wikipedia.org/wiki/Giro) which is the opposite of the US system. When a company wants me to pay a bill, they give me their giro number and an invoice number, and I deposit money in their giro account. They never get to know my bank account number, and I never get to know theirs.
I just came home from eating out, and the restaurant had a portable chip&pin reader, which is increasingly common. The waiter enters the amount in the reader, gives it to me, I insert my card, enter additional tip, enter my pin code, press ok, take my card, and hand the thing back to the waiter. We both get a receipt, and the restaurant gets my money without ever knowing my card details. It sort of solves the underlying problem.
the restaurant gets my money without ever knowing my card details
I think what Cushman wants is for the merchant to present the customer with a QR Code, the customer scans this with their device and registers a transaction with their bank (possibly adding tip, etc). There are at several ways for the merchant to confirm the payment including notification from their bank, notification from the customer's bank, and notification from the customer's bank returned to the customer's phone (which the merchant could trivially scan and authenticate).
>It's still their hardware.
No, they lease them from their bank. :-)
But yes, there is still an attack vector there, and I agree that the best solution is one where the business owner gives me payment details, I complete the transaction using my own hardware, and they verify it using theirs.
I have a hard time seeing a solution built on smartphones gaining widespread adoption though.
No, they lease them from their bank. :-)
But yes, there is still an attack vector there, and I agree that the best solution is one where the business owner gives me payment details, I complete the transaction using my own hardware, and they verify it using theirs.
I have a hard time seeing a solution built on smartphones gaining widespread adoption though.
It's still their hardware.
That's true, but I think that's the smaller problem. Owning and using hardware built for fraud (presumably banks ordinarily provide merchants with the real ones) would be a serious crime that only outright criminals commit. With credit cards you need to worry about the marginal criminals.
That's true, but I think that's the smaller problem. Owning and using hardware built for fraud (presumably banks ordinarily provide merchants with the real ones) would be a serious crime that only outright criminals commit. With credit cards you need to worry about the marginal criminals.
If you credit the merchant's account, then your account will be debited by someone, by definition, whether it's your own bank on behalf of the merchant or the merchant itself. Whether or not you authorize one side or the other first is pretty much irrelevant because the other will happen very soon (usually milliseconds) after. Either way, someone will need to keep track of the numbers. I think you're making a big deal out of what to me seems to be the least broken part of the payment system.
Really? You can't see the practical difference between these two flows?
The Way It Obviously Should Work:
Me -> my bank: I want to pay this store $10. Here's my password. My bank -> the store: Here's $10 from Cushman. The store -> me: We've got the money. Here's your stuff.
The Way It Does Work:
Me -> the store: I want to pay you $10. Here's my password. The store -> my bank: Cushman wants to pay me $10. Here's his password. My bank -> the store: Sounds good to me, here's $10. The store -> me: We've got the money. Here's your stuff. And I promise I didn't save your password or anything.
I'm obviously not an expert in this stuff at all, so I don't know how broken that is in economic terms, but it's obviously broken.
The Way It Obviously Should Work:
Me -> my bank: I want to pay this store $10. Here's my password. My bank -> the store: Here's $10 from Cushman. The store -> me: We've got the money. Here's your stuff.
The Way It Does Work:
Me -> the store: I want to pay you $10. Here's my password. The store -> my bank: Cushman wants to pay me $10. Here's his password. My bank -> the store: Sounds good to me, here's $10. The store -> me: We've got the money. Here's your stuff. And I promise I didn't save your password or anything.
I'm obviously not an expert in this stuff at all, so I don't know how broken that is in economic terms, but it's obviously broken.
There are no passwords transmitted in the banking system at the level you're talking about. Your PIN is never transmitted whether you're using credit card fund capture, ACH for debit purposes across banks, or on-us transfers within banks. Your web password is entirely irrelevant to all of this.
If things worked the way you think they do, I'd agree they're broken--but they don't work that way!
If things worked the way you think they do, I'd agree they're broken--but they don't work that way!
I'm not talking about a web password. (And I obviously know more about what I'm talking about than that— come on.)
When I pay with a credit card, every piece of information used for the transaction (Name, card number, whatever else) is stored on the magnetic stripe of the card. That set of information — the information needed to convince my bank to send you money — is what I'm referring to as my "password", and that password is given by me to the merchant for every single credit card transaction.
I'll admit I don't know how the debit infrastructure works, but I do know that I must enter my PIN on a pad owned by the merchant. That is transmission, and it's completely out of my control.
Aside from naming, how does the system not work the way I think it does?
When I pay with a credit card, every piece of information used for the transaction (Name, card number, whatever else) is stored on the magnetic stripe of the card. That set of information — the information needed to convince my bank to send you money — is what I'm referring to as my "password", and that password is given by me to the merchant for every single credit card transaction.
I'll admit I don't know how the debit infrastructure works, but I do know that I must enter my PIN on a pad owned by the merchant. That is transmission, and it's completely out of my control.
Aside from naming, how does the system not work the way I think it does?
It's not out of your control. Just don't use it if you don't like it.
I really don't see the problem that you're talking about. When you pay with a credit card, nothing happens with your bank at all. You pay your bill by check or on-line 20 to 30 days later, and only then does your bank get involved because you told it to. When you pay with a debit card, your bank is informed that you have authorized a fixed amount to be withdrawn. You could also do that through a bank web site or by writing a check, which has your account number on it. Not that much different, really.
I really don't see the problem that you're talking about. When you pay with a credit card, nothing happens with your bank at all. You pay your bill by check or on-line 20 to 30 days later, and only then does your bank get involved because you told it to. When you pay with a debit card, your bank is informed that you have authorized a fixed amount to be withdrawn. You could also do that through a bank web site or by writing a check, which has your account number on it. Not that much different, really.
"When you pay with a debit card, your bank is informed that you have authorized a fixed amount to be withdrawn."
See that passive voice hiding the problem: The bank is informed by the payee that I've authorized the transaction. I think it would make more sense for me (as the owner of the money) to do that.
See that passive voice hiding the problem: The bank is informed by the payee that I've authorized the transaction. I think it would make more sense for me (as the owner of the money) to do that.
Theory aside, has this ever been a problem in real life for you?
"Merchants have a lot more money sitting in their bank accounts (on average) than consumers. The last thing they want is everyone knowing their account numbers."
Why would they? The only thing anybody could use that information for is for sending them money. Here in the Netherlands, those account numbers normally are on the company letterheads. Is that different elsewhere?
Why would they? The only thing anybody could use that information for is for sending them money. Here in the Netherlands, those account numbers normally are on the company letterheads. Is that different elsewhere?
Actually, I just wish that US banks would get up to speed with the Chip & PIN thing Europe has been doing since the '90s.
Every time I buy groceries here in England, I get grief about my ancient relic of a Visa card that doesn't even have a chip on it, and thus requires swiping through a reader like the cavemen used to do and then signing a piece of paper.
About every 3rd visit, I get to have a manager called over and explain that I come from a primitive country where the banks still do things the old way.
It's embarrassing.
Every time I buy groceries here in England, I get grief about my ancient relic of a Visa card that doesn't even have a chip on it, and thus requires swiping through a reader like the cavemen used to do and then signing a piece of paper.
About every 3rd visit, I get to have a manager called over and explain that I come from a primitive country where the banks still do things the old way.
It's embarrassing.
I think UK was also the last in Europe to use chips on the cards, which, as far as I know, are the French invention. I remember using their specialized cards with chips there twenty years ago only to make some phone calls.
By the way a lot of elementary security issues with cards are there because all the mechanisms still have to allow Americans to use their magnetic stripes, allowing simple tricks with them that would otherwise not be possible. On another side, chips are no silver bullet when it comes to the security. There are a lot of possible attacks, just some specific set of them would be excluded by only having chips. So no matter how it's popular among the geeks, the real-life solutions to real life problems are not purely technological and probably will never be.
Still, as I live in Europe, I'd personally like to have the cards without the magnetic strip.
By the way a lot of elementary security issues with cards are there because all the mechanisms still have to allow Americans to use their magnetic stripes, allowing simple tricks with them that would otherwise not be possible. On another side, chips are no silver bullet when it comes to the security. There are a lot of possible attacks, just some specific set of them would be excluded by only having chips. So no matter how it's popular among the geeks, the real-life solutions to real life problems are not purely technological and probably will never be.
Still, as I live in Europe, I'd personally like to have the cards without the magnetic strip.
Chip and PIN have one major drawback for you though: they shift the liability from the merchant to the consumer. With conventional cards you can contest a purchase and the merchant is out of pocket. With Chip and PIN it's like a debit card and typically you the consumer is out.
Hm? I have combined and separate Visa- and MasterCard-branded chipped cards. Insofar as I know, they work as credit/debit normally does.
Yes, but the card never leaves my hand, and since it's a challenge-response system, you can't skim the data off of it with a fake reader. This means that for someone to buy stuff in my name, they would need to steal my card and peek at my pin-code, and unless I'm a bumbling moron, I will notice if you steal my credit card.
Chip and pin was broken pretty thoroughly early this year:
http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-i...
Swiping and signing is heck of a lot faster than figuring out which to insert the card in this particular terminal, waiting for the damn machine wade through its various phases and navigating through a couple of menus, and eventually entering the PIN code followed by the green enter key.
But that's not the real problem, in my opinion.
With hand-written signatures I was pretty sure that if someone stole my card then with great certainty he couldn't replicate my signature in a way a professional hard-writing analyst could be fooled. Thus, I would have some buffer of justice against the period between stealing my card and informing the bank about it. They could just run the signatures and I would have a pretty strong proof that someone else counterfeited my signature.
With PIN code it's different. As soon as someone types in the correct PIN code, everything is kosher and validated. I can't prove it wasn't me. It doesn't really matter that you're supposedly the only one who knows the PIN code because it's dead easy to eavesdrop and then you're out of luck.
But that's not the real problem, in my opinion.
With hand-written signatures I was pretty sure that if someone stole my card then with great certainty he couldn't replicate my signature in a way a professional hard-writing analyst could be fooled. Thus, I would have some buffer of justice against the period between stealing my card and informing the bank about it. They could just run the signatures and I would have a pretty strong proof that someone else counterfeited my signature.
With PIN code it's different. As soon as someone types in the correct PIN code, everything is kosher and validated. I can't prove it wasn't me. It doesn't really matter that you're supposedly the only one who knows the PIN code because it's dead easy to eavesdrop and then you're out of luck.
> Swiping and signing is heck of a lot faster than figuring out which to insert the card in this particular terminal
Well, there's always the issue of unfamiliar terminals, but that's a question of habit. I, for one, can complete a chip+pin transaction faster than most terminals can print a slip for signing.
Well, there's always the issue of unfamiliar terminals, but that's a question of habit. I, for one, can complete a chip+pin transaction faster than most terminals can print a slip for signing.
What country are you in? The machines in Zurich pretty much always take 8-10 seconds just to get around to asking for a PIN, then a further 5 seconds to confirm. This, in a reasonably wired city where both my bank and the merchant's bank are a couple blocks down the street. At grocery stores in North America, I usually swipe the card, sign the screen, and have a receipt in under 5 seconds.
The screen-signing solution is very fast - I was talking about paper-signing.
I'm in the UK now, but I'm talking about Denmark. I'm probably pretty biased by my experience with my Danish chip-card that still requires a signature here. I'm often asked by confused checkout assistants if I have a pen. Not fast.
In the beginning, when the chip-cards were rolled out in Denmark, they were very slow, on the scale of what you're describing, but it's much faster now.
I'm in the UK now, but I'm talking about Denmark. I'm probably pretty biased by my experience with my Danish chip-card that still requires a signature here. I'm often asked by confused checkout assistants if I have a pen. Not fast.
In the beginning, when the chip-cards were rolled out in Denmark, they were very slow, on the scale of what you're describing, but it's much faster now.
Agreed, most terminals I use are pretty quick - certainly a lot faster than waiting for a bit of paper to be printed, singing it and then the bits of paper torn apart.
Banks in the US do issue such cards, and in NYC at least I see them used. Are you certain that your bank does not?
Amex Blue has the Euro chip.
I will need you to cite your source on that claim. I have the original Blue, with the chip to which you refer, and can assure you that it is not the same chip as in "chip and pin".
It was marketed by Amex with a special RFID-esque reader that was designed to unlock your Amex "password vault" or some such silliness.
It was such a flop that the new Amex cards have switched to actual RFID (or similar technology) for use in "Speed Pay" or whatever, in that you need not take your card out of your wallet to buy things at CVS or Whole Foods (for example).
It was marketed by Amex with a special RFID-esque reader that was designed to unlock your Amex "password vault" or some such silliness.
It was such a flop that the new Amex cards have switched to actual RFID (or similar technology) for use in "Speed Pay" or whatever, in that you need not take your card out of your wallet to buy things at CVS or Whole Foods (for example).
You are correct, they are not compatible.
This is cool, but it solves the wrong problem.
The two biggest sources of credit card fraud are:
1.) Credit card numbers stolen from merchants with insecure systems.
2.) Credit card stripe information stolen by skimmers installed on legitimate terminals.
To combat these, you either need an entirely new system, (which would require every bank, everywhere, to buy into a new system, and thus will never happen) or something that generates new credit card numbers on the fly.
Hey, that would actually make this workable.
Have your bank generate ten one time use credit card numbers. Upload them to your smart credit card. Each time you swipe it, it uses up a CC#. After ten swipes, it's an inert piece of plastic until you reauthorize it.
The two biggest sources of credit card fraud are:
1.) Credit card numbers stolen from merchants with insecure systems.
2.) Credit card stripe information stolen by skimmers installed on legitimate terminals.
To combat these, you either need an entirely new system, (which would require every bank, everywhere, to buy into a new system, and thus will never happen) or something that generates new credit card numbers on the fly.
Hey, that would actually make this workable.
Have your bank generate ten one time use credit card numbers. Upload them to your smart credit card. Each time you swipe it, it uses up a CC#. After ten swipes, it's an inert piece of plastic until you reauthorize it.
I know there are banks here in Sweden where you can get one-time VISA numbers for online purchases. You enter a maximum amount where you guess your purchase will end up, you get a VISA number and expiry date and all that, and it's valid for one purchase. If someone stores that number or tries to use it again, they're shit out of luck because the thing isn't connected to your account, you are not liable in any way.
However, those are only practical for occasional purchases, I'd assume you would run through the numberspace pretty quickly if everyone had that by default on their cards. But it's a neat idea. :-)
However, those are only practical for occasional purchases, I'd assume you would run through the numberspace pretty quickly if everyone had that by default on their cards. But it's a neat idea. :-)
Chase offers this, as well as PayPal. In addition, you can generate MasterCard numbers that only work with a specific merchant, but can be used many times.
The biggest source of credit card fraud is that there's no standard way of proving that someone is in physical possession of the card.
Online transactions only require CC#/Exp/CV2 name/address etc which are stored on merchant machines and then compromised and released to the while.
A much more secure option would be to have CCs with built-in RSA key gen. Stealing the CC#s would no longer be enough to make a fraudulent transaction.
Online transactions only require CC#/Exp/CV2 name/address etc which are stored on merchant machines and then compromised and released to the while.
A much more secure option would be to have CCs with built-in RSA key gen. Stealing the CC#s would no longer be enough to make a fraudulent transaction.
The CVV2 is not supposed to be stored in any merchant system, that's it's entire point! A merchant who does store it is actually violating their contract with the card issuer.
They are also violating the terms of their contract if they make fraudulent transactions on your behalf (to put it mildly). Which is why we're not worried about above-board merchants committing outright fraud, but we are worried possibly internal security holes through which your credentials may leak. The CVV2 is on their hardware while the transaction runs, which makes it vulnerable to unauthorized internal snooping.
I don't know how merchants like Amazon handle fraud, but they don't use CVV2 because they don't bill you until items ship.
I don't know how merchants like Amazon handle fraud, but they don't use CVV2 because they don't bill you until items ship.
Can someone explain the benefits to me? Thinner wallet, I guess? I don't know if consumers have much to gain from the security, so is this targeted at banks trying to reduce fraud?
It's funny I remember the square guys telling me you can get in a lot of trouble for re-programming credit cards, surprised this technology isn't violating some obscure laws.
It's funny I remember the square guys telling me you can get in a lot of trouble for re-programming credit cards, surprised this technology isn't violating some obscure laws.
Visa/MasterCard, which create those regulations, are basically owned by their member banks. It's banks that issue credit cards. So if banks want to issue a new kind of credit card with technology like this, they'll rewrite their own regulations to allow it.
Visa and Mastercard are no longer owned by the banks, they both went public in the past couple of years and are increasingly acting as independent organizations.
I like the idea, but I’m putting my money on NFC integration into mobile phones.
Yes, manufacturers and services providers alike have been trying for years. Last time I checked there are huge issues with the security. This site seems to have good information on the topic: http://weblog.cenriqueortiz.com/touch-nfc/
Anyhow, I see much more potential when the ability to transfer money quickly is paired with an all-powerful computer in your pocket.
So we need someone to both figure out a secure process and provide apps/APIs to leverage that. Apple, anyone?
Yes, manufacturers and services providers alike have been trying for years. Last time I checked there are huge issues with the security. This site seems to have good information on the topic: http://weblog.cenriqueortiz.com/touch-nfc/
Anyhow, I see much more potential when the ability to transfer money quickly is paired with an all-powerful computer in your pocket.
So we need someone to both figure out a secure process and provide apps/APIs to leverage that. Apple, anyone?
Meh. Looks like more trouble that it's worth. With the new(ish) RFID chips, I can "swipe" a credit card without taking it out of my wallet. If I wanted a "secure PIN" feature, I could use my ATM card. Maybe I'll change my mind if my credit card were ever stolen, but until this, this seems like an sounds-good-but-is-actually-useless kind of feature.
Banks seem to be backing away from the RFID cards. My new card came without one. I called and asked them why and they said they were less secure. Personally, I love the new cards. Unfortunately, NYC cabs and CVS are the only place where you can find the readers.
Looks cool, anybody knows how the handle the energy issue?
I notice that the cards consume electricity. I wonder how long the battery lasts, and how they're replaced. Furthermore, there's the whole pressing against your card, and looking at the actual pressing action, it looks like you have to press them pretty hard (or maybe he just was). How durable is the card, really?
+1 I voite for thesi card + chip on the card. I really love it.
> the cards are as versatile as they are secure
I highly doubt that. History has proven to me that there's no such thing as secure when it comes to technology.
I highly doubt that. History has proven to me that there's no such thing as secure when it comes to technology.
They never said that they're perfectly secure, they said that they're as versatile as they are secure. As in "You're as smart as you are handsome".
'Consequences' will never be the same.
(bring the down votes, or just enjoy)
The way credit cards work is exactly wrong— to make a purchase, I have to hand over every single piece of information the merchant needs to convince my bank to give them money. Then they ask the bank for as much money as they want. My bank will /maybe/, in extreme cases, double check with me if I actually want to give it to them.
Now that smartphones are everywhere, we finally have the tech to implement electronic payments the way they should be— where the merchant provides me with /their/ id, and then /I/ tell my bank to make a payment.
But no, not today. "Card 2.0" makes my financial information more secure right up until the moment I swipe it, at which point it's just as stupid and broken as classic credit cards. Not intending any offense towards the founders, but I hope the era of your tech is short-lived.