Technology Exploration Project – M591

Keeping passwords secret

How can a password based system still be used in an insecure environment, where it is hard to avoid others from gaining knowledge of someone's password? The idea is to use one-time passwords (OTPs) as part of an authentication system. Two of these sytems will be discussed. On the one hand the widespread and well known commercial system RSA SecurID and on the other the open source toolkit One Time Passwords in Everything (OPIE).
The question to be asked in this context is why the commercial system is so successfully placed on the market while it is difficult to find a currently maintained and used open source system, like there are in other areas? (e.g. Apache webserver, OpenOffice, openPGP, Linux, etc.)

Introduction to One-Time Passwords

The idea of OTPs developed with the introduction of remote access, when it became possible to eavesdrop by wire-tapping. The first remote access was through dumb terminals which where hard-wired to a mainframe. As the name says, one-time passwords are meant to be valid for only one authentication process, hence a sniffed password is no use to the attacker. Although most remote connections and sensitive communications over the internet are encrypted nowadays, with the help of key loggers and trojan horses it is still possible to get someone's password.
In 1981 Leslie Lamport introduced an idea of generating OTPs and implementing one-time password authentication using one-way functions, also known as hash functions. In his article "Password Authentication with Insecure Communication" he mentioned three ways someone could gain knowledge of another person's password:

1. By gaining access to the information stored inside the system, e.g., reading the system's password file.
2. By intercepting the user's communication with the system, e.g., eavesdropping on the line connecting the user's terminal with the system, or observing the execution of the password checking program.
3. By the user's inadvertent disclosure of his password, e.g., choosing an easily guessed password.

His method, which will be discussed later, addresses the first two points. The third one can be overcome by forcing the user to choose a hard to guess password, which leads to other problems, or by not letting the user choose the password. The latter one is partly used by SecurID and will be discussed later as well.
Although we do not use the term one-time password very often, we use varying implementations of the idea. In online-banking for example OTPs are used as the Transaction Authentication Number (TAN). The customer is provided with a list of TANs by the bank, which keeps itself the same list. Once a TAN is used, it is invalidated.
CAPTCHAS can also be seen as OTPs. Their purpose is to validate the user to be human. They are more and more used during the registration processes of free internet services such as email, forums and social networks. The method used by CAPTCHAS is called challenge-response. The challenge is a disturbed picture of a word or some characters and the response is the actual string itself. For humans it is easy to solve a CAPTCHA because most of the people using computers can read latin characters even when they are distorted while Optical Recognition Programmes would fail. This helps to avoid automatic programmes to create random accounts which might be used for spam or other purposes (Hüls, Müller, Ressler, 2006)
Both methods addresses different methods of authentication. TANs authenticate something you have, the TAN itself, while CAPCHAS authenticate something you know, the ability to read disturbed characters.

Techniques

OPIE is a system completely based on software. RSA SecurID is token based and usually uses a combination of hardware and software.

OPIE - One Time Passwords in Everything

OPIE was developed by the National Naval Research Laboratory (NRL) and is based on the S/Key system which was developed by Bellcore Systems in the early 1990s. S/Key uses the Lamport scheme which implements a hash function to generate the one-time passwords. As described by Lamport (1981), the OTPs are generated by applying the hash function H several times to a secret W that is only known to the user. The hash stored on the server is the result of Hⁿ(W). The first password to be used would be H^n-1(W). This is sent to the server, the hash function is applied and the result is compared to the stored hash Hⁿ(W). The sent password H^n-1(W) then becomes the stored hash for the next authentication process, therefore no secret has to be stored on the server. Because of the nature of the hash function it is impossible to reverse the calculation to get the next password or even the secret W from a known hash.
In S/Key, so in OPIE, W consists of a secret p and of a seed s which is provided by the server. When prompted for a login the user will be shown the current index n and the seed s. To get the OTP the user has to apply the hash function H n-times on W. The next time the user wants to login, the index will become n-1, while the seed remains the same:

Although S/Key was meant for a variety of UNIX systems, it mainly focused on BSD 4.3 and was hard to use on others. Therefore the NRL developed OPIE, which enhances S/Key and makes it usable for all UNIX based systems (McDonald, Daniel L. et al., 1995). It comes with replacements for the standard login, su and ftp and can also be used together with pam (pluggable authentication module). Because a library is provided, it can be applied to other applications as well. The seed is used to enhance the usability. It is usually different for each user / server and allows to use the same secret for multiple servers. Another usability enhancement is the conversion of the hexadecimal 16 digit hash into six short English words from a standard dictionary with 2048 words to enhance the usability (Haller, 1995).

RSA SecureID

