“Simplicity is the ultimate sophistication,” said Leonardo daVinci. It's an expression that applies very well to security,because as products have become increasingly complex,vulnerabilities have multiplied, resulting in security systems thatare relied on by tens of thousands of organizations beingcompromised.

This is why multi-factor authentication is at a crossroads inits evolution. Attacks on several pre-issued key systems, with the2011 attack on the seed file source code of the market-leadingtoken solution being the most exposed, has highlighted the problemfor both traditional hardware tokens but also more popular softwaretokens.

These solutions use what's known as a pre-issued code. So at anygiven point in time, the token knows a given code, and theauthentication server knows that the token will give that code atthat time. The Zeus malware designed to phish these pre-issuedcodes clearly showed that if the code could be stolen and reused byhackers within the allotted time-frame, the system is no longersecure. And the seed file attack showed that this can be done on alarge scale as well.

The complexity of having both server and token knowing the samecode in advance of the password's usage introduces thevulnerability. This applies to any multi-factor authenticationsolution which generates its passwords in advance of the login time– even if those passwords are one-time usage only. The longer thepassword exists before the user actually requires it, the greaterthe potential risk.

Old Ways Aren't Always Best

Why do the majority of multi-factor authentication systems takethis approach? It's largely because of the user's need to have theappropriate passcode available every time it's required, toinitiate a remote session. However, this reasoning is flawed: itstems from the origins of legacy two-factor authentication, whensecurity systems were not designed with today's pervasiveconnectivity from all types of device in mind.

Even newer, software token-based solutions perpetuate thisfundamental flaw of using time- or event-based, pre-issued tokens.They simply replace a separate hardware token with an app on auser's smartphone, making the device itself the token – but stilljust a plain old token.

This may save on associated procurement and sometimes, butcertainly not always management costs compared with hard tokens,but there's still a risk that a determined attacker could phish acode to make an illicit transaction. Especially as some solutionsallow re-use of the same passcode if a user's initial login attemptfails.

Real Time, One Time Only

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

This would enhance security and reduce the risk of interception,as a potential attacker would not be able to know the passcode inadvance. In addition, the code could be made valid only for asingle login effort and, if that fails, a new code must begenerated. This means that if the code is phished afterthe user enters it, it is invalid and the potential attack will bethwarted.

However, there's also a caveat: the passcode needs to bedelivered to the user in real time, every time and on time. One wayof achieving this cost effectively is to deliver the code via atext message or voice call to the user's phone. As we saw earlier,using the phone as an authentication token delivers savings inprocurement, provisioning and management: users invariably havetheir mobile to hand wherever they are.

Also, delivering the passcode by SMS means users don't even needto have authentication apps on their phone – considerablysimplifying the overall solution. Furthermore, a text message isalmost instant: after all, two generations of teens have relied onit for communications in preference to phone calls, and teens arenot usually known for their patience. Finally, it further boostsauthentication security because the passcode is delivered out ofband, making it extremely unlikely that it could be interceptedbefore the legitimate user receives it and uses it.

Going Further

But what about situations where the mobile signal can'tpenetrate to deliver the text with the passcode – for example insecure data centers (which can sometimes be sited underground), orin high-security workspaces where mobile phones are not permitted?While these situations are specialised, the answer is simple – thesystem should of course have a rollback option giving the useralternative login methods, if necessary, such as direct delivery tothe PC or device that will be used for the session.

As we mentioned earlier, complexity is the enemy of security.Multi-factor authentication solutions that rely on pre-issued codesand distribution of hard or soft tokens have been found to bevulnerable, compared to the simpler approach of using real-time,session-specific passcodes. Simplicity isn't just sophisticated:it's also more secure.

Lars BartholdNielsen, is vice president, Commercial Operations, at SMS Passcode in Brondy,Denmark.