In this post I will describe the need for Two Factor Authentication (2FA), the problems with existing 2FA, , and some of the emerging approaches to introduce stronger authentication methods - in particular, the opportunity to use mobile technology to avoid the hardware costs and introduce much stronger two channel protection.
Some people might start by asking why 2FA is needed in the first place?
Put simply it's too easy for attackers to steal usernames and passwords on the web, and back in the real world it's easy to steal your keys or cards (entry cards or credit cards). The whole point of 2FA is "something you have and something you know" where the card or one-time-password generating token is what you "have", and your PIN/username/password is what you "know". Therefore in theory a thief will have to succeed in both the real world, and the digital world to defeat the authorisation check.
There are three main problems with existing 2FA solutions: Vulnerability to Attack, Expense and Cumbersome Implementations.
Vulnerable to Attack
All systems can be attacked, but the important consideration is how easily they can be attacked successfully. Alas, standard 2FA is all too vulnerable to simple attacks.
For example simple attacks on the most common form of 2FA, the ATM Card and PIN, tend to be based on copying or stealing the physical card after watching the PIN being typed, either with a hidden camera or a real person (shoulder-surfer). We aren't just scare-mongering, Card Fraud has soared in the UK since the introduction of Chip and Pin, but actual numbers are hard to come by as UK card operators charge back the merchants for fraud, and don't bear or report the total loss centrally.
This style of attack works just as well against door entry systems using keys/cards/RFID that are associated with a PIN.
Copying cards should be more difficult than it currently is, but unfortunately there are two major vulnerabilities:
- The Smart-Cards still mix all of the old and new card identifiers on one card, including the raised card number and owner name, and also the magnetic stripe which are child's play to clone.
- Some Chip and Pin implementations use offline checking and a weak cryptographic process which make the card chips easier to clone than they should be, such as cards in France.
Further reading:
- Ross Anderson Phish and Chips
- Chip and Spin
- Cambridge University
- Guardian Newspaper
- Light Blue Touchpaper security blog
- Physical bait and switch with full smartcards: Two chip and pin cards, swapping their transactions.
OTP Attacks
Attacks on the logins protected by One-Time-Password (OTP) devices are equally simple. The key-fob - a device that generates a sequence of numbers that change every few minutes - is considered the physical "something you have" component in 2FA, to go with your password which is "something you know". The best known is the RSA SecureID key-fob style token used to protect corporate VPN logins and some Bank logins.
This can be attacked in a similar way to simple "one factor" password systems with one twist: the Man-in-the-middle or key-logger attacker must use the stolen details immediately, rather than at his leisure. The recent ABN Amro and Citibank attacks used this method
(see Phishers break ABN Amro's 2FA protected Web Banking).
An attacked simply has to:
- Set up a free WiFi hotspot in the middle of a city or airport;
- Use a virus to adjust their "hosts" file;
- Hack any DNS server (when was the last time you checked your home ADSL router, or the one at your hotel? Would you even know if it was compromised?)
Once this is achieved the attacker can redirect users to whatever site they want. This will go undetected as long as the attacker relays almost all pages perfectly to the victim, only stepping in when they log into a bank or corporate site. At that point the attacker makes the login with the user's details (including whatever One Time Passcode they entered), whilst showing the user a "sorry come back in 30 mins" page; the attacker can then do whatever they like, maybe invalidating the login credentials when they leave to make it harder for the user to realise what had happened.
Some 2FA devices, such as the Barclays Card-Reader device, introduce challenge/response codes 
where a code is shown to the user to type into their card reader, along with their pin, so that their card can "sign" the transaction to authorise it.
However these systems are also ready victims to a Man-In-the-Middle attack where a "bait and switch" is performed, just like the physical card attack described above. The attacker shows you web pages that describe the victim's intended transaction, but actually the attacker is performing another. When the attacker is given the challenge code for their criminal purchase, they simply relay it to the victim who dutifully responds with the correct response, however many pins/cards/steps they have taken to process the challenge. The problem is that when the user types in the code to sign, they have no idea what transaction they are really signing.
Expensive and Cumbersome
The hardware key-fob or card reader devices introduced by RSA, Barclays and others are usually fixed lifetime devices that are a burden for customers to keep with them at all times. Some have a planned lifespan of only two years, yet anecdotal evidence presented to me was that over 20% of secure tokens were washed, broken or lost before their natural end.
Additionally, as you increase the number of systems that you want to protect, the number of hardware devices presents an ever greater burden on the end user.
To get around the expense and inconvenience of Hardware Tokens, new Software tokens have been developed which can be used from USB key-fobs, PDAs or Mobile Phones.
One problem with these soft-tokens is that they are often run on untrusted devices at the edge of, or beyond, any corporate security controls. The most vulnerable tokens are those on readily attacked platforms like the USB sticks and PDAs and smart-phones (eg. running the Symbian, Linux or Windows Mobile OSs) that can fall victim to viruses.
Standard phones which are not running a smartphone OS like Symbian, Linux or Windows Mobile are very resistant to viruses. Most can run Java programs, but each program is run in a restrictive "Sandbox" which prevents the program from accessing the files or memory of another program or accessing the hardware of the device in the uncontrolled way that C or machine code programs can. In fact, one of the main reasons that Java was chosen as the language to use on phones was that it's sandbox would help prevent bad or faulty programs from affecting the normal call and message functions of the phone. One day someone might find ways to make a practical virus on these devices, but it has not yet been shown.
The key vulnerability of mobile Java programs is that if an attacker persuades the user to install a new hacked version of an application over the top of a previous application, the hacked version can (if the user permits it) gain access to any data previously stored on the device by the first program, such as the secret seed to the time-sync service that runs the One Time Password Generator, or any other secret part of the OTP/2FA service on the phone. To prevent this happening on the latest handsets you can digitally sign the application to prevent an attacker from overwriting your application, but there are many serious problems with digitally signing applications related to root certificate issues on handsets as noted in a previous blog posting.
Two Channel Protection
Two factor is a good start, but if you are performing challenge-response through just one channel you leave yourself open to hijack or bait-and-switch on that single channel. One approach to improving transaction protection is to perform part of the process through a second channel, where the second channel uses a different trust system and repeats the details of the proposed transaction to the user, so that they can be sure that they are not being tricked.
Mobiles have been used as the second factor already, providing "Soft Tokens" to replace the simple RSA SecureID Tokens, but as simple OTP generators they are just as vulnerable to MiM, if not more so, as they are frequently stolen. However - mobile phones offer the potential to introduce a second channel to the transaction. You can send the transaction details through an encrypted SMS or encrypted GPRS/3G connection, along with part of the transaction authorisation key. The phone will be communicating using a different network, so any virus, local DNS attack, or dodgy WiFi access point will not compromise its security.
Masabi have built a Two Factor, Two Channel Auth system in partnership with GrIDsure, which provides standard off-line time-synchronised OTP generation for logins and low value transactions and secure two channel authentication for more sensitive transactions. For example when adding a new payment recipient to an on-line bank account, the system sends an encrypted SMS message to the user's phone which wakes up the app and shows the user the details of the transaction, before showing the OTP to authorise that transaction. As the transaction details are encrypted with the private key of the card issuer they cannot be adjusted by a man-in-the-middle. The user is also given the option to report a transaction as fraudulent if they had no previous knowledge of the transaction, or the details of the transaction differ between the two channels, thus revealing MiM or bait-and-switch attacks.
The extra twist to this GrIDsure system is that the presentation of the OTP to the user does not give away the actual code or PIN to an attacker or phone thief. The OTP numbers are shown hidden within a grid and the user selects the correct auth code from a secret pattern (PIP) shared between the user and the card issuer, rather than a shared PIN. Because of duplication of the numbers on the grid an attacker or pin thief has to see both the phone and the characters typed into the computer or ATM for many transactions to learn the shared pattern. The user never types the code into the same device that shows the Grid so that only compromising both devices for several transactions will reveal the relationship between grid and code.
This means that the user can use a compromised ATM, Chip&PIN, virus-ridden PC or tell an auth code to a phone operator without revealing their secret pattern.
Full details of our Mobile Two Factor Two Channel system will be published on 4th October on this page.
Other Two Channel Systems
An alternative two channel (or "out of band") system is being promoted by Authentify which calls up the user to confirm large purchases using a normal voice call. We tried their demo and were slightly surprised to find that the voice call did not repeat the transaction details, leaving it open to MiM or bait-and-switch attack, but I'm sure they could improve that with a little development time. Authentify's solution does not really allow the user to detect MiM if the calls are being re-routed, but otherwise their solution is a good step in the right direction.
Also Cronto are using on-screen barcodes to transfer the encrypted transaction details and one time passcode to the user from the merchant or bank website. It relies on the phone having application access to a camera, and they've got to get the cryptography right to prevent a malicious website from adjusting the contents of the barcode, but it's another example of thinking in the right direction.
