An Enhanced One-Time Password Implementation

TAN Teik Guan

Data Security Systems Solutions Pte Ltd
Singapore
http://www.dsssasia.com

Abstract – We propose here a number of enhancements to the RFC 2289 One

Time Password System (or S/Key™). The enhancements take into account the
vulnerabilities of RFC 2289 as well as the practical usage issues in deploying this
standard for modern day 2-factor authentication. More significantly, with the
introduction of a user-originated “bias”, the enhancements allow for various
user-end implementations, both on hardware or software, to be supported with the
possibility of extending this support into 3rd factor biometric authentication.

Keywords: Authentication Security, One-time password, RFC 2289

1 Background

Identification has been always the fundamental aspect of Information Security. Without a
reliable user identification means, the basis of trust between communicating parties break
down and the use of strong cryptography to protect communications such as confidentiality,
integrity, etc become secondary. All communications begin with identification, either
subconsciously or deliberately, using various parameters of trust, such as recognizing a face
or voice, or entering a phone number, or even being introduced via a mutual friend.

In the modern electronic world that we live in, the accepted means of achieving identification
is using pre-determined factors such as “something you know”, “something you have” or
“something you are”, and the process of validating the factors is known as authentication. As
an example, if Alice and Bob were to go on a date, they can identify each other by i) knowing
the time and place to meet (1st factor authentication); ii) checking the license plates of the cars
they are driving (2nd factor authentication); and iii) recognizing each others’ faces and voices
upon greeting (3rd factor authentication). Naturally the authentication process is not done
deliberately and rigorously each time they meet, but carried out subconsciously.
Nevertheless, if Bob forgot the time to meet but still drove the same car, Alice would not be
as suspicious as if Bob were driving a different car, or worse still if Bob looked different.

The identification solution we present today provides a flexible platform for an organization
to implement an authentication system to identify its users, using either or all of the
authentication factors mentioned above. The concept is, of course, not limited to user
authentication, but can also be applied to data authentication, transaction integrity, data
confidentiality, etc.

2 One-Time Passwords

The idea of using a sequence of one-time passwords for user authentication was mooted by
Lamport [6] in 1981. Lamport stated that using a mutually agreed sequence of stored
passwords for authentication would prevent any 3rd party eavesdropper from gaining access to
the system. But it was, in his opinion, not entirely satisfactory as there was a need to store a
potentially large number of passwords (Lamport gave an arbitrary figure of 1,000 passwords),
and that an intruder could take advantage of a system crash rollback, which at his time could
mean a whopping 2 hours, to re-use a previously used password to gain entry to the system.
He then proceeded to introduce the method of using a one-way function to generate the
sequence of passwords that led to the implementation of the One-time Passwords.

One popular and still widely used one-time password implementation today is Bellcore’s
S/KEY [4]. The S/KEY solution was originally described by Haller in 1994 [4] and had
undergone some updates to its current standard RFC 2289 [5]. Users using the S/KEY
solution are authenticated using different passwords each time, thus defeating any replay
attacks on the system. To handle key management, the idea is to rely on a one-way hash
function such as MD4, MD5 and SHA to ensure that it is not computationally possible to
derive the source input from the hash output. Hence, from a single initial secret seed (or pass-
phrase), an arbitrarily long chain of keys can be determined and used in a Last-in-First-out
(LIFO) manner. The security of the S/KEY solution is thus dependent on the cryptographic
non-invertability strength of the one-way hash functions, which fortunately have not yet been
compromised. The shortfalls of S/KEY solution are also well researched upon. The main
security argument against S/KEY is that the passwords are not independent and mean that it
is susceptible to off-line dictionary attacks [9]. Proposals to modify or improve the one-time
password solution include US Naval Research Laboratory’s OPIE [8] which addressed
several S/KEY implementation issues, using 3DES as a pseudo random function to
complicate the dependencies between keys [10], and using challenge response [7] which
addresses the issue of secret-seed compromise by an attacker overlooking the user’s shoulder.

