OCRA Algorithm Explained

Posted By Anna on Jun 17, 2020 | 0 comments

OCRA, or OATH challenge-response algorithm is the most reliable multi-factor authentication algorithm yet. OCRA algorithm is proved to be the safest one created by the OATH (OpenAuTHentication initiative) as it allows a challenge input to be used for one-time passcode generation alongside the secret key (seed) and a counter or time. 

The key difference of the challenge-response authentication algorithm from the older OATH algorithms HOTP and TOTP is the capability to identify the server. The end-user can be assured in the server authenticity, which significantly adds to the security.

OCRA token is usually a keypad-style device or an app. As OCRA meaning might suggest, the algorithm utilizes a certain challenge and a response to it. So a notional challenge-response example would look something like this:

• the website or app, a client tries to log into, provides a code (this will be the challenge)
• the client needs to enter this code into the token
• which in its turn returns another code (this will be the response)
• the client then enters this response code to login.

In this article, we will take a closer look at OCRA and its background, see in detail how it works and find out how Protectimus implements it.

OCRA Background — HOTP & TOTP

The challenge-response algorithm can be identified as an advanced HOTP, the logical next stage of its evolution. Here, instead of employing a counter like it’s done in HOTP, we can employ any data (including the time like in TOTP) as an authentication challenge.

HOTP

OATH has been working on OTP algorithms since 2004. The initial outcome of those efforts was the Hash-based Message Authentication Code OTP algorithm — HOTP, published as an IETF (Internet Engineering Task Force) project in 2005.

HOTP algorithm allows generating one-time passwords by utilizing a secret key and a counter. The token’s counter scales up each time the button on the device is clicked, the server counter scales up with each validated OTP. 

We’ve already published an article on HOTP, so we won’t delve into details here. Suffice to say — the algorithm had a few drawbacks, plus the technology evolves very fast so new security challenges arise fast as well. So OATH continued its work in pursuit of the most trustworthy verification method.

TOTP

The next expansion was put out in 2008. Unlike HOTP, the new method, named Time-based One Time Password or TOTP for short, does not utilize a counter for the server-user synchronization but generates a password based on the current time. The advantage of the TOTP password is a limited lifetime, usually 30-60 seconds.

The end-user’s TOTP token has a secret key and the current time value, these two are hashed with any hash function and the result hash value is truncated, that’s how we get a one-time password that should be sent to the server. The server in its turn has the same secret key as the user’s token and, naturally, the same time value. So the server makes the same calculations and compares the end values.

| Read also: Time Drift in TOTP Hardware Tokens Explained and Solved

OCRA

Finally, in 2010 the OCRA authentication was presented in IETF RFC 6287. OCRA algorithm expanded TOTP further by introducing the challenge-response mode to calculate OTP values. The key difference of the challenge-response authentication from the older methods of authentication is the capability to identify the server. With the challenge security the end-user can be assured in the server authenticity, which adds to the security significantly.

How OCRA algorithm works

As you’ve seen in the OCRA algorithm example at the beginning of the article, the OCRA login requires a client’s input before producing an OTP. According to IETF, this input can be any variable data agreed upon by both parties (token and server): a counter as in HOTP, a timestamp like in TOTP, a PIN, a word, a session identifier, even a question-answer pair. This input parameter also has to announce which data and which hash functions are being in use, so there’s a header incorporated with the data. If you are interested, you can see a more specific challenge-response authentication example at the OCRA RFC 6287.

We’ve already mentioned the most important difference of OCRA – while in both HOTP and TOTP only the server has the ability to prove true the user’s identity, the other way around is not possible. The OCRA OATH challenge-response algorithm allows the verification to go both ways. OCRA simply permits the end-user to issue a challenge for the server. So, with the mutual mode two separate calculations happen, one client->server, and one server->client.

Finally, there’s a “plain signature mode”, this one does not require a shared seed, so any user can sign it. The server provides a challenge, a user needs only to sign and send the response back. This mode is handy for tracking, but can be coupled with the common challenge-response thus creating a so-called “signature with server authentication mode”.

| Read also: 2FA Security Flaws You Should Know About

Transaction data signing

More advanced use of OCRA is the transaction data signing method. Here the client can verify and confirm a transaction by confirming certain details of it. Things like the recipient’s account number, currency, and amount, can be used to verify a financial operation with this method.

Using this approach we created the Protectimus Confirm What You See (CWYS) data signing function. With CWYS the OTPs are created using the data of the user’s current transaction or operation. For example, a user needs to transfer a significant sum of money. When the transaction is created the user’s protected system (bank website or app) sends a data signing request and Protectimus CWYS provides a QR code, which the user scans and checks if the displayed data is matching (this can be the sum, the currency, the account data, etc.). If everything looks ok the user enters the OTP provided by their token to confirm the transaction. Here’s a more detailed description and you can try how a challenge-response protocol example works at this demo page.

This method is second to none in preventing phishing attacks, banking Trojans, injection and man-in-the-middle assaults, and password interception.

| Read also: Best Protectimus MFA Features for Financial Services Cybersecurity

Protectimus OCRA tokens

Protectimus Smart OTP	Protectimus Ultra
An OATH OCRA token has to be able to run the OCRA functionality, obviously. And the ability to visualize the data is another requirement if you are looking for the full capacity of CWYS. Currently, the best choice among Protectimus OCRA tokens is the app Protectimus Smart. Here the OCRA token activation takes mere seconds, all the tokens created with the app support the CWYS function, and the app is absolutely free of charge.	A hardware token that supports the OCRA algorithm is Protectimus Ultra. Being a hardware token this one is considered to be more secure, since it does not have any network connections. But this token can not visualize the data as the app does. And it’s available for order from 500 pieces only.

Read more

• Active Directory Two-Factor Authentication
• Two-Factor Authentication Solutions Comparison: Google Authenticator vs. Protectimus
• Duo Security vs Protectimus
• Two-factor authentication for Windows 7, 8, 10
• Remote Work: How to Transition Team to Working From Home During the COVID-19 Pandemic
• Sophos 2FA with Hardware OTP Tokens
• 2FA Chatbots vs. SMS Authentication
• SMS Authentication: All Pros and Cons Explained