One-time password

Generation

Concrete OTP algorithms vary greatly in their details. Various approaches for the generation of OTPs include:

• Based on time-synchronization between the authentication server and the client providing the password (OTPs are valid only for a short period of time)
• Using a mathematical algorithm to generate a new password based on the previous password (OTPs are effectively a chain and must be used in a predefined order).
• Using a mathematical algorithm where the new password is based on a challenge (e.g., a random number chosen by the authentication server or transaction details) and/or a counter.

Time-synchronized

A time-synchronized OTP is usually related to a piece of hardware called a security token (e.g., each user is given a personal token that generates a one-time password). It might look like a small calculator or a keychain charm, with an LCD that shows a number that changes occasionally. Inside the token is an accurate clock that has been synchronized with the clock on the authentication server. In these OTP systems, time is an important part of the password algorithm, since the generation of new passwords is based on the current time rather than, or in addition to, the previous password or a secret key. This token may be a proprietary device, or a mobile phone or similar mobile device which runs software that is proprietary, freeware, or open-source. An example of a time-synchronized OTP standard is time-based one-time password (TOTP). Some applications can be used to keep time-synchronized OTP, like Google Authenticator or a password manager.

Hash chains

Each new OTP may be created from the past OTPs used. An example of this type of algorithm, credited to Leslie Lamport, uses a one-way function (call it ${\displaystyle f}$). This one-time password system works as follows:

1. A seed (starting value) ${\displaystyle s}$ is chosen.
2. A hash function ${\displaystyle f(s)}$ is applied repeatedly (for example, 1000 times) to the seed, giving a value of: ${\displaystyle f(f(f(\dots f(s)\dots )))}$. This value, which we will call ${\displaystyle f^{1000}(s)}$ is stored on the target system.
3. The user's first login uses a password ${\displaystyle p}$ derived by applying ${\displaystyle f}$ 999 times to the seed, that is, ${\displaystyle f^{999}(s)}$. The target system can authenticate that this is the correct password, because ${\displaystyle f(p)}$ is ${\displaystyle f^{1000}(s)}$, which is the value stored. The value stored is then replaced by ${\displaystyle p}$ and the user is allowed to log in.
4. The next login, must be accompanied by ${\displaystyle f^{998}(s)}$. Again, this can be validated because hashing it gives ${\displaystyle f^{999}(s)}$ which is ${\displaystyle p}$, the value stored after the previous login. Again, the new value replaces ${\displaystyle p}$ and the user is authenticated.
5. This can be repeated another 997 times, each time the password will be ${\displaystyle f}$ applied one fewer time, and is validated by checking that when hashed, it gives the value stored during the previous login. Hash functions are designed to be extremely hard to reverse, therefore an attacker would need to know the initial seed ${\displaystyle s}$ to calculate the possible passwords, while the computer system can confirm the password on any given occasion is valid by checking that, when hashed, it gives the value previously used for login. If an indefinite series of passwords is wanted, a new seed value can be chosen after the set for ${\displaystyle s}$ is exhausted.
6. Although the server's counter value is only incremented after a successful OTP authentication, the counter on the token is incremented every time a new password is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization. It is recommended to set a look-ahead parameter ${\displaystyle x}$ on the server, which defines the size of the look-ahead window. In case of an accidental password generation by the user, the server will still authenticate the client, because it can recalculate the next ${\displaystyle x}$ OTP-server values, and check them against the received password from the client.

To get the next password in the series from the previous passwords, one needs to find a way of calculating the inverse function ${\displaystyle f^{-1}}$. Since ${\displaystyle f}$ was chosen to be one-way, this is extremely difficult to do. If ${\displaystyle f}$ is a cryptographic hash function, which is generally the case, it is assumed to be a computationally intractable task. An intruder who happens to see a one-time password may have access for one time period or login, but it becomes useless once that period expires. The S/KEY one-time password system and its derivative OTP are based on Lamport's scheme.

Challenge–response

The use of challenge–response one-time passwords requires a user to provide a response to a challenge. For example, this can be done by inputting the value that the token has generated into the token itself. To avoid duplicates, an additional counter is usually involved, so if one happens to get the same challenge twice, this still results in different one-time passwords. However, the computation does not usually involve the previous one-time password; that is, usually, this or another algorithm is used, rather than using both algorithms.

Implementations

SMS

A common technology used for the delivery of OTPs is text messaging. Because text messaging is a ubiquitous communication channel, being directly available in nearly all mobile handsets and, through text-to-speech conversion, to any mobile or landline telephone, text messaging has a great potential to reach all consumers with a low total cost to implement. OTP over text messaging may be encrypted using an A5/x standard, which several hacking groups report can be successfully decrypted within minutes or seconds. Additionally, security flaws in the SS7 routing protocol can and have been used to redirect the associated text messages to attackers; in 2017, several O2 customers in Germany were breached in this manner in order to gain access to their mobile banking accounts. In July 2016, the U.S. NIST issued a draft of a special publication with guidance on authentication practices, which discourages the use of SMS as a method of implementing out-of-band two-factor authentication, due to the ability for SMS to be intercepted at scale. Text messages are also vulnerable to SIM swap scams—in which an attacker fraudulently transfers a victim's phone number to their own SIM card, which can then be used to gain access to messages being sent to it.

Hardware tokens

RSA Security's SecurID is one example of a time-synchronization type of token, along with HID Global's solutions. Like all tokens, these may be lost, damaged, or stolen; additionally, there is an inconvenience as batteries die, especially for tokens without a recharging facility or with a non-replaceable battery. A variant of the proprietary token was proposed by RSA in 2006 and was described as "ubiquitous authentication", in which RSA would partner with manufacturers to add physical SecurID chips to devices such as mobile phones.

Recently, it has become possible to take the electronic components associated with regular keyfob OTP tokens and embed them in a credit card form factor. However, the thinness of the cards, at 0.79mm to 0.84mm thick, prevents standard components or batteries from being used. Special polymer-based batteries must be used which have a much lower battery life than coin (button) cells. Semiconductor components must not only be very flat but must minimise the power used in standby and when operating.

Yubico offers a small USB token with an embedded chip that creates an OTP when a key is pressed and simulates a keyboard to facilitate easily entering a long password. Since it is a USB device it avoids the inconvenience of battery replacement.

A new version of this technology has been developed that embeds a keypad into a payment card of standard size and thickness. The card has an embedded keypad, display, microprocessor and proximity chip.

Soft tokens

On smartphones, one-time passwords can also be delivered directly through mobile apps, including dedicated authentication apps such as Authy and Google Authenticator, or within a service's existing app, such as in the case of Steam. These systems do not share the same security vulnerabilities as SMS, and do not necessarily require a connection to a mobile network to use.

Hard copies

In some countries' online banking, the bank sends to the user a numbered list of OTPs that is printed on paper. Other banks send plastic cards with actual OTPs obscured by a layer that the user has to scratch off to reveal a numbered OTP. For every online transaction, the user is required to enter a specific OTP from that list. Some systems ask for the numbered OTPs sequentially, others pseudorandomly choose an OTP to be entered.

Security

When correctly implemented, OTPs are no longer useful to an attacker within a short time of their initial use. This differs from passwords, which may remain useful to attackers years after the fact.

As with passwords, OTPs are vulnerable to social engineering attacks in which phishers steal OTPs by tricking customers into providing them with their OTPs. Also like passwords, OTPs can be vulnerable to man-in-the-middle attacks, making it important to communicate them via a secure channel, for example Transport Layer Security.

The fact that both passwords and OTP are vulnerable to similar kinds of attacks was a key motivation for Universal 2nd Factor, which is designed to be more resistant to phishing attacks.

OTPs which don't involve a time-synchronization or challenge–response component will necessarily have a longer window of vulnerability if compromised before their use. In late 2005 customers of a Swedish bank were tricked into giving up their pre-supplied one-time passwords. In 2006 this type of attack was used on customers of a US bank.

Standardization

Many OTP technologies are patented. This makes standardization in this area more difficult, as each company tries to push its own technology. Standards do, however, exist – for example, RFC 1760 (S/KEY), RFC 2289 (OTP), RFC 4226 (HOTP) and RFC 6238 (TOTP).

Use

Mobile phone

A mobile phone itself can be a hand-held authentication token. Mobile text messaging is one of the ways of receiving an OTAC through a mobile phone. In this way, a service provider sends a text message that includes an OTAC enciphered by a digital certificate to a user for authentication. According to a report, mobile text messaging provides high security when it uses public key infrastructure (PKI) to provide bidirectional authentication and non-repudiation, in accordance with theoretical analysis.

SMS as a method of receiving OTACs is broadly used in our daily lives for purposes such as banking, credit/debit cards, and security.

Telephone

There are two methods of using a telephone to verify a user's authentication.

With the first method, a service provider shows an OTAC on the computer or smartphone screen and then makes an automatic telephone call to a number that has already been authenticated. Then the user enters the OTAC that appears on their screen into the telephone keypad.

With the second method, which is used to authenticate and activate Microsoft Windows, the user call a number that is provided by the service provider and enters the OTAC that the phone system gives the user.

Computer

In the field of computer technology, it is known that using one-time authorization code (OTAC) through email, in a broad sense, and using one-time authorization code (OTAC) through web-application, in a professional sense.

• An email is one of the common ways of using OTACs. There are two main methods used. With the first method, a service provider sends a personalised one time URL to an authenticated email address e.g. @ucl.ac.uk; when the user clicks the URL, the server authenticates the user. With the second method, a service provider sends a personalised OTAC (e.g. an enciphered token) to an authenticated email address; when the user types the OTAC into the website, the server authenticates the user.
• A web application can generate a unique personal identification number (PIN) that the user can input into the desktop client, the desktop client, in turn, uses that code to authenticate itself to the web application. This form of authentication is particularly useful in web applications that do not have an internal username/password store but instead use SAML for authentication. Since SAML only works within the browser, a desktop-based web application client cannot successfully authenticate using SAML. Instead, the client application can use the one-time authorization code (OTAC) to authenticate itself to the web application. In addition, it is possible to use the OAuth authorization framework when a third-party application needs to obtain limited access to an HTTP service.

Post

It is possible to send OTACs to a user via post or registered mail. When a user requests an OTAC, the service provider sends it via post or registered mail and then the user can use it for authentication. For example, in the UK, some banks send their OTAC for Internet banking authorization via post or registered mail.

Expansion

Quantum cryptography, which is based on the uncertainty principle is one of the ideal methods to produce an OTAC.

Moreover, it has been discussed and used not only using an enciphered code for authentication but also using graphical one time PIN authentication such as QR code which provides decentralized access control technique with anonymous authentication.