Visa gives merchants crypto card security guidelines Visa has published best practices for data field encryption (AKA end-to-end encryption) that call on merchants to always encrypt cardholder data. Data field encryption covers techniques for ensuring swiped credit data is always stored and transmitted in an encrypted format right from the point where a customer plastic is …
A while ago I was the victim of a little credit card fraud. Visa's excuse was that the site where the fraudulent transactions took place (not a site I'd ever visited) did not ask for the 3 digit security number. All it asked for was data that could be gleaned from the front of the card. They suggested that the most likely way my card details were stolen was that a merchant handled my card. Well the only time that had happened recently was two days before the dodgy transactions at the petrol station of a well known supermarket who's chip and pin machines were out of action. Coincidence? I told Visa and my bank this, but they weren't interested and just refunded my account. I tried the police who were also not interested. They said it was unlikely the spotty faced youth who'd handled my card had used my card to fund an online gaming habit (yeah right!) and that it wasn't worth pursuing.
Anyway the point about that was that Visa should refuse to deal with such an insecure site, but they didn't. Likewise these should not be guidelines they should be mandatory.
Look,
Until you lock down the database with field level encryption and stronger access auditing, then moving outward to the web/external interface, you will never be secure enough to breathe easily.
I rate this a fail because its meant to give the consumer a false sense of security.
Twice I've seen online retailers send credit card numbers by email.
Last month I reserved an hotel, gave my name, credit card number, expiry date, security code.
When I arrived and paid in cash, the reception gave me the email they had printed out, with all the info I'd given to the https website.
Previously, a few years ago, when I canceled an order on a web-shop, they returned an email confirming that they had not debited my card number ... (full card number was given).
Look on the bright side, it could have been much worse.
Some time ago an ex-colleague of mine bought a bottle of the local drain cleaner at a certain well-known Spanish tourist airport (presumably a silly hat and a straw donkey too, I didn't ask). By the time he got off the plane at Heathrow his account was damned nearly maxed out. It would have been completely maxed out, but the simultaneous "Card present"(!) purchase attempts in Hong Kong, Capetown and San Franciso tipped off Visa, who blocked it.
As for the other side of your experience, I sympathise. Some years back I dropped my wallet. A few hours later I got a call from Amex's retailer authorisation arm saying that they's had a call from a vendor saying he's had some moody looking types in trying to use my card (it auth'd ok, but he told 'em to get knotted anyway). They put me in touch. The chap reckoned he had good CCTV and a decent set of dabs on the Rolex they'd been handling, which he'd polished before he handed it over. Now, do you think anyone from either Amex's card fraud unit or the plod gave a flying f***? There's a good reason for card fraud, we make it really bloody easy to get away with. In this particular case, while they didn't get the Rolex, they did get a telly and DVD player.
...that can't make up their mind what is and isn't card holder information? For example: the card holders name. Yeah, sure I'll encrypt that. And then I'll write de/encryption code directly into my website so I can greet users thus rendering said encryption completely useless in the event of a server breach.
Am I reading this right, "Sensitive authentication data such as CVV2 numbers or PINs should only be used for authorisation and never held on merchant's systems"
Should never be held? It's a bit surprising that PINs COULD be held on merchants' systems.
What's to stop a bogus card reader taking the card details and then recording the PIN for later nefarious use?
Not reassured at all.
I assume that no-one is suggesting that Standards like PCI shouldnt exist?
One of the big flaws in the Standard was always that the requirements for encryption etc were sufficiently wooly as to cause confusion amongst Merchants attempting compliance. Now they're not, so where's the problem?
I do get a bit depressed reading people bitching about how awful everything is and then proceeding to bitch even more when someone tries to improve things.
Encryption can itself be one of the worst enemies here.
Post-authorisation, very few sites need to encrypt the card number. It's not even necesary to store the thing! The attitude of "we can store it, it's OK, we've encrypted it" is a fallacy shared by a huge number of sites, operators and even major players who Ought To Know Better (and are indeed told so in PCI DSS). It's a shift from "we don't need to do this" to "we need to do this competently, forever, against attack" and we know how hard that is.
If you want an audit trail, _obfuscate_ the number (wipe all but the last digits), don't encrypt it. That's just not reversible, even if the whole database is compromised. Works fine for audit trails and answering customer post facto denials too.
If the card number does need to be held long-term (future repeat charges), then that's a whole different business, not the usual one-off web shopping visit. Do it if and when it's needed, but that's the rare exception on most sites, not the rule.
As for encryption with a symmetric key cipher (and just how nearby is that encryption key held?), that's a WTF of its own.
------------
If the card number does need to be held long-term (future repeat charges), then that's a whole different business, not the usual one-off web shopping visit.
------------
Actually - even then the merchant shouldn't hold the full number - merely the last 4 digits. Most payment processors have a system whereby you can enable repeat processing on that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
