Blog post

Paper Token: Gutenberg’s version of One Time Passwords

Nowadays, ensuring proper security for information technology is a mandatory requirement for governments, companies and even individuals. Even protected and hardened system infrastructures are vulnerable to hacking attacks and malware (see the latest press about the “stuxnet” worm infiltrating Iran’s nuclear power plants). However, high security comes at a price: a lot of security technologies are not easily accessible to their users — especially with regard to the cost of their acquisition or maintenance. So-called One-Time Passwords (OTP) are one such example.

Introducing One-Time Passwords (OTP)

What are one-time passwords? Wikipedia gives the following definition:

A one-time password (OTP) is a password that is valid for only one login session or transaction. OTPs avoid a number of shortcomings that are associated with traditional (static) passwords. The most important shortcoming that is addressed by OTPs is that, in contrast to static passwords, they are not vulnerable to replay attacks. This means that, if a potential intruder manages to record an OTP that was already used to log into a service or to conduct a transaction, he will not be able to abuse it since it will be no longer valid. On the downside, OTPs cannot be memorized by human beings. Therefore they require additional technology in order to work.

Now let us look at why and when one would like to use OTP. For instance, imagine being at a place such as a cybercafé or a hotel where you cannot trust the local IT infrastructure. Unfortunately, you really need to access your email inbox through a non-encrypted communication channel (e.g. HTTP instead of HTTPS, or IMAP instead of IMAPS) but at the same time you don’t want to risk revealing your email password to the rest of the world. An OTP provides a solution to have a unique password that changes every time and at each authentication. Even if the password is captured by some bad guys as it travels across the networks, they will not be able to re-use it for their malicious purposes because the password is valid only one time or in a short period of time.

Browsing at an Internet Café

Browsing at an Internet Café: Not the most secure place for your confidential passwords. (Picture by Flickr user feserc)

Commercial OTP solutions

So while OTP are an interesting solution for such scenarios, they come literally at a price. A proprietary OTP solution can be quite expensive, especially if we consider that any required security devices for OTP such as hardware security tokens can cost more than 50,- EUR per person/year. Additionally, hardware tokens and their corresponding infrastructure is often proprietary and require a lot of effort to be setup and maintained.

Hardware OTP token (RSA and Cryptocard)

Hardware OTP tokens (RSA SecureID and Cryptocard)

Can we improve the adoption of this security technology? How we could adapt OTP — the tools, the processes, etc. — to make this approach more accessible? And can we make it cheaper (e.g. using it for emergency access for a large number of users)?

As OTP rely on cryptographic functions to operate, we started our brainstorming by digging into one of the existing open standards describing OTP operation: “HOTP: An HMAC-Based One-Time Password Algorithm” (RFC 4226). HOTP describes a counter-based OTP relying on the HMAC-SHA-1 algorithm. In other words, the corresponding token is relying on the evolution of a counter for each authentication combined with the secret embedded in the token (and which is shared with the remote server responsible for verifying the authentication).

The cost (and complexity) of such a solution depends on two major components:

  • The server side including the information about each token
  • The client side being the hardware/software token to compute the required OTP value for each authentication requested by the user

Large OTP vendors rely on the current OTP scheme outlined above to make their business.  Even if the OTP algorithms themselves are standardized, the majority of vendors lock the users into their own proprietary solution so that users cannot choose to buy tokens from other suppliers.

Paper Token: Gutenberg’s version of OTP

Looking for an alternative to the commercial solutions described above, we asked ourselves: Is a simple, low-cost OTP solution possible? What if we could remove the dependency on an electronic device on the client side, i.e. the hardware token? And how could we come up with an affordable solution on the server side?

We remembered an older blog post by security expert Bruce Schneier about password management for users:

“Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We’re all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.” —Bruce Schneier 2005

With this in mind, what if we came up with a security token based on a sheet of plain, old-school paper? As hopeless book aficionados, we thought that this would also be true to the spirit of Johannes Gutenberg.

Johannes Gutenberg

Johannes Gutenberg: Would he have been happy to see a paper token as a simple, low-cost OTP solution?

We decided to give it a go and have thus written a Perl script called “Paper Token” which generates a printable page of a pre-calculated tokens for OTP.

You will have to set the initial counter (for a new token, this will usually start at the number zero) and the final counter. The Perl script will generate any possible values from the starting value until the end of the counter. The unique key of the token (in this example, this is the test vector value — so do not use it in a production environment…) needs to be set to the value known by the remote server.

Here is a simple example of running the Paper Token script:

perl  --output test.pdf --counter 0 --end 200 --secret 3132333435363738393031323334353637383930 --digits 6

The script generates a PDF document that will be handed to the user in either digital form or directly as printed paper sheet (see the photo below for how the token sheet looks in practice). The user will then just need to begin using the paper token by reading his paper sheet from left to right and strike-through values whenever they have been used for an authentication, i.e. very similar to how TAN work in the context of online banking (beside that the TAN is used in conjunction with your password and where the OTP is replacing the password). The user will keep the paper token in his wallet just like any other valuable cards or papers.

Paper token (an example)

How a paper token looks like.

Is there a future for a paper token?

This experiment shows the feasibility of using paper tokens even without
altering the security of the authentication process. Very often, we are giving up some
security for the convenience of using a publicly accessible computer or a shared computer. Why are Web services not allowing for an alternative way of user authentication by including OTP? Maybe ease of use and user convenience are the answers to this question. Still, a simple OTP approach such as paper tokens might be feasible in practice without investing too much into existing infrastructures or without adding too much complexity to existing security processes. Hey, we’re brainstorming here after all!

Another potential use of such a technology is the use of OTP as a password/account recovery mechanism. A lot online services are relying on those silly “security questions” like What is your mother’s maiden name? or What is your favorite color?, and these are often a source of security problems as described in What’s in a Name? Evaluating Statistical Attacks on Personal Knowledge Questions. (Just ask yourself: how many colors are there that users might have picked as their favorite? Not many? Exactly!) Maybe we could replace these easy to guess security questions through a pre-calculated OTP paper sheet?


Of course, we are not claiming to have found a miracle of a solution. Some questions and tasks are still unfinished (we haven’t talked much about the server side, for instance). But we want to initiate a discussion about simple, low-cost OTP solutions, and to not come to this discussion with empty hands but with some working piece of software that could serve as a starting point for further activities. There are plenty of opportunities to improve the security while keeping the cost or the accessible at a reasonable level. It’s often just a matter of creativity…


From quuxlabs:

From other people:

This blog post was filed under Security, Software and tagged , , , , , , , , .

2 Responses to Paper Token: Gutenberg’s version of One Time Passwords

  1. none says:

    I don’t *quite* get the point. From a cursory glance, OPIE – S/KEY already supports the concept of having a printed list of pregenerated one-time-use passwords, and people (albeit maybe not enough people) have been using it in this way for years, so what exactly is the new thing in this article? What does your new implementation bring?

  2. Thank you for your comment.

    It’s true that S/KEY exists for years and used by a small number of people. The article is more targeting the HOTP[1] devices (e.g. RSA SecurID token) where a lot of services are now relying on token-based hardware to access “secure” services. As the majority of token user (or even administrator) didn’t know that event-based token can be pre-calculated and printed on a sheet of paper, we show this possibility for HOTP. Especially that large corporation use token-based access for emergency case, they usually don’t need the hardware-based token (usually more expensive to acquire and manage) and could simply rely on a paper.

    I hope this answers your question.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>