Mobile OTP - Secure?

Question

I came across Mobile-OTP, "a de facto standard for strong mobile authentication" (http://motp.sourceforge.net). The developers claim that it is very secure etc.

Reading through the implementation, I noticed that the scheme requires the user's PIN to be stored in reversible form on the server side. (the sourceforge implementation stores them plain text), which I think is not a very desirable feature.

My questions are

• Is Mobile-OTP a well known scheme?
• Is it considered secure?
• What would be the reason to choose it?
  (why choose it over SSL for example?)

Answer 1

First time I've heard about this, but it doesn't mean it's not well-known.

Sounds a little similar to OATH HOTP / TOTP. OATH is based on RFC 4226 and seems at least at a first glance more robust. For example it uses HMAC instead of simple hash (motp uses MD5). OATH was also adopted by products like Yubikey and recently Google Authenticator.

Based on these very shallow facts, I'd say I would personally prefer OATH over this seemingly-bespoke solution. It would require a deeper analysis to really flash out the advantages/disadvantages of those schemes.

I hope this answers your first two questions.

As for the reasons for choosing it - One Time Password (OTP) not only protects against eavesdropping over the communication line. So whilst SSL will ensure the password (or one-time-password) is transported securely, OTP ensures that even if the password is lost/stolen, it cannot be re-used. It's unique for every session. So even if someone looked over your shoulder when you typed your password, since it's a one-time password, they can't use it again.

There are some other advantages to OTP schemes, in this case it acts as a 2nd factor authentication. Not only what you know, but also what you have. In those mobile-based OTP schemes, it's usually some secret key that is stored on your phone and is used to generate the password. So an attacker will not only need your password, but also your phone (or the key on your phone), in order to authenticate as you.

Most authentication schemes are complementary to SSL and wouldn't replace it. Even if the authentication process is secure, there's usually other data being exchanged, or some kind of session established. For example, consider logging into your bank account, and then viewing transactions or transferring funds. Protecting the authentication alone (e.g. via OTP) is not enough. Same goes to just protecting the connection (using SSL without authentication). To protect it better you'd usually combine SSL with some form of user authentication.

Regarding your concern about storing PIN/key in reversible form rather than using a secure-hash. I would say this is probably an acceptable trade-off considering what you gain. OTP gives you great protection against cases where the static password might be leaked (including phishing, over-the-shoulder, people writing down their passwords, social engineering etc). Even if one OTP password is leaked, it limits its usefulness -- it can only be used once and within a limited timeframe typically. The downside is that you have to make sure your authentication server (and to some extent user devices) are well-protected. If your server is your weak-spot, then, I'm not sure secure hashes alone are going to be enough to protect you anyway. Plus, combining it with SSL and a standard (hashed) password could really boost your protection even further.

Answer 2

The scheme has some security limitations. A one-time password is not secure against man-in-the-middle attacks, unless there is some other out-of-band mechanism to prevent man-in-the-middle attacks. It is also a bit inconvenient to use.

Depending upon the context, there may be better ways of authentication. For instance, if you are going to build an app, in many settings you'd be better off to use SSL with a client cert (you can require a PIN or password as well once the channel is set up if you prefer).

Using the one-time password is very likely to be better than nothing. It may stop some threats.

Bottom line: It all depends upon what you are planning to use this for. Depending upon the application domain, it might be a useful tool, or it might be sub-optimal. If you want more specific advice, I suggest describing the specific application context in which you need authentication, and perhaps explain the risk level / threat model you have in mind.

Answer 3

MOTP is an authentication protocol. The intended use scenario is a user with some kind of mobile device wishing to authenticate with a server; the device generates an authentication code which is only valid for a limited time (a few minutes). The authentication is based on a shared secret between the client side and the server side.

On the client side, the secret is split into two parts: a 64-bit secret which is held inside the device (what you have), and a 4-digit PIN that the user must enter every time (what you know). In this way, MOTP provides two-factor authentication. The device does not know the PIN, it blindly computes the authentication value from the supplied PIN each time.

A typical MOTP device has a keypad and a screen capable of displaying 6 digits, a processor with very low performance requirements (must be able to compute an MD5 of 20 bytes in the blink of an eye), a clock, and possibly some tamper resistance to protect the secret. There are single-purpose MOTP devices as well as implementations on mobile phones. On a single-purpose device, the device displays a 6-digit authentication code which is valid for a couple of minutes (3 minutes minus the time it takes from computing the authentication code on the client to the verification on the server, plus or minus the consequences of clock drift). On a mobile phone, the authentication code may either be displayed or directly used by the client application.

MOTP has the advantage of being very simple. There are plenty of existing implementations in various languages and on various platforms, both on the server side and on the client side. As far as I know, MOTP came from the industry and has seen little if any independent review.

The PIN is part of the shared secret between the client and the server. The server needs to perform the same computation as the client, it needs the PIN for that. You could make a variant of MOTP that uses some the image of the PIN under some strengthening function instead of the PIN itself, but there would be no benefit, as a hash on a search space of barely 10 bits is trivial to brute-force even if you had to do it separately with each differently-salted account. Servers don't store passwords because those are supposed to have enough entropy to make brute-force hash reversing difficult, this does not apply for a 4-digit PIN.

MOTP is not comparable with SSL; you would use the two in combination. The two of them can be used in a complementary fashion. SSL has three parts: it establishes a secure channel between two parties, it authenticates the server to the client, and it optionally authenticates the client to the server. The third part is often left out because most clients have no authentication data, which leads to a lot of software using SSL not supporting client authentication. MOTP can be a way to authenticate a client on an SSL connection. Unlike SSL client certificates, which typically authenticate a device or a combination of a device plus the data stored on it, MOTP is intended to authenticate a user; the authentication step requires entering a PIN (which is typically not cached).