The other school of one-time password implementation stems from the hardware
authentication token manufacturers such as RSA Security Inc (NASQ: RSAS,
http://www.rsasecurity.com), ActivCard S.A. (NASQ: ACTI, http://www.activcard.com) and
VASCO Data Security (NASQ: VDSI, http://www.vasco.com). RSA Security’s SecurID
tokens are well-recognized by many as the “industry standard” in providing non-repeating
one-time authentication passwords. The method, described in [11], accepts a static variable
and a time-dynamic variable as inputs into a secret transformation algorithm to generate a
different password at every time interval. Naturally, the SecurID system handles the time-
drift between the tokens and server for the authentication process as well as tamper-response
on the tokens to erase the secret algorithm if the tokens are compromised. The methods
implemented by ActivCard [1] and VASCO [2, 3] also derive the one-time passwords as a
function of input, stored variables, time and/or event, but with the flexibility of a non-secret
encryption algorithm, such as DES. The differences amongst the manufacturers’
authentication solutions are subtle to the layman, while their similarities are indeed causes for
a number of patent violation lawsuits between them.

3 Proposed Enhancements

The RFC 2289 algorithm requires a user secret <Pass-phrase> and a server published <Seed>
value, which are hashed and folded a number of times as determined by an ever-increasing
<sequence integer>. The output is a 64-bit value to be presented to the backend verification
service

From an implementation standpoint, the RFC 2289[5] is cheap to deploy, requiring only
minimal computational capabilities, as compared to more resource intensive symmetric and
asymmetric cryptographic algorithms, on the backend servers. Besides the vulnerabilities
associated with Dictionary attacks on the <Pass-phrase>, we note a number of practical user-
end issues that are related to RFC 2289.
These include:

o Challenge-Response. The RFC 2289 is essentially a Challenge-Response protocol in

which the user is required to enter the sequence number and secret pass-phrase in
order to get the one-time password. This protocol creates the requirement for some
input requirement at the user end, and is typically deemed as “inconvenient” from a
usage standpoint. The challenge is also subject to spoofing attacks in which the user
may be tricked to reply a response that can be used subsequently [9].

o Lengthy one-time password. The response from the one-time password algorithm in
RFC 2289 is lengthy (64 bit value, that is transformed into 6 alphabetical words) and
language dependent. This is in contrast to the more popular hardware token
manufacturers whose tokens continually generate 6 to 8 digit responses which are
more universally recognized and easier to transcribe.

Our enhanced implementation to the RFC 2289 standard is meant as add-on, without
changing the algorithms nor input parameters, in order to meet today’s needs of one-time
password implementations. The enhancements are:

Increased <Pass-phrase> search space. We propose the use of a binary <Pass-

phrase> independent of a user password to be used to increase the search space
against a dictionary attack. This <Pass-phrase> should be a secret stored in the
device, encrypted by an optional user password. In order to obtain the one-time
password, users will be optionally required to enter their user password to decrypt the
<Pass-phrase>

Response-only. We propose that the device would automatically know the OTP
challenge (i.e. <sequence integer> and <Seed>) without any communication from the
host. This will eliminate any spoofing attacks and reduce the inconvenience to the
user. In our reference implementation, we use the concept of time to determine the
<sequence integer> and <Seed>.

Digit-only password. To have the one-time password to take the form of 6 to 8

digits, rather than a 64-bit value.

Bias. To have a user/device specific value, in the form of a Bias, which is generated
during token initialization. This Bias skews the one-time passwords that are
generated to be dependent on the Bias, in order to prevent another token from using
the same serial number and seed to generate identical passwords. This Bias can be
determined in numerous ways, including:
o Randomly
o A derivation of a device/OS specific value, e.g. manufacturer’s serial
number, license number
o A derivation of a user specific value, e.g. a biometric value.
With this Bias, devices with the same initialization values from the server may not
generate the same one-time passwords. This is because the Bias value is only
determined by the device upon initialization, and the server will discover the Bias
upon the first login by the user.

4 Reference Implementation

We now describe below an implementation of the enhanced RFC 2289 one-time password
system. Since the end-user device used to compute the one-time password can vary from a
myriad of software programs or devices including Personal computers, Mobile phones, Java
applets in browsers, hardware devices, etc, we will use a generic name of “token” to refer to
such devices.

The token has the following data stored internally:

Serial Number, a numeric string in ASCII format of up to 12 digits in length. The
Serial Number is null-terminated to depict the end of the string.
A Secret 1-byte binary value, named Bias.
A Secret 16-byte binary value, named Secret. The Serial Number concatenated with
the Secret and Bias represents the secret <Pass-phrase> in the RFC 2289 standard.
The chosen length (i.e. 6, 7 or 8) of the one-time password.

We propose that the one-time passwords generated by the token are per minute, i.e. The one-
time password changes every minute, although this is not mandatory.

4.1 Token Initialization

Before the token can be used to generate one-time passwords, it has to be first initialized.
During manufacture, the Serial Number is to be assigned to the token. The Serial
Number is a numeric string in ASCII format not exceeding 12 digits in length. The
Serial Number is null-terminated to depict the end of the string. This should not be
changed throughout the token’s lifetime.
During personalization, the initialization string issued for that token has to be
entered. The initialization string is a 32 hexadecimal character string, in Uppercase
ASCII characters. The token obtains the internal Seed by computing a MD5-hash on
the concatenation of the following:
o Serial Number, a numeric string in ASCII format not exceeding 12 digits in
length. The Serial Number is null-terminated to depict the end of the string.
o Initialization String, 32 hexadecimal character string in Uppercase ASCII
characters
o Optional. A manufacturer specific salt.
The resulting 16-byte digest value is stored as the Secret for the token. The token can
have optionally a means for re-programming which involves erasing the existing
Secret and allowing re-input of a new initialization string for a new Secret.
The token will also random generate a 1-byte value (0 to 255) which is stored as the
Bias.
The length of the one-time password (e.g. 6, 7 or 8 digits) can also be set at this time.

4.2 One-Time Password Generation

When the user depresses the button, the one-time password computation is activated.

Data Preparation
The token reads the system time, and forms a DateTimeString in the form of
YYYYMMDDHHMM. e.g. 28 Sep 2004 2.05pm will be “200409281405” for the
DateTimeString. The DateTimeString represents the <Seed> in the RFC 2289
standard.
A TimeRemaining integer value is obtained as the minimum of {20, 60 – seconds}.
For example, if the time is 2.05.35, TimeRemaining is 20. If the time is 2.05.45,
TimeRemaining is 15. TimeRemaining represents the duration of time that the one-
time password remains displayed.
 The HashCount is an integer representing the <sequence integer> in the RFC 2289
standard and will be computed = 24 – hour. e.g. 2.05pm will be 24 – 14 = 10.

One-Time Password Computation

Initial Step
o The initial Digest is obtained by computing a MD5-hash on the
concatenation of the following:
<Passphrase> consisting of
• Serial Number (not including the null-terminating character)
• Secret
• Bias
<Seed> consisting of
• DateTimeString
o The initial Digest is folded into 8 bytes such that byte 0 is XOR’d with byte
8, byte 1 is XOR’d with byte 9, etc.
o The result of this step is a 64-bit value.
Computation Step
o This step performs HashCount number of MD5 Hashes on the folded result
of the previous operation.
o The input to this step is the 64-bit output of the initial step.
o The output of this step is a 128-bit digest of the last MD5 hash.
Display Step
o The 128-bit Digest output is then folded into 8 bytes such that byte 0 is
XOR’d with byte 8, byte 1 is XOR’d with byte 9, etc.
o For each of the 8 bytes, the corresponding one-time password value for that
position is obtained by multiplying the byte value with 39, dividing the value
by 1000 and truncating off the decimal point. i.e. let xi denotes the i-th byte
value, and ni denote the i-th numeric one-time password digit at the
corresponding i location.

For all i, 0 ≤ i < 8, ni = truncate ( (xi * 39) / 1000 )

The left most significant digits (determined by the one-time password length setting)
is then displayed. The displayed number is the one-time password for that minute.
The duration of display is the number of seconds determined by the TimeRemaining
value. The token should switch off the display once the total time displayed reaches
the TimeRemaining value. The token should also have the functionality to switch off
the display should the user depresses the button before the TimeRemaining duration
is reached.

We show two screen shots of the front end token implementation, one on a Windows PC, and
the other on a J2ME phone.
4.3 One-Time Password Backend Verification

Verification of the one-time password can be carried out by the DSSS Authentication Server
[12].

The DSSS Authentication Server has a single drift window parameter that can be set to
handle the clock drift in the tokens. The drift window parameter value represents the number
of minutes of drift allowed (both forwards and backwards) for the token since the last login.
For example, a drift window parameter value 3 means that the server will allow a drift of up
to 3 minutes forwards and 3 minutes back from the last token login.

Special handling is needed for initializing the token and for the first login.

When the token is defined in the Server, an initialization string is generated for that token.
The transmission of the initialization string to the token user can be in the form of Pin Mailer,
SMS, Bluetooth, infra-red or email.

During the first login, the Server allows a drift from the actual Server time of up to 5 x drift
window parameter. For example, if the drift window parameter value is 3, the server will
allow the token time to be up to 15 minutes before or 15 minutes after the server time. The
server will also compute the Bias and store this secret Bias value in the database. Since the
Bias can range from 0 to 255, there is only a one in 256 possibility (0.4%) that another token
(with the same serial number) will generate the same one-time passwords from the same
initialization string.

5 Analysis

The implementation described in Section 4 is an enhanced version of the RFC 2289 that
addresses some of the vulnerabilities previously highlighted, as well as improves usability of
the RFC 2289. Changes to any front-end implementation of the existing one-time password
system are minimal. Neither the algorithm nor the input parameters is changed. Other
extensions to the RFC 2289 can be similarly applied to this implementation.

The advantages of the enhanced implementation are:

o Addresses the vulnerabilities of Dictionary attacks and spoofing attacks
o Allows for one-button operation in generating a “response-only” numeric one-time
password suitable for easy use.
o Through the use of the Bias, it reduces the chance of 2 tokens having the same
initialization string to display the same one-time password.
o Through the ingenious use of the Bias, it also allows for indirect incorporation of
biometric values to be easily transmitted to the backend for verification.

The only point of contention we note is that the backend system will require to securely
maintain a copy of the <Pass-phrase> in order to verify the one-time password. This is in
contrast to the current RFC 2289 implementation in which the backend only stores the last-
used one-time password. The mitigating factors in place in DSSS’ implementation are that
the <Pass-phrase> will be stored in a secured appliance, and further encrypted using a HSM
(Hardware Security Module).
6 References

[1] Audebert, Y., “System and Method for User Authentication Employing Dynamic
Encryption Variables”, United States Patent Office, Patent no. 5,937,068, 10 Aug 1999.

[2] Cargile, W. P., Freeman, R. D., Lyon, J. M., “Solid State Key for Controlling Access to
Computer Systems and to Computer Software and/or Secure Communications”, United
States Patent Office, Patent no. 4,819,267, 4 Apr 1989.

[3] Haggard, J. C., Hoornaert, F., “Security Access and Authentication Token with Private
Key Transport Functionality”, World Intellectual Property Organization, WIPO No.
WO 00/48064, 17 Aug 2000.

[4] Haller, N., “The S/KEY one-time password system”, In Proceedings of the ISOC
Symposium on Network and Distributed System Security, pages 151--157, San Diego,
CA, February 1994.

[5] Haller, N., Metz, C., Nesser, P., Straw, M., “A One-Time Password System”, RFC
2289, February 1998.

[6] Lamport, L., “Password Authentication with Insecure Communication”,

Communications of the ACM, Vol. 24, No. 11, Nov. 1981, pp. 770-772.

[7] Matsumoto, T., “Human-computer cryptography: An attempt”, In Clifford Neuman,

editor, 3rd ACM Conference on Computer and Communications Security, pages 68-75,
New Delhi, India, March 1996. ACM Press.

[8] McDonald, D. L., Atkinson, R. J., Metz, C. “One-Time Passwords In Everything

(OPIE): Experiences with Building and Using Strong Authentication,” Proceedings of
the 5th USENIX UNIX Security Symposium, June 1995

[9] Mudge, “Vulnerabilities in the S/KEY one time password system”, L0pht.com,
http://www.unix.geek.org.uk/~arny/junk/skeyflaws.html.

[10] Rubin A. D., “Independent one-time passwords, Computing Systems”, The USENIX
Association, Vol. 9, No. 1996, pp. 15--27.

[11] Weiss, K. P., “Method and Apparatus for Positively Identifying an Individual”, United
States Patent Office, Patent no. 4,720,860, 19 Jan 1988.

[12] http://www.dsssasia.com