Hacker News Reader

Comment by digler999 | Hacker News Reader

What annoys me is the expiry date and CVV. It seems like their solution to "more secure" is just to add more numbers. How about put the last 3 digits on the back, and call it the cvv ? How about use alphanumeric card numbers so we dont have to use as many digits ? Get rid of the expiry date used as validation. It's just more entropy, if you need more entropy then add another digit. It's just annoying having to type that crap in all the time.

View on HN

CVV is not just more entropy, it's handled differently: https://randomoracle.wordpress.com/2012/08/25/cvv1-cvv2-cvv3...

The whole point is that you can't skim the CVV2 from the magnetic data and then use it to make purchase.

In addition to not being on the magnetic stripe, merchants are also not allowed to save it, so if you steal a merchant's database of stored CCs, you don't get the CVVs.

That probably works approximately as well as how merchants weren't allowed to store the cc number itself.

Requiring CVV's for online transactions invalidates this security feature.

No, that's what the CVV is for. It's only for card-not-present online transactions.

(Yes, there are probably a lot of retailers breaching their PCI-DSS compliance by storing the CVV, but the point is they're not supposed to. Until we can do chip-and-pin or similar for online purchases, e.g. Apple Pay, the problem remains)

Expiry date: It checks that you're not using an old card that someone has just thrown away, often card numbers remain the same if you get a new one. This is effectively just specifying the version of the card, and is something that needs to be on cards anyway (so the user knows when they're no longer valid). Additional benefit is that it means your customer has just checked that their card is still valid.

CVV: Not sure why it's on the back, but the point of this is that it's a number that's not raised, so it's not recorded when using a credit card imprinter (less common than is used now).

That doesn't seem convincing, for the expiry. The issuer needs to keep track of cancelled cards anyway, and they should be cancelling expired cards anyway - it seems like a huge security hole to keep expired cards in an active state and rely on an expiry date check to reject transactions.

I assumed that it's a leftover from early days, before online card checks, so the merchant can check that the card is still valid (besides checking signature and ID or whatever). When introducing online checks of the magnetic swipe, expiry date was part of the data transmitted, and early phone/Internet payment systems relied on reconstructing the data present on the magnetic strip, to "fake" a swipe. Then it just stuck from there.

Expired cards and active cards generally have the same card number. I've certainly had multiple cards with the same long number across them. If you have to write the expiry date on anyway then why not use it?

Wait, I thought the expiration date was just theoretical. Nobody keeps the same card number that long without having the card compromised, do they? :)

All my debit cards have had the same number on them for the past 5 years (at least). No part of it is my account number. I know it by memory. I have no evidence that it's been compromised.

One reason for this is that it's at the discretion of the issuing bank whether or not to accept an expired card (in fact, you can get into trouble for handling this locally with some processors).

I believe it's a convenience thing for the end user, when issuing a new card - offer a couple of days "grace" - and arguably there isn't much risk associated with this practice: lost/stolen cards are always cancelled immediately.

exp date could be checked by the server. I just mean they shouldn't ask me to enter it during a purchase.

When I get replacement cards, they have the same long number on them, so the expiry date distinguishes between an old/lost card and my current one.

Expiring cards has a few other benefits as well. It ensures that the card company has a reasonably-recent mailing address for each of their customers. And it makes it easier to roll out security features/improvements to the actual card since they can limit the maximum age of any valid card. Also, merchants can use the expiry date to alert customers to re-enter credit card details prior to expiry for recurring charges.

> if you need more entropy then add another digit.

That would break so much as most of the message formats and batch files use fixed width fields. It's probably the same for the databases underneath. Changing to alphanumerics sounds nice but the check digit algorithm would have to change from Luhn to Luhn mod n. More breaking changes.

Banking systems are one of the ultimate forms of legacy, which is why most of the security additions have been bolted on. Just look at 3D secure - they added an entire subsection to the message format and it was still just another single factor auth method that nobody wanted and everybody hated.

> but the check digit algorithm would have to change

or just get rid of it. It was a relic from 20+ years ago when networks and computers were 1/100th the speed they are today. Let them enter invalid numbers. Let the server return an error (as it already does)

