News
Lars Nielsen, SMS Passcode: Authentication: the Text Factor
March 2013 by Lars Nielsen, SMS Passcode
“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 security systems that are relied on by tens of thousands of organisations being compromised.
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 both 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 that 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, the system is no longer secure. And 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 which generates its passwords in advance of the login time – even if those passwords are one-time usage 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 device 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 compared with hard tokens, but there’s still a risk that a determined attacker could phish a code to make an illicit transaction. Especially as 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, as a potential attacker would not be able 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, it is invalid and the potential attack will be thwarted.
However, 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 achieving this cost-effectively is to deliver the code via a text message or voice call to the user’s phone. As we saw earlier, using the phone as an authentication token delivers savings in procurement, provisioning and management: users invariably have their mobile to hand 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 it and uses it.
Going further
But what about situations where the mobile signal can’t penetrate to deliver the text with the passcode – for example in secure data centres (which can sometimes be sited underground), or in high-security workspaces where mobile phones are not permitted? While these situations are specialised, the answer is simple – the system should of course have a rollback option giving the user alternative login methods, if necessary, such as direct delivery to the 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 codes and distribution of hard or soft tokens have been found to be vulnerable, compared to the simpler approach of using real-time, session-specific passcodes. Simplicity isn’t just sophisticated: it’s also more secure.
