Hacker News Reader

Comment by Someone1234 | Hacker News Reader

The HK title is identical to the article's title but the article's title is misleading. Even the author goes into great pains in the first paragraph to say that this will look at "[the] process in broad strokes" and not really in-depth.

Plus the article is really low-tech (spending a very long time teaching us about tokens) and very pro Apple (e.g. making claims that make no sense like "it may very well be the safest way to make any type of credit card payment" yeah, except those dozens of other identical systems we already have, and have had for at least a year!).

I have nothing against Apple Pay at all. I am glad they joined the party. This article though is meh.

View on HN

"claims that make no sense like "it may very well be the safest way to make any type of credit card payment" yeah, except those dozens of other identical systems we already have, and have had for at least a year!"

Pause for a second and believe me when I say that you are very wrong.

Virtual, one-time use credit card numbers are very different from the EMVCo tokenization specification that Apple Pay implements. These differences have important security and privacy implications.

Apple Pay is literally the safest way to use a credit card today. Read the specification if you don't understand why this is true.

http://www.emvco.com/specifications.aspx?id=263

Alternatively, read the best technical summary of EMVCo tokenization: http://clover-developers.blogspot.com/2014/09/apple-pay.html

Apple Pay is literally the safest way to use a credit card today.

Credit (and debit) cards in Canada and elsewhere have had NFC functionality for several years now. You never hand your card or numbers to anyone, but instead through chip insertion or proximal NFC it communicates with the identifier on the card, which the payment processor can correlate with you, and using the secret on the card cryptographically signs a transaction.

The most secure way I can use my credit card...is to use my credit card: Nothing that can be usurped is passed to the POS terminal.

Apple is essentially injecting themselves in a simple process that works extremely well.

EDIT: I think this might be wrong, FYI.

Sure, you never hand the card over when you pay with NFC, but that card number is being sent through computer systems that current events prove are very vulnerable.

NFC and Chip-and-PIN protect the merchant from fraud, not the user. A malicious customer can't use a stolen card at a merchant that only accepts Chip-and-PIN payments.

EMVCo tokenization generates a token that can only be used with one-time cryptograms generated with a secret key that never leaves the device. If someone hacks a merchant you pay via Apple Pay and tries to use your token as a card number online, it will be rejected even though it looks like a card number.

EMVCo tokenization is a new thing. It is better than what came before it because it was designed with that goal in mind. People are reluctant to believe this for some reason.

EMVCo tokenization generates a token that can only be used with one-time cryptograms generated with a secret key that never leaves the device

You mean exactly like the EMV that is on every Canadian credit card since about 2007? NFC / Chip hold unique tokens that have on device cryptography, exactly as you've described. You can't "steal" anything of consequence via NFC or the chip, and that's why it was designed. Further while you say that it's for the vendor, the liable party for fraud is actually the credit card companies, which is exactly why they made EMV.

You seem to think this is all new because of EMVCo, however it is a standardization for the last mile: Google Wallet originally was doing what the credit cards themselves do, holding the secret key and identifiers on an NXP secure element. There are issues with that (largely carrier related) which is why the industry started moving to software-held tokens, as in the Apple solution. Presenting an iPhone token offers zero additional security over presenting a Canadian chip or NFC credit card, and that notion is rather ridiculous.

Hm. There's a chance that your contactless card sends a different token that isn't your credit card number when you pay that way. I'm not sure. If so, you're right that it's basically the same level of security.

However, the new way lets you do the same thing in software without giving all your transactions to Google, which is nice. We'll be able to do online payments that are as secure and private as NFC, which we can't today.

Sadly, you can read magstripe data via NFC with today's contactless cards. I've seen apps do it on the Google Play store today. See section 5.1 on page 7 here: http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f...

Note though, replay attacks require downgrading the card and suggesting it's not actually EMV-secured. And um, it appears all you need is a cell phone to clone one card onto another, if I'm really reading this right? No wonder we need EMV or stronger, Apple Pay protections.

Frankly, the way I see it, we can't move fast enough to one-time use card numbers, however we achieve it... then I suppose more fraud will attack the next weakest point, perhaps passwords or IT systems.

The article contains original reporting with newly sourced details not available elsewhere. As a result, as of this moment it's the most detailed article available. It's the best you're going to get, like it or leave it.

Could you elaborate on the dozens of identical systems? I haven't yet managed to find one where no one except the credit card networks can see my CC number (and I thought the tokenization spec was only released 6 months ago...)

Isn't that how contactless and EMV payments already do it, or am I mistaken?

No, the tokenization spec has just been released and Apple Pay is the first (large scale) implementation. Tokenization is a combo of a token bound to a device, a one-time signature made through a secret store in a non-readable chip, and a personal authentication of the person through a non-static code.

Does that mean that existing chip and contactless systems just transmit the credit card number, as a sort of fancy version of a magstripe?

Virtual credit card provisioning seems common.

For example: https://support.google.com/wallet/answer/2740044?hl=en

Token-like services are also common for contactless payment systems ...

Your linked example is drastically different. Although the merchant only sees a virtual card number, Google sees, stores and charges your real credit card number the old-fashioned way.