SecurID was developed by SDTI (now RSA Security). It uses a token which generates a pseudo-random number every minute (or every 30 seconds). By combining this number with their PIN, the users can authenticate themselves to the computer system or network. It is a two factor authentication mechanism because it is based on something you have, the token, and something you know, your PIN.
The number generated by the token is based on a shared secret and the current time. Since 2003 a 128-bit secret and the AES algorithm are used to calculate the number. The secret has to be stored on the server as well and the clocks of the server and the token has to be synchronized. Before 2003, a proprietary hash algorithm combined with a 64-bit secret was used which was found to be not secure by Alex Biryukov, Joseph Lano and Bart Preneel in their Cryptanalysis of the Alleged SecurID Hash Function (Biryukov A. et al., 2003). The AES algorithm is currently believed to be secure. The token itself is tamper resistant and has usually a lifetime between three and five years. It is issued by RSA, who also generates the secret stored in it.



The SecurID system consits of three parts, the token on the client side, the application to which the client wants to authenticate (authentication agent) and the authentication manager. On authentication, the user sends his name, PIN and the generated number to the agent, e.g., a Webserver or a VPN Gateway. This agent forwards the authentication request to the Authentication Manager which will authenticate the client, based on user name, PIN and the generated number.

Installation and Usage

Administrator perspective

With SecurID RSA provides a scalable implementation of OTPs. On the "server" side, the Authentication Manager is needed as well as one or many Authentincation Agents. On the client side only the hardware token is needed which has to be registered with the Authentication Manager. According to the widespread use of the system it is assumed that the system is easy to install and to maintain. Even though RSA offers an evaluation version, it was not tested due to the limited time and limited extent of this article. (Also it is not likely that a student is provided with the necessary hard- and software for evaluation when there is no intention to buy the product) Because it is a commercial system, RSA and other licenced companies provide an installation and maintanance service.

The OPIE system (version 2.4, 2001) was installed and tested on a Linux system (openSuse 10.3). It was used to secure the authentication via ssh. Because Linux uses the pluggable authentication module (PAM), there are only a few files to be configured. Once the administrator is familiar with the installation of the OPIE package and how to configure PAM, it will only take about 15 minutes to set up the one-time password authentication for ssh (the user administration not included). Because OPIE is not scalable in the first place, this has to be done on every machine which can be accessed via an insecure connection / computer. It might be possible to use OPIE with a single-sign-on system like Kerberos, but this has to be further evaluated. The evaluated package can be used with every application which uses PAM for authentication without changing the source code.

User perspective

With SecurID the authentication process does not really change for the user. He still enters his username and a password (PIN + token number). The provided token is easy to use, even for non computer literate people. It only generates numbers which are easy to type and the token is easy to carry around on the keyring.
Because OPIE is a challange-response system, the authentication process requires more effort. When the user wants to login, he is challenged with the sequence number and the seed and prompted for the response.


Here the sequence number is 490 and the challange is jo2454. The response can be calculated with the program opiekey.


If the programm opiekey is not available on the client or the client is not secure, a list of OTPs can be precalculated.


Apart form the programm opiekey there are other key generators available on the internet. There is an implementation in java called jotp which is available on http://www.cs.umd.edu/users/harry/jotp/. This application is also available for mobile phones on http://tanso.net/j2me-otp/. Unfortunately the mobile application could not be evaluated because no supported mobile phone was available. The programme jotp works and can be downloaded for free.

Strength and weaknesses

To analyse both systems, one must be aware of their purpose. The idea of OTPs is to allow authentication in insecure environments without giving away any secrets. They cannot prevent eavesdropping but they try to eliminate the effect of eavesdropping for the authentication process, thus using a sniffed password. OTPs cannot prevent somebody to read the data exchanged over a remote connection or from active attacks like man in the middle or connection hijacking. But they can be combined with other techniques to overcome these issues, like IP/Sec, SSH and others. Both systems, RSA SecurID and OPIE are designed to work with other techniques and products, so they can both be seen as a toolkit which enhances the security of a system. The advantage of SecurID is that RSA also provides the application it can be used with, so RSA can offer a complete solution which OPIE cannot.

Algorithm

