Comparison of TAN mechanisms and alternatives

17 Apr 2019 - tsp

This blog post should provide a short overview of TAN alternatives and methods as well as their pitfalls and security.

The presented ones are:

And at the end a short

Traditional TAN

In traditional TAN environments the user gets a list of transaction authorization numbers which is an unordered set of numbers of a fixed length. Whenever the user wants to authorize an transaction he can use any of the provided numbers - any number that hasn’t been used up to this point and is contained on an unexpired set of TANs can be used to authorize an operation.

This method has been seen as unsafe for a longer time (justified). The main problem is that this mechanism is particular prone for phishing attacks - an attacker can trick an user into entering any TAN anyhwere and use it so sign any operation in the future - and the user won’t re-use that TAN since he thinks that it had already been used.

If one neglects phishing the probability of completing a transaction with a single request - for numeric TANs consisting of $n$ numeric characters chosen of the list of $m$ valid TANs $m * \frac{1}{10}^n$. So if one uses the typical $6$ digit TANs on a list of 25 TANs the probability of executing an operation is about $0.0025$ percent. This may seem low but since one has multiple tries during an automated attack (one has to guard such a system against repeated invalid tries - without opening the door for denial of service attacks - so one cannot simply lock an account for which an attacker tries multiple transaction authorizations) the probability is not that low.

Main attack vectors:

Indexed TAN

Since traditional TANs are that prone for phishing attacks indexed TAN lists have been introduced. In this case there is a set of $m$ numbers as before but they are ordered and numbered. In case a user wants to authorize an operation he is asked for a specific TAN instead of any TAN. Since every TAN is only asked for exactly once this reduces the probability of guessing correct by $\frac{1}{m}$ compared to the traditional TAN list. On the other hand - depending if one completely locks TANs that have not been sent properly - this might open the door for denial of serivce attacks. One may also only temporarily block usage of such numbers or block them from given sources, etc.

The main attack surface for iTAN is malware that executes on the computer or is capable of alterning network traffic (for example by running on proxy servers and having people ignore certificate security warnings of their web browsers) and again phishing attacks. In case of malware software may alter the transaction details displayed to the user - letting the user enter an iTAN to authorize a totally different transaction.

Main attack vectors:

SMS based transaction authorization

This is the weakest method and even less secure than TAN and iTAN. The idea is that a user requires to own his phone to receive an SMS after an operation has been requested. This SMS contains a unique transaction authorization number that is valid for the requested transaction (many times these SMS should also contain a description of the operation that will be authorized by this code so people can check that malware hasn’t altered their requested operation during transfer to the service).

The main problems with this approach are:

SMS based authorizations are that unsafe that they are explicity not recommended with standards like NIST SP 800-63B.

Main attack vectors:

Mobile app based transaction authorization

This is again on of the weaker authorization methods. In this case an application is installed on the mobile phone of the user who wants to authorize an operation. He issues the request on his computer or another device, gets a push notification on his mobile and responds there granting or declining the operation. The application might use strong authentication (for example using public key authentication - maybe even using hardware security modules like SIM cards or keys stored in some secure storage that’s accessed via secure enclave of the mobile device) to authorize itself against the webservice that is notified about the users decision.

This may sound like a good idea on the first hand - and in theory it is as long as the mobile device is secure.

On the other hand every mobile phone that’s capable of executing such authentication applications currently out there is vulnerable to a whole bunch of attacks:

There is a whole bunch of known malware attacking banking App-Tan applications lie Zeus, Game over Zeus, Citadel, etc. Most of the time this malware is distributed via spam or scaming attacks. There have also been trojans and worms that tried to automatically correlate mobile devices and malware via sidechannels like identifying the networks hosts and mobiles had been using, using UXO, etc.

Main attack vectors:

TOTP / HOTP token

These methods have one thing in common: They use a seed that the issuer of the token (the entity that asks for your authentication) and the device that one uses know. They use this seed to derive a TAN that’s either changed on basis of the time (TOTP) or based on the number of previously generated TANs (HOTP). There are multiple common implementations of these tokens - beginning from Software implementations like the Google Authenticator app and ending at hardware implementations that do not have any network connection to the outside. The latter ones are already commercially available (like the RSA SecurID system).

The key requirement for such systems to be safe is that the seed is only ever known to the device issuing the tokens and the service that one authenticates against. As soon as a third party gains knowledge of the seed this third party can issue any authorization it desires. In case the manufacturer pre-programmes the tokens a hack of the manufacturer may compromise a large amount of services as has happened during the hack of RSA SecureID (which has been an intersting thing on it’s own if one reads how the hackers managed to compromise the system - it all started with MS Word on a secritary’s computer). Also a hacked backend database on the service side allows the attackers to forge any users confirmations without having a ability to discriminate between the forged ones and the ones generated by the users.