Similarly, once we did away with legacy electromechanical phone switches, the (phone area code) NANPA started allowing area codes with non-[0,1] middle digits. The big form of 10-digit numbers was retained and extended by relaxing a legacy constraint.

The check digit gets used today by e.g. JavaScript in input forms to indicate a typo in the card number.

To play devil's advocate, it may be useful to know when the card expires for a merchant who mightn't charge immediately. And maybe it's significant that the cvv is on the back so you couldn't just use a photo. And mixing letters and numbers is scary. But I agree. Maybe the solution is just having lots of entropy and reading it electronically, who really needs to read out card numbers over the phone?

I agree, keep the exp date, just dont use it to validate the transaction so I dont have to fumble with the keyboard and mouse to select stupid dropdown boxes. Let the server handle the case where the card expires tomorrow. I agree the CVV should be on the back, so just take the 3 numbers off the front and put them on the back.

I think we can all agree the correct model is a card that generates a globally unique card number for each and every transaction (e.g. coin failed, final). It should also have a 2nd factor authorization like CVV which is not embedded in the magnetic strip (can't be read by swipers).

Which is (roughly) exactly how EMV chips work. Crypographic challenges that result in unique tokens for every transaction.

Of course, EMV is still a broken piece of crap, because the signer can't actually verify the transaction being signed.

Plus, you still have to support plaintext between the EMV chip and the reader. This opens an entirely new class of places to steal card details (like PINs)

Recurring billing is a major feature of credit cards that some merchants find very important.

The first part is basically what Final claims to be doing:

https://getfinal.com/

I have a Final card. You have three options:

1. Use your real card number. I never do this. 2. Use a merchant-locked card number. I use this commonly for online pizza and other online shops I don't trust much. Once a merchant uses it, only that merchant can use it. 3. Use a one-time card. The number is used once and disabled. Good for one-off orders or skeezy purchases.

Overall I've been pretty pleased. I think the idea that card numbers should be disposable is awesome.

this is pretty solid actually, ill have to check it out.

edit, i checked it out. so 1) its no open to sign ups, and 2) you have to have pretty stellar credit to even be considered. so that leaves out most people.

Dang, I didn't know about the signup thing. I hopped on when they had an open beta period. (Kinda weird to say that about financial services!)

There are a tons of reasons to keep our signups closed for now. One non-obvious reason to most people is that it costs us money to lend out money to customers. Theres a ton of others we're working on solving in parallel too

Email me at aaron@getfinal.com and we can get you a code to apply :) We're working on broadening our underwriting criteria, but this is a complicated business overseen by an incredible amount of regulation, while also taking risk when we issue new lines of credit. Large banks throw around a lot of $ to make it work (a lot in this statement), but to start a new provider takes a lot of tactical decisions and iteration to grow in a safe and sustainable way.

Email me @ aaron@getfinal.com I'd love to hear more, if you don't mind. We encourage people to use the physical card and just treat it as disposable if it ever gets skimmed/breached/stolen/lost. We made sure it impacts none of your other relationships :)

I think the correct model has the customer authorize (sign) the specific transaction through a channel not controlled by the merchant.

An object which signs every transaction it's asked to sign is an improvement (can only be in one place at a time) but still broken (evil terminals).

I don't agree about the unique account number every time. That's nice to opt into when you want maximum privacy but it screws up things like loyalty programs or recurring billing where you actually do want a merchant to remember you.

What we can agree on is that there should be strong authentication. Apple Pay is the best system I've seen. It creates a unique but static account number that can only be used with Apple Pay, which has strong authentication which is also convenient (Touch ID), so it can be mandatory. Thus it doesn't matter if the number gets stolen as it's useless without Apple Pay.

subscription billing, its definitely one of those big, ugly, nasty hard to solve problems that no one really wants to talk about or address. Definitely falls into the category of "if its not broke don't fix it."

But payments in general are just totally effed and can't seem to move forward without some sort of fix. as a consumer its both amazing and incredibly frustrating. as a merchant it's essential. Imagine how much money netflix would lose if you had to auth payments every 30 days.

never thought of this.Simpyfying the number system would be beneficial for the consumer but also for the companies who make money out of this CC system

Reply on news.ycombinator.com