Because OPIE is not maintained any more it still uses MD5 (or MD4). Although the MD5 algorithm is still widely used for checksums to verify data integrity, it is not believed to be secure any more (it is not collision free, hence, two different inputs can produce the same hash (Wikipedia 2007). The underlying Lamport scheme does not recommend any hash function. The sourcecode of OPIE is freely available, therefore the MD5 algorithm can be replaced by any other function which is believed to be secure (like SHA-256). Thus the currently used hash function can be seen as only a minor weakness. In 2003, as mentioned before, RSA replaced its own proprietary algorithm with AES which is believed to be secure.

Secrets

In OPIE the generated passwords are dependent. Each password is the hash of the next one OTP_n = H(OTP_n-1). Hence no secret is stored on the server, which meets the first point of Lamports list. Nevertheless it also means if somebody get hold of a password with a low index, it is possible to calculate all the following passwords. This can happen, if a list of OTPs is printed and somebody overlooks some of them. If the secret is revealed, every OTP can be calculated. Although the secret can be chosen freely and might be easy to guess, this is only a minor weakness. The secret itself is never transmitted in clear text and only the last password (sequence number = 1) from a certain set is derived directly from the secret. Each time the hash function is applied, the probability of getting the secret with a brute force attack is halved.
The secret for the calculation of the pseudo-random number in SecurID is stored inside the token and on the server. It is longer than a usual password (128-bit) and is set by RSA. This mechanism partly addresses the third way of password theft mentioned by Lamport but contradicts the first one. Nevertheless, the PIN is transmitted in clear text. In another implementation of SecurID the secret consists of the PIN and the stored 128-bit key. The token has a keypad where the user enters his PIN. The OTP is then calculated on the combined secret (PIN + 128-bit key). This is more secure in terms of wiretapping, because the PIN is never transmitted in clear text, but the token is more expensive.

Implementation and Costs

The main strength of OPIE is that it is open source and comes for free. Every major Linux distribution has the OPIE package included and for someone who has some knowledge of Linx/Unix it is easy to set it up. It does not need any additional hardware. A drawback of OPIE is that the user has to set up the OTPs for himself. This is done by running the command opiepasswd. A detailed description of how the user has to set up his OTPs can be found in the FreeBSD-Handbook (FreeBSD, 2007).
As described above, OPIE in its current implementation is not scalable, hence it must be set up separately on each system. Especially For larger companies with huge networks and a variety of applications this is an especially big issue. There is also no implementation for Windows which is another drawback these days. SecureID on the other hand offers with its Authentication Manager a single entity to manage and authenticate users. It also supports a wide range of other security related products, both Windows and Unix based applications. But this support does not come for free. SecurID is a cost intensive security solution.

Why is there no successful open source system for OTPs?

To answer this question it is necessary to analyse what OTPs are used for. In general, to make it possible to use passwords in insecure environments. But what does that mean?
The average internet user is usually not aware of the threats of password theft or does not really care. He uses passwords easy to remember and often the same password is used for many systems.
Companies on the other hand need to secure their networks and data otherwise they would loose money. With the globalization more and more employees travel around the world but still need access to their emails and applications. Also inside the company network many sensitive applications and device need extra protection, like firewalls, database systems, etc. Therefore, the customers for one-time passwords are companies and not single users.

The major concerns of companies are scalability, maintainability and to know who can be blamed if something is not working. In all three issues OPIE has its drawbacks. It is not really scalable and therefore not so easy to maintain. Open source software usually does not provide any support or liability, too.
OPIE might be usable in smaller companies but often small companies do not have the knowledge to use Unix or Linux and cannot afford to pay a Linux or Unix administrator.
Also S/Key and OPIE were probably not developed for the general user but for computer literates. As described, the user has to generate the OTPs himself which is not necessary with SecurID. Even though some usability was added to the challenge-response system by converting the hash into English words, it is still not very comfortable to use. Because at the time the systems were developed, portable devices like notebooks, palmtops or mobile phones with java support where not widely used or even developed, it was necessary to precalculate the OTPs if there was no secure system available. This is another security risk which SecurID solves by using a dedicated hardware token.
Another advantage of the commercial systems is their support of Windows and Windows based applications. While in the early 90s many servers were mainframes and Unix based systems, nowaday Windows servers are becoming more and more popular, especially for email (MS-Exchange Server) and Active Directory systems.
The commercial success of SecurID compared to other commercial systems like "Kobil" or "Entrust IdentityGuard" is not least based on the good reputation of RSA Security.
Finally, because the data companies want to protect are valuable, they are willing to pay for their protection.

---

References

• Haller N. (1994), The S/Key One-Time Password System [Electronic version]. Proceedings of the ISOC Symposium on Network and Distributed System Security, February 1994, pages 151-157
• Haller N. (1995), RFC1760: The S/KEY One-Time Password System. Retrieved November 10, 2007, from http://www.ietf.org/rfc/rfc1760.txt
• Lamport, Leslie (1981). Password Authentication with Insecure Communication [Electronic version]. Communications of the ACM 24.11 November 1981, 770-772
• Hüls A., Müller J., Ressler M. (2006). CAPCHA. Retrieved October 30, 2007, from http://m591group.pbwiki.com/14-11-2006-Coursework-Report
• McDonald , Daniel L. et al. (1995). One Time Passwords In Everything (OPIE): Experiences with Building and Using Stronger Authentication [Electronic verstion]. Procedings of the Fifth USENIX UNIX Security Symposium, June 1995
• Biryukov A. et al. (2003). Cryptanalysis of the Alleged SecurID Hash Function [Electronic version]. Lecture Notes in Computer Science, Selected Areas in Cryptography Volume 2006/2004
• FreeBSD (2007). One-Time Passwords. FreeBSD Handbook, Chapter 14.5 Retrieved November 10,2007 from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/one-time-passwords.html