Understanding token security

Question

I am having some problems, cryptographically speaking, digesting this information. There is a table that seems to say that tokens provide "end to end security" (I suppose we understand different things by that).

But my main issue is with this:

Tokenization also helps protect your online shopping activities. You buy a coffee table on Ikea.com, for example. If IKEA has tokenized the card numbers that it keeps on file, your information is safe even if it gets hacked (which it hasn’t). The retailer may never actually see or store the credit card number, so if someone weasels into the system (like in the Home Depot breach, for example), all the criminal can see is the randomly generated tokens.

I understand the benefits of tokens, because they are pseudo-random, they can be changed periodically (so the old ones will not work) and they do not disclose identifiable information. However, it seems to me that whoever owns the token can perform the same activities as the legitimate owner. So it is an "anomisation" of PANs, not a security measure against forbidden use. If someone hacks Ikea.com and gets the tokens, he/she could use them to buy a coffe from somewhere else in the same conditions as the actual PAN could be used. In this case, the benefit is that the token can be easily renovated without having to change the PAN.

(1) Am I missing something? What is the real security provided by tokens in this case?

(2) Are tokens generated by PRFs? If a PRP is considered "secure" (so it cannot be distinguised from a "secure" PRF and its outputs look like random strings) can PRPs be used to create PRFs to generate tokens? For example, a cipher block with random keys used to generate tokens.

(3) Additionally, tokens that are 128 bits long and are never changed will operate correctly (in probability) up to $2^{64}$ generated tokens, after which we can expect the system to fail? (due to collisions)

Squeamish Ossifrage · Accepted Answer · 2019-05-16T22:19:05.163

(1) Am I missing something? What is the real security provided by tokens in this case?

Suppose you shop at Home Despot and IKING and they store payment information. Suppose Home Despot is breached and evil Freedonian hackers steal all the stored payment information. What can we do?

If Home Despot was storing your long-term credit card information, then you have to get a new credit card. Worse, so do the eight million other people who used it. And until you get a new credit card, you can't buy a new longcouch at IKING—but until the breach is discovered, the pirates who breached Home Despot can!
If Home Despot was merely storing a per-site pseudorandom function of your payment information, then:
- only Home Despot has to get a new thing (in their case, a new security department)—you and the eight million other schmucks who shopped there can keep your credit cards
- presumably the Home Despot tokens work only at Home Despot, so the pirates are unable to refurnish their living quarters with new longcouches from IKING on your shilling

(2) Are tokens generated by PRFs? If a PRP is considered "secure" (so it cannot be distinguised from a "secure" PRF and its outputs look like random strings) can PRPs be used to create PRFs to generate tokens? For example, a cipher block with random keys used to generate tokens.

As long as you see well under $2^{b/2}$ input/output pairs for a PRP, a PRP is a good PRF. Of course, if the key gets leaked, all bets are off. For a keyed hash like HMAC-SHA256, which has PRF security and a little more, at least if a key gets leaked an adversary is limited to brute force search to find the input (like a credit card number) that might have gone into it to yield an output they found stored in a database. So, while a PRP is a pretty good PRF, there are qualitative differences that might lead you to want to choose something with stronger security like HMAC-SHA256 or keyed BLAKE2 or KMAC128 instead.

(3) Additionally, tokens that are 128 bits long and are never changed will operate correctly (in probability) up to $2^{64}$ generated tokens, after which we can expect the system to fail? (due to collisions)

It's unclear to me exactly how the tokens are used and I'm too lazy to read beyond the page you linked. But suppose it works as follows—a scheme I just pulled out of my cloaca on the spot:

Home Despot is assigned a secret key $k$ known only to Squipe, Silicon Valley's hottest new payment processor.
When Evelyn T. Shopster enters her credit card information at Home Despot's web site using Squipe's gooey webplet, Squipe stores Evelyn's name and credit card number, and computes for Home Despot the token $t = \operatorname{HMAC-SHA256/128}_k(m)$ where $m$ is the message: The bearer of this token is authorized to charge the credit card of Evelyn T. Shopster. (Here $\operatorname{HMAC-SHA256/128}$ is the 128-bit truncation of HMAC-SHA256.)
When Home Despot wants to charge the card, it sends the charge amount, Evelyn's name, and $t$ to Squipe.
On receipt of a charge request with token $t$ and name name, Squipe computes $\operatorname{HMAC-SHA256/128}_k(m')$ on the message $m'$ computed by The bearer of this token is authorized to charge the credit card of ${name}., and checks (in constant time!) whether the result is the same as $t$.

In this protocol, it doesn't matter if there is a collision between tokens, because one token cannot be used for another user; for any particular user you might try to abuse a token for, there's still only about a $1/2^{128}$ chance that it will work.

On the other hand, there are cases in which collisions could matter—for example, $2^{64}$ queries to an oracle for HMAC-MD5 under a secret key can lead to forgery with high probability. (This isn't because MD5 is broken—only MD5's collision resistance is broken; the same attack applies to HMAC with any 128-bit hash.)

Just a clarification, since Home Despot don't know your card, the token has to be created by the bank, as I think you say in (3). In that case, are banks going to keep track of all clients tokens, one for each shop they visit? In your system, the token is computed by Squipe, and then sent to HD. I suppose that Squipe can only distinguish between a legitimate request to change tokens by HD (because they have been compromised) or a malicious one because the request should come with the old token + the credit card information — user1156544, May 16 '19 at 22:16
@user1156544 What I meant is that Evelyn T. Shopster registers an account at Home Despot's web site, which has some web thing that calls out to Squire to actually store the data. Clearer? — Squeamish Ossifrage, May 16 '19 at 22:20
@user1156544 I have no idea what the revocation protocol is. Presumably after a breach at Home Despot there will be some way for them to say ‘uh oh, Squipe, I got owned, please toss the cookies’. Maybe there's also a way to revoke individual tokens; indeed, if you allowed just anyone to revoke individual tokens, the only damage is potential denial of service—which would require an adversary to learn the token in the first place, so maybe it's not a big deal to let anyone on the planet ask to revoke any particular token. — Squeamish Ossifrage, May 16 '19 at 22:22
"What I meant is that..." - Yes, but this means that Squire (or Google/Apple Pay) will store credentials per site per user. "maybe it's not a big deal to let anyone on the planet ask to revoke any particular token" I think this will denigrate part of the system, since the credit card might have to be transferred every single time — user1156544, May 16 '19 at 22:54
@user1156544 The reason it's not a big deal is that the adversary is extremely unlikely to learn the token and not have a better use for it than revoking it. They can't guess the token, and if they obtain the token from a breach they can probably do something more nefarious with it than simply revoke it. — Squeamish Ossifrage, May 16 '19 at 23:00

score 0 · Answer 2 · answered May 16 '19 at 20:44

0

They might be using the word token in the context of treating a hash digest as a token (perhaps), which is like storing an encrypted version of your password or credit card even though hash digests are not decryptable, they are sometimes reffered to as encrypted or ciphertext (as they are the output of a oneway/trapdoor function that is not reversable). If a service stored the sha256 hash digest of any arbitrary data, the digest is 256 bits long, which means the total ciphertext space for hash digests of that length is 2^256 (despite theoretical collisions such as different inputs mapping to the same digest output which have yet to be found. Otherwise, tokens could be generated as random values associated with users and set to expire or actually be encrypted with AES which requires that the service retain the keys to deceypt unless the client has that solely or in addition to the service being able to revoke them.

answered May 16 '19 at 20:44

Steven Hatzakis

391
3
14

Mmm... Sorry, but I am not sure how your answer addresses any of my 3 questions. Also, if you generate a cryptographic hash as a token, then it is incorrect - It is not random, so you lose all ability to use it as a token. In some way, it will have the same effect as encryption, since the same PAN will produce the same "token". – user1156544 May 16 '19 at 21:45
This was the part I was adressing related to hash function (and hash functions are just like psuedo-random number generators as they are both deterministic, so as long as the pre-image has enough entropy there wouldn't be much difference in terms of use, contextually), the squareup site you linked to even mentions them as "one-way non-reversible cryptographic functions" not sure if had you seen that part. – Steven Hatzakis May 17 '19 at 04:39
P.S. it was under the FAQ section https://squareup.com/townsquare/what-does-tokenization-actually-mean – Steven Hatzakis May 17 '19 at 04:49
Although it doesn't seem to address the questions, it is interesting nevertheless... They say "Tokens can be generated through mathematically reversible algorithms" impliying there is no key "Unlike data that is encrypted, tokens are not mathematically reversible with a decryption key", so one PAN means one token. Like in a hash, that you mention. If the token gets compromised, the PAN must be regenerated. If the hash algorithm is compromised, all PANs must be regenerated. It opens also to rainbow attacks, since PANs have predefined structures... Not sure a hash make sense – user1156544 May 17 '19 at 07:56
I think an attacker could compute all possible hashes for a bank, since it only involves $10{^9}$ possibilities. Moreover, what you are saying implies that the same token is used for all commerces, so I could compute all hashes from Bank Z and try them on somewhere insecure, right? Tokens as hashes seems broken to me – user1156544 May 17 '19 at 08:14
Perhaps a salt could be used but otherwise the security of any hash digest is based in the security of the entropy (i.e. pre-image of the resulting digest) together with the particular hash function. Keccak also has a sequence during its squeezing phase that can be used as a PRNG. Hashes are widely used on the internet as access tokens which is the narrative I tried to touch on in answering some of your questions. Thanks for the feedback and hope it was useful, cheers. – Steven Hatzakis May 17 '19 at 10:19
P.s. 10^9 could be easily broken in any cryptosystem, except for time-based tokens such as HOTP or TOTP we both sides need to sync and there is a limit on incorrect attempts to deter brute force searches. – Steven Hatzakis May 17 '19 at 10:19
Yes, good point about time-based tokens. But then again they cannot be used with hashes, as they will imply changing the PAN in the same time fashion – user1156544 May 17 '19 at 17:10

Understanding token security

2 Answers2