You say "Google sees your real credit card number".

(I'll address the rest later)

Somebody sees the credit card number, even in token based systems, even if it's only for a moment to acquire a token.

In other words, either Apple stills sees it while it acquires a payment token, or someone does to issue the payment token, as it's the only mechanism that identifies the account number to get a token for. The tokenization specification has a whole section on what identification and verification should be taking place to ensure the "primary account number" (credit card number) that the payment token is replacing is one the user has authorization for.

So let's focus on the "stores and charges". Yes, Google stores and charges your primary account number. This is just because Google happens to be the one doing the payment processing. Even in a token based system, again, somebody on the other side knows what real primary account number (credit card number) this token links back up to so they know what to subtract money from. The token based stuff is not an full anonymization protocol, it's mainly a way to securely avoid transmitting and storing credit card info to/by random merchants. In that respect, the virtual credit card numbers provide the same protection. They are one time use, and interception or storage by the merchant can not harm you. Secondarily, the payment tokens are also a way to reduce the number of networks your credit card number goes over, when used properly. The virtual credit card numbers perform the same function here too.

The person who knows in either system is usually your payment processor (though in case it isn't, it's possible for the tokens to be used there too. however, nothing in Apple Pay currently guarantees this happens with the tokens). Since that is google here, it makes sense they would have the primary account data to do the lookup.

If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that.

The TL;DR is that virtual credit card numbers are in fact, a method of tokenization. The only reason they went with "token" is because they don't have to be credit card numbers, and because not all virtual credit card implementations have the same guarantees.

In any case, if you want fully tokenized systems, those have existed too, just not en masse.

EMVCo payment tokenization is more secure and more private than Google Wallet. With Google Wallet, two people know your card number and purchase history: Google and your issuer. With EMVCo tokenization, just your issuer knows your card number and purchase history.

It's better. It's the future.

"If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that."

I disagree. Care to explain?

"just your issuer knows your card number and purchase history."

If this was true, i'd agree. But it's not, AFAIK.

"I disagree. Care to explain?"

Nothing in the spec that i have seen requires that it be used all the way to the issuing bank.

In fact, here is one actual implementation: http://www.firstdata.com/downloads/thought-leadership/EMV-En...

Now look at figure 2 on page 8, and you can see ... It's not the issuer doing the tokenization or the PAN lookup, firstdata is doing it (in this case), just as Google is doing it in the Wallet case. Firstdata sells an approved apple pay solution.

It happens that Apple does not provide payment processing services, and is thus not doing it. That of course, does not change how many parties see your card number :)

Now, maybe there are issuers doing the tokenization, storage, and lookup themselves. But it's not required.

The actual spec leaves these functions to an "Agent" (not an issuer) and defines an Agent as "An entity appointed by the Card Issuer to perform specific functions on behalf of the Card Issuer. Some examples of these functions include card processing, Cardholder verification using the 3-D Secure protocol, and Token Service"

There is also nothing that assumes they do not appoint multiple agents (and in fact, specifically forsees this happening), etc.

Love to see something that says otherwise, but i can't find it.

That whitepaper is from 2012. The tokenization there is for merchants to be able to keep a token on file for a customer instead of keeping a card on file. It's like getting a Braintree or Stripe token to use for payments, but instead, you're getting a First Data token.

This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html

(Clover is owned by First Data.)

"That whitepaper is from 2012"

It's pointed to from their apple pay solution as to how it works?

"This is how things work in 2014: http://clover-developers.blogspot.com/2014/09/apple-pay.html "

Again, I have not seen a single implementation that claims to actually perform token usage all the way back to the issuing bank, just some diagrams that say "it's supposed to work that way" in some magical world where issuing banks run token service.

(and i've looked at actual implementations).

If you look at the comments on the blog, the author actually agrees with what i said: "Yes, the token is issued by the payment network, but Apple is not the payment network. The network would be Visa/MasterCard/AMEX. Apple receives the token from the payment network when the card is stored in Apple Pay (or Passport), then the token is provided each time a payment is made."

Note: Issued by the payment network. This is not the same as "bank who issued you the card". In fact, it's exactly the people I said it was (look at definition of payment network in the spec).

Also note: Apple sees the card to get the token to store in the wallet (it has to, unless the client directly understands how to route to an agent for a given card and connect there, which at least as apple has implemented, it doesn't). If you remember, above you said in an EMV world, only the issuer sees the real number. This is 100% false. Apple has no other way to get a token other than providing the PAN and letting an agent do ID & verification as part of a token request.

As I also said, the spec very specifically does not require anything else, delegating token service providing to agents.

Do you have anything to refute that issuing banks are going to be 100% compliant with the EMV tokenization spec (and apple pay) if they delegate the vault/lookup to someone else, like the payment processors? (I pasted the definitions from the spec, it specifically says the card issuer or the agent can perform this )

How about if they delegate to multiple people?

How about if they delegate to stripe, or google, or whoever?

The tokens only go exactly as far as the parties agree they want them to.

Two parties still see your card in Apple Pay: Whoever initially asks for the token to store (Apple right now), and whoever is playing vault. Apple just doesn't store it.

Reply on news.ycombinator.com