Hacker News Reader

Comment by vgel | Hacker News Reader

It seems to me like this scheme is only a half-measure for protecting something, because if an attacker compromises your app and steals a token they can still use it like your app does, right?

Say you have wrapped a credit card number in a token. When a user buys something, you call the API to charge the CC token instead of a CC number. But if an attacker steals a token, they can make that same API call and charge a card to pay themselves.

I guess the mitigations tokens give you over bare CC numbers in that scenario are:

* The attacker probably needs your API key or similar to use along with the token, instead of having a bare CC they can easily use anywhere

* Better auditing of token use

* Tokens are revocable in case you discover a breach

Still, due to that risk I don't see how this "eliminates" compliance risk.

View on HN

It’s generally not considered safe to expose the raw tokens to your users to use in your api. In fact if your using the system to try to avoid the headaches of PCI DSS, if you expose tokens as means of payment they’ll consider the token to be a card equivalent.

Instead the best practice would be to tokenize the data, accept it through one channel (an AttachCard api or whatever) and then return to your api consumer another opaque token to use for actions like authorization or clearing. From here there you can ensure that tokens are never reused etc.

This way if tokens leak they should be “inert” and no actions should be able to be taken with them.

> It’s generally not considered safe to expose the raw tokens

I think the article muddies the waters on this point because the the sentence defining tokens in the intro says they "are safe to expose".

Yeah, I can’t really speak for the article. I ran a large production tokenization system for a payments company. Most of my experience is within the narrow context of protecting credit card numbers.

In other contexts maybe you’re more accepting of public exposure. For example tokenization can be an effective GDPR mitigation, but i don’t think folks are particularly worried about reuse attacks when the information contains a name or email (I’m sure there are instances where they are concerned as well)

But at least when talking about tokenizing actionable information (credit card, bank account, whatever) implementors should be careful to keep them out of their public apis.

Credit card tokenization is a thing, and commonly used in retail. It leaves the last four digits of the number intact to allow searching for transactions from the POS; but other numbers are scrambled. Credit card data is otherwise stored in the POS systems tokenized. It takes all teeth out of credit card data for PCI requirements.

In this case, the tokenization is the measure itself.

> But if an attacker steals a token, they can make that same API call and charge a card to pay themselves.

I can't speak for every payments product but in the one I work with tokenized cards are tied to one merchant. A compromised token can only be used to process payments to that merchant.

Same here for the many payment processors I’ve worked with in the past. Except for the one time the processor swore up and down that tokens were tied to a merchant when they weren’t. It took several weeks of pestering support with example curl commands to convince them to escalate to someone who knew how to run a curl command. Then the bug was fixed within an hour.

It should be coupled to strong mutual authentication between the client and server.

Reply on news.ycombinator.com