![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Credit Card Number Tokenization
May. 7th, 2013 09:41 amRecently, I posted about adapting to new technology and, in passing, referred to tokenization. I thought about explaining what I meant by that, but assumed that it was a long post and no one really cared anyway. Turns out I was wrong (not about the length -- about the no one caring), so here's my explanation of tokenization, with a reference even.
Once upon a time, I used to work with a tiny number of people at a dot com startup. One of the people I was working with was my boyfriend (<-- simultaneously smart and stupid decision, but life's like that). My boyfriend at the time self-described as a code queen, also, while he could work with other people, he wasn't really great at it, so he got put in charge of the credit card stuff: it was a really important piece to get right, his natural paranoia worked in his favor and his attention to detail was a plus rather than an aggravation. And it was small enough that he could do the whole thing himself and not have to interact with very many other people.
As a dot com startup, we wanted to sell things to a lot of people, but a lot of people were still a little concerned about handing over credit card information over the internet. We did a variety of things to try to assuage these concerns, some of which genuinely improved security and some of which were mostly there to make people feel like this was familiar territory and thus "safe". The "genuine improvement" was to completely isolate _all_ credit card information. When we received credit card information, it went into a "box" and the box gave you a token. The token was used everywhere that credit card information would otherwise be stored: all through the ordering process, for marketing research, blah, blah, bleeping, blah. If you needed to actually _charge_ the credit card, you gave the "box" the token, and the "box" did the magic and you never, ever, ever saw the credit card information. The "box" had a bunch of physical and other security to render it extremely unavailable to hacking, either internally or over the internet. The "box" had a name styled on a particular form of pest control, the "Roach Motel": credit card information went in, but didn't come back out.
While I never worked on this code, and don't know the internal details of implementation, I know good architecture when I see it, and this was The Right Way to Do Things. Lots of people had access to the order database: you could write queries to find out how many people ordered a particular item -- or how many items a particular person had ever ordered, or whatever. What you couldn't do was get credit card information. Thus, protection from internal hackery. Protection from internal hackery limits external hackery directly, because it's harder to exploit human factors: you couldn't just call up customer service and con them into telling you a credit card number, because they didn't know any more about that number than you could see on the web (last four digits, type of thing). And then physical isolation of the servers running the motel.
Like everyone else, I make sense of the world based in part on my personal experience. Because this was an important experience of credit-cards-on-the-internet, I tend to assume that this is how other online and offline vendors manage credit card information. Alas, if only it were so. As I was reading this (I was reading some of First Data's papers on EMV, recently):
http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-Tokenization-WP.PDF
it became clear to me that a lot of companies doing business on and offline have credit card information throughout their business, accessible to employees throughout their business and available for attack directly or through human factors.
*sigh*
The nice thing about that paper is it points out that tokenization can occur on other-than-internal-to-a-merchant basis: Discover Card apparently offers something like this (and I think this is why both PayPal and the Secure Remote Payment Council have adopted Discover/D-Pas as a platform (<-- might not be quite the right terms). First Data obviously toots the horn of its own services in this arena as well.
And now, in passing, a remark: really, in the 2000s, companies feel they need to call the American cardholder and make sure they _really_ want to ship a bunch of expensive items to some address in the Ukraine?!? What the fuck is wrong with you? We knew that was fraud in 1997. Duh.
I feel curmudgeonly, so I will stop now.
Once upon a time, I used to work with a tiny number of people at a dot com startup. One of the people I was working with was my boyfriend (<-- simultaneously smart and stupid decision, but life's like that). My boyfriend at the time self-described as a code queen, also, while he could work with other people, he wasn't really great at it, so he got put in charge of the credit card stuff: it was a really important piece to get right, his natural paranoia worked in his favor and his attention to detail was a plus rather than an aggravation. And it was small enough that he could do the whole thing himself and not have to interact with very many other people.
As a dot com startup, we wanted to sell things to a lot of people, but a lot of people were still a little concerned about handing over credit card information over the internet. We did a variety of things to try to assuage these concerns, some of which genuinely improved security and some of which were mostly there to make people feel like this was familiar territory and thus "safe". The "genuine improvement" was to completely isolate _all_ credit card information. When we received credit card information, it went into a "box" and the box gave you a token. The token was used everywhere that credit card information would otherwise be stored: all through the ordering process, for marketing research, blah, blah, bleeping, blah. If you needed to actually _charge_ the credit card, you gave the "box" the token, and the "box" did the magic and you never, ever, ever saw the credit card information. The "box" had a bunch of physical and other security to render it extremely unavailable to hacking, either internally or over the internet. The "box" had a name styled on a particular form of pest control, the "Roach Motel": credit card information went in, but didn't come back out.
While I never worked on this code, and don't know the internal details of implementation, I know good architecture when I see it, and this was The Right Way to Do Things. Lots of people had access to the order database: you could write queries to find out how many people ordered a particular item -- or how many items a particular person had ever ordered, or whatever. What you couldn't do was get credit card information. Thus, protection from internal hackery. Protection from internal hackery limits external hackery directly, because it's harder to exploit human factors: you couldn't just call up customer service and con them into telling you a credit card number, because they didn't know any more about that number than you could see on the web (last four digits, type of thing). And then physical isolation of the servers running the motel.
Like everyone else, I make sense of the world based in part on my personal experience. Because this was an important experience of credit-cards-on-the-internet, I tend to assume that this is how other online and offline vendors manage credit card information. Alas, if only it were so. As I was reading this (I was reading some of First Data's papers on EMV, recently):
http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-Tokenization-WP.PDF
it became clear to me that a lot of companies doing business on and offline have credit card information throughout their business, accessible to employees throughout their business and available for attack directly or through human factors.
*sigh*
The nice thing about that paper is it points out that tokenization can occur on other-than-internal-to-a-merchant basis: Discover Card apparently offers something like this (and I think this is why both PayPal and the Secure Remote Payment Council have adopted Discover/D-Pas as a platform (<-- might not be quite the right terms). First Data obviously toots the horn of its own services in this arena as well.
And now, in passing, a remark: really, in the 2000s, companies feel they need to call the American cardholder and make sure they _really_ want to ship a bunch of expensive items to some address in the Ukraine?!? What the fuck is wrong with you? We knew that was fraud in 1997. Duh.
I feel curmudgeonly, so I will stop now.