As long as these systems are used on dedicated hardware the only pitfalls are leaked / stolen seeds and malware displaying different information inside the applications / webpages that ask for authorization. So these methods are prone for authorizing different actions when malware gains access to computer systems.

Main attack vectors:

ChipTAN / PhotoTAN / FlickerTAN

This method removes the need for the TAN generator to have a permanent network connection which provides an enormous gain in safety. Most of the time the smartphone is used for PhotoTAN - so the same problems apply as for application based TAN and SMS. If an external device is used (like with ChipTAN most of the time - they use devices like the RainerSCT) this methods may provide a suiteable way of issuing TANs as long as the generation algorithm which noramlly is based around an known seed as well as an hash or symmetric encryption algorithm (applied in a special way) is used or the transaction details are signed with a public key mechanism. The transaction details which are included in the visually transferred and captured barcode that’s required by these generators have to be included in the hash generation (for example one can combine the generated OTP token with the transaction details and hash them both to generate the TAN that has to be entered by the user).

The major drawback when done safely is that the user requires an addition device instead of his mobile phone - that device should not have any communication abbilities despite the visual recognition of the transaction details and a display to display the transaction details and the corresponding TAN.

Main attack vectors:

Signature based

These are of course as always the most secure ways - if the keys are managed in a safe way and the users cannot be forged into signing other content than they think they do. Basically it’s application of strong public key signatures with which one can sign a request.

The key point is securing the signature keys. If they are only stored in some device memory like your computers or mobile phones storage they are as safe as your device is (and note that there are sidechannels - for example cache timing attacks - that allow readout of memory regions even from JavaScript, even though browser vendors try to convince one that they apply countermeasures - but it has been shown that there is always a way to get enough timing resolution to steal data from other applications on the same physical hardware as long as these applications are not developed in a way to prevent such attacks from end to end).

The safest way to store keys is an external hardware security module (HSM) or a smartcard. In case of smartcards and HSMs the second important thing is how they are commanded to sign content. If content is sent to them from a computer or mobile phone and the user is prompted for a PIN code on the computer or mobile itself - like for class 1 cardreaders - malware might steal users pin or send forged data to the smartcard or HSM. If malware steals the pin with class 1 devices it’s able to sign as many data as it wants to as long as the HSM is connected / the smartcard is inserted into the cardreader (so remove them when not required!). On class 2 cardreaders the pin is entered on the cardreader itself but the user lacks feedback about what he has signed with his action. It prevents malware to sign an arbitrary amount of messages - but doesn’t prevent it to send counterfeigt data to the smartcard - so the number of stolen signatures is limitied but the risk of signing other data than intended is imminent (as soon as the device has been compromised).

Class 3 smartcard readers offer a pin terminal as well as a display. They display the data that is going to be signed by the card and ask the user for the pin together with the shown data. This prevents malware from presenting the user different data than he’s going to sign.

Class 4 smartcard readers are not any more interesting for most applications - the main difference is that the smartcard readers authenticate themselves also against the backend that they send data to. These are used at point of sales terminals for example and should prevent shops from using counterfeigt terminals that collect pin numbers without being noticed.

The main reason signature based mechanisms are more secure than OTP tokens is that the only location ever that need to know the private key is the HSM or smartcard (keys may even be generated on these devices without the ability to read them externally which is the best way such systems can be used).

Examples for smartcard readers are (note - the links are Amazon affilate links, the author profits from any qualified purchases):

Main attack vectors:

Conslusion

Methods like TAN and iTAN are prone for phishing but at least not an arbitrary number of automated attacks, SMS based solutions are the weakest currently available solutions, App based solutions are as insecure as the mobile platform underneath. Avoid them at any cost.

External TAN generators (TOTP / HOTP tokens) offer acceptable security whereas ChipTAN/PhotoTAN/FlickerTAN provides good security against automated attacks - assuming they are not implemented on hardware that’s connected to a network and assuming that the seeds have been stored in a safe way at the entity that one’s authenticating against too (a really bad example of how this can fail has been the hack of RSA SecureID where hackers stole the Seeds for millions of hardware tokens that have been pre-programmed by the manufacturer (note that such tokens should always be programmed by the issuing party - nobody else should ever have access to the seeds and the seeds have to be truly random).

If done correctly (external key store on i.e. a smartcard or HSM, external verification of the signed data and external PIN entry or at least confirmation) signature based mechanisms offer the best available security.

This article is tagged: Internet, Security, Web, Tutorial, Computer


Dipl.-Ing. Thomas Spielauer, Wien (webcomplains389t48957@tspi.at)

This webpage is also available via TOR at http://jugujbrirx3irwyx.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support