From OTP (One-Time Password) to OTID (One-Time ID)
One-time passwords, or OTP for short, are generally considered more secure than traditional passwords, for a very simple reason: they can be used only once. The next time a user wants to log into a portal, web app, or mobile app protected by OTP they’ll have to use a newly generated password as the one they previously used will (likely) not work anymore.
That’s the simplistic (maybe too simplistic) explanation. Of course, real life applications of one-time passwords are — in general — far more complex than that. They have to take into account users who generate one-time passwords but don’t use them, maybe they forgot or changed their mind before completing the authentication process, and a good system administrator knows that such “forgotten OTPs” cannot live forever. One cannot afford to have rogue yet valid OTPs roaming around, as they could potentially be acquired and used at a later time by a malicious attacker, if they’re still valid simply because no one has used them yet.
Therefore, most OTP standards are time-based. Generated OTPs must be used within a specified time window (generally 30 seconds to 2 minutes) or they will expire and won’t work anymore. This is the reason why, after a less than warm reception of the HOTP standard by the IT community, the TOTP standard has been developed.
Yet, all one-time password algorithms and standard only address the “password issue”, they do absolutely nothing to protect the so-called claimed identity. Let me explain…
In every OTP-based authentication scheme, the user has to provide their claimed identity first. Typically this is done by providing a username. Once the portal (or web app, or mobile app) learns who the user claims to be, then and only then it will try to authenticate such user with an OTP. The idea behind it is that the remote service is telling the user “let me verify that you really are who you claim to be”.
What the reader will surely notice is that in both typical schemes depicted in the two images here above the user will send their claimed identity (username) to the service they want to authenticate against. And that, in my opinion, is already way too much information given away to a potential attacker.
A better way to use OTPs would be to find a way to conceal your authentication information completely, including the username or whatever form of claimed identity the user needs to use.
Enter Xiid OTID (one-time ID). Here’s a UML chart:
The first thing to notice is that the user experience is quite similar to the easiest and most effective version of OTP. But there is a remarkable difference: with Xiid OTID the claimed identity (typically the username) is never sent over the network, only the OTID code is sent, which is a one-time code that does not contain any useful information for a potential attacker.
OTID format example: 12K8–33FA-GH7R-92VA
Thanks to Xiid’s patent-pending OTID technology, only the actual Service in charge of authentication can infer or compute which specific user the OTID belongs to, and then verify the one-time information contained inside of it to grant or reject the now-known-user access to the Service.
A single “meaningless” (for an attacker) one-time code, that changes every time, that doesn’t give away literally any information about the user (including their claimed identity) and provides a higher degree of resilience against a higher number of typical attacks targeting authentication systems.
But why is it so important to conceal your claimed identity? Think about it: if an attacker gets to know who you claim to be (maybe your username is your email address, so they already also know how to contact you) they already have enough information to attempt some attacks, like educated password guessing, password harvesting or — even worse — social engineering. But if there is no way for an attacker to even guess “who” is attempting to log in, then they really have nothing meaningful to work on.
Another step forward towards ensuring users’ identity protection.
