The search for alternative, safe, easy, and inexpensive user authentication methods has become a very central question due to the rise of attacks targeting and defeating user passwords (see e.g. link). However, “inexpensive” at the Internet scale is contradictory to “safe”, so the search for better compromises than passwords looks both like a Graal quest and squaring the circle. In this post, I look at how secure the proposed alternatives are.

Security vs. All the rest

When designing an aircraft or a power plant, safety (security) is paramount. Some would call it sad, but for online services it’s different. A website or Corporate access has to be “safe enough” as far as user accounts and data are concerned, but other design objectives must be satisfied first, such as costs and user experience. Obviously, an inexpensive but improper authentication adds indirect costs (e.g. in the hotline) but that’s another story I won’t discuss in this post.

When passwords are no longer seen as safe enough in a given context, alternatives must be found that improve security and are still both affordable and acceptable. The market is full of secure authentication solutions, but what does ‘secure’ really mean?

A system is as secure as its weakest component. In an authentication solution, there’s a user component and a server component, their security principally relates to the complexity of extracting secret data that they contain and to the possibility to bypass or to spoof the component itself. Let’s take a few examples.

How short text codes are defeated

Despite its costs and the unpredictable delivery time of short text messages, authentication based on codes sent to cellphones has been very successful for online payments and e-banking transactions, because everyone has a phone, and there is basically nothing to explain or to do beyond having a verified phone number for all users.

However, people sometime change phone number, so there must be a process (online or via a call center) to update the number to which codes are sent. That’s Achilles’ heel, because that process can’t rely on a short text based authentication. Someone impersonating you in this process will then receive the confirmation codes for transactions performed on your accounts. Of course, this is a targeted attack, so the bad guys have to collect enough information to be able to impersonate their targets, but it works.

Now, there’s worse: malwares have been designed and spread on numerous smartphones to silently forward short texts. This is no longer a targeted attack, it was performed successfully on a very large in Europe in 2012.

So, unlike sometimes heard, short text based authentication can be bypassed quite easily, because the bad guy doesn’t need to have your phone.

The biometry long term advent

I won’t spend too much time now discussing biometry security, because biometry is not yet a realistic method for online authentication. This will need sensors to provide open and standard APIs (or APIs at all, cf. our post on Apple TouchID) – that’s the main purpose of FIDO Alliance (so many topics for future posts…). This will need Apple to support similar industry-wide initiatives – not something the Cupertino firm has much used us to so far. Lastly, this will need mobile web browsers to support such APIs – not the case for iOS and Android mobile browsers so far. So, there’s plenty of time to discuss biometry security for online services…

Multi-factor and multi-step

This is the interesting part of this post, because this is also where there’s a big confusion.

Multi-factor authentication (MFA) or, in practical terms, two-factor authentication, basically means that knowing your password is not enough to access your online account. Something more is needed, called a second factor. It can be one of your devices that would have been enrolled, or a specific device like a key-chain token, a USB dongle, a badge with or without a smartcard on it… It may sound complex and cumbersome, however, MFA can be made completely invisible to end-users as it is the case with inWebo smart ‘tokens’. This additional factor, in most cases, is both a piece of information (‘keys’) that is unique to you, and an algorithm that would generate one-time identity proofs based on the authentication factors. These proofs are valid – and you can get access – if and only if you hold all factors. Multi-step authentication refers to a particular subset of multi-factor authentication methods where the factors are sequentially submitted, for example first entering your usual password, then entering a code received on your cellphone or generated on a key-chain token.

A thorough discussion of MFA security would require to be specific, in particular to discuss the various options’ vulnerability to attacks such as replay, phishing, MITM, and MITB, then to make a chart to recap and to compare… I will only mention that phone-based OTP authentication is subject to phishing and MITM, unless there’s some form of prior user authentication (e.g. at least a signed cookie including a one-time nonce); and that MITB can’t be countered with a single-channel approach, no matter what you can read on some vendors’ websites – like for squaring the circle, it’s proven that there’s no solution, but genial inventors keep sending articles to the Academy of Sciences.

However, the confusion is not really with phishing, MITM or MITB. The confusion is, more fundamentally, to mistake MFA for security. Indeed, MFA brings additional security compared to passwords only if all factors are seriously protected, both on the user side and on the server side. Don’t take it for granted, none of the above is obvious.

On the user side, smartcards were considered a good protection of users’ keys, but academic research has recently proven that many (most?) of the vendors’ implementations were weak. Worse, most (all?) vendors also propose software implementations of key-chain tokens (“soft-tokens”, e.g. mobile Apps) were there is no possible efficient protection of the keys. Encrypting the keys doesn’t change the situation, but helps the Marketing departments: MFA is mistakenly and somewhat intentionally assimilated to security. inWebo approach, replacing fixed keys with randomly dynamic credentials – hence protecting against the use of stolen or exposed keys -, seems to be unique.

Cloud-based authentication

Most (all?) vendors now propose Cloud-based versions of multi-factor authentication servers. In an MFA solution, the server plays the same role as the password database: this is the place where user authentication data is checked during the login phase. Protecting the users’ keys on the server side is awfully complex, even in a private infrastructure – not to speak about a public Cloud, but we don’t want to reopen the debate about comparing security in private infrastructures vs. public Clouds. Protecting keys on server side is not a question of size or respectability of the vendor: millions of user keys were stolen in 2011 in the market leader databases after a successful and highly sophisticated attack exploiting APT (advanced persistent threats) was performed. Here again, encryption helps Marketing departments but doesn’t really affect the ability for serious hackers to access users’ keys or bypass software-enforced security rules. Hardware enforcement of encryption, authentication and security rules is the only serious approach to that concern. inWebo also appears as a pioneer in the way they have envisioned Cloud-based authentication security.

The right mix

It is an easy conclusion: if you need to manage risks associated with accounts takeover, better try to enforce strict password policies unless you’re forced to MFA by regulation, or you think that your users won’t accept such measures. And if you really opt for MFA, don’t confuse the means with the ends: target secure – yet affordable / acceptable – implementations, not just inexpensive ones. I hope this post will help you better evaluate what secure MFA is.