Comment: Authentication – The Text Factor

“Simplicity is the ultimate sophistication”, said Leonardo da Vinci. It’s an expression that applies very well to security: as products have become increasingly complex, vulnerabilities have multiplied, resulting in the compromise of security systems that are relied on by tens of thousands of organizations.

This is why multi-factor authentication is at a crossroads in its evolution. Attacks on several pre-issued key systems – with the 2011 attack on the seed file source code of the market-leading token solution being the most exposed – has highlighted the problem for not only traditional hardware tokens, but also more popular software tokens.

These solutions use what’s known as a pre-issued code. So at any given point in time, the token knows a given code, and the authentication server knows that the token will give the code at that time. The Zeus malware designed to phish these pre-issued codes clearly showed that if the code could be stolen and reused by hackers within the allotted time-frame, then the system is no longer secure. In addition, the seed file attack showed that this can be done on a large scale as well.

The complexity of having both server and token knowing the same code in advance of the password’s usage introduces the vulnerability. This applies to any multi-factor authentication solution that generates its passwords in advance of the login time – even if those passwords for one-time use only. The longer the password exists before the user actually requires it, the greater the potential risk.

Old Ways aren’t Always Best

Why do the majority of multi-factor authentication systems take this approach? It’s largely because of the user’s need to have the appropriate passcode available every time it’s required, to initiate a remote session. However, this reasoning is flawed: it stems from the origins of legacy two-factor authentication, when security systems were not designed with today’s pervasive connectivity from all types of devices in mind.

Even newer, software token-based solutions perpetuate this fundamental flaw of using time- or event-based, pre-issued tokens. They simply replace a separate hardware token with an app on a user’s smartphone, making the device itself the token – but still just a plain old token. This may save on associated procurement and sometimes, but certainly not always, management costs when compared with hard tokens, but there’s still a risk that a determined attacker could phish a code to make an illicit transaction. This is especially true because some solutions allow re-use of the same passcode if a user’s initial login attempt fails.

Real Time, One Time Only

So why not use a real-time system where a one-time password code is not calculated in advance, but instead calculated at the time the user is logging into a new session, and tied to that specific login session?

This would enhance security and reduce the risk of interception, because a potential attacker would be unable to know the passcode in advance. In addition, the code could be made valid only for a single login effort and, if that fails, a new code must be generated. This means that if the code is phished after the user enters it, then it is invalid and the potential attack will be thwarted.

Nevertheless, there’s also a caveat: the passcode needs to be delivered to the user in real-time, every time and on time. One way of cost-effectively achieving these goals is to deliver the code via a text message or voice call to the user’s phone. As discussed earlier, using the phone as an authentication token delivers savings in procurement, provisioning and management: users invariably have their mobiles handy wherever they are.

Also, delivering the passcode by SMS means users don’t even need to have authentication apps on their phone – considerably simplifying the overall solution. Furthermore, a text message is almost instant: after all, two generations of teens have relied on it for communications in preference to phone calls, and teens are not usually known for their patience. Finally, it further boosts authentication security because the passcode is delivered out of band, making it extremely unlikely that it could be intercepted before the legitimate user receives the code and uses it.

Going Further

What about situations where the mobile signal can’t penetrate to deliver a text with the passcode – for example, in secure data centers (which can sometimes be situated underground), or in high-security workspaces where mobile phones are not permitted? While these situations are specialized, the answer is simple – the system should, of course, have a rollback option that gives the user alternative login methods when necessary. This could include direct delivery to the PC or device that will be used for the session.

Complexity is the enemy of security. Multi-factor authentication solutions that rely on pre-issued codes and distribution of hard or soft tokens have proven vulnerable at times, especially when compared to the simpler approach of using real-time, session-specific passcodes. Simplicity isn’t just sophisticated, it’s also more secure.

Lars is Nielsen is vice president, Commercial Operations, for SMS PASSCODE. Nielsen has over 25 years of experience in building and managing teams in high-technology companies and oversees marketing, alliances, business development and emerging markets responsibilities.