Thinking Security: What’s a token?
This is the 25th blog in a series about security and how security is about how you think.
One of the latest security buzzwords is “tokenization” – the process of using tokens within your environment to help with the security. But what is a token? What is it used for? How does that help with the way that I think about security?
The first way that I think of the term “token” is when I take mass transportation – a subway token. I’s an old term, and just another term for coin. Nowadays most people use passes or cards, and very few use a token anymore. But it does show some of the use of the token – it represents the fare amount and shows that you paid some amount of money (which the transit authority can raise or lower) to get the token.
Another use of the term “token” is when I stand in line at the delicatessen counter or wait for a table in my favorite restaurant. When I get in line, I take a number or get handed a fob that will alert me when it’s my turn. While not called a token specifically, it represents me and my place in line. When I get to the head of the line, the deli worker will call my number or the fob will flash knowing that my turn has come. This is an important part of a token – that it represented me (whoever I may be) with something that its owners know and control.
The best analogy of a token is a hotel key card. When I register at a hotel, I’m given a smart card that will unlock my room and allow me access to other areas of the hotel – the elevator after 6pm, the fitness center (or so I’m told), the pool, the business center, etc. The key card is tied to my identity (or maybe just my room number) and gives me access only to the areas that I’m supposed to access and for only the amount of time that I’m registered at the hotel. I also believe that any use of the key card would also be logged for time and success/failure. If I fail to return the card when I check out, it’s not valid anyway and can be thrown away.
This is more what a token really is – it’s a representation of identity but within a bounded and controlled namespace. It allows the owner of the token (the hotel in this case) to control the access of the holder (me) without needing to worry about all of the different possibilities of identifying me. For example, when I’m at the hotel, I don’t use my credit card to check into my room or use the elevator, I use their access card.
Part of what makes tokens secure is that they’re very hard to make or counterfeit and are under control of the owner (for example, the hotel). Even if I had the same type of key card, I would have to be able to write onto the card the right digits for it to be accepted in their system. I could try all of the combinations (brute-force the process), but every attempt to use that fake card would probably be logged and then I would be arrested.
Tokens are very useful in computers for the same reasons that they are useful in hotels. For example, when I log in to a system for the first time, I may get back a token (called an authentication token) which contains information about me and how long I may access the computer system. I can present that authentication token to other systems within that enterprise to get access if I’m allowed. This is the concept of “single sign on” and is fairly prevalent in enterprises today. Another computer use is with networking protocols – when a client first connects to a system, it’s given a token (otherwise called a session ID or session token) which it should present back either with subsequent messages of this session or later on to continue the conversation. These tokens must follow the same security as the hotel key card – they have to be very hard to make (either containing random bits and/or using cryptography) so that they’re not easily guessable. And invalid use of them has to be logged so that brute-force attempts to get in are found. (Is someone trying to break into my system using a fake identity or trying to be a man-in-the-middle of my network protocol?)
But tokens don’t solve the entire security problem. They are only part of the solution. What’s most important is how they are integrated into the protocol, system, or solution. They must be tough to counterfeit, but easy for the right people to create. All access (both success and failure) must be logged and examined to see if there is a problem or break-in. Again, it comes down to how the system designer, network protocol designer, or hotel manager THINKS security in how they work and how the entire security of the system builds on them.