Two Factor Authentication

Two factor authentication since 2006 has been widely implemented by all banks as it was imposed upon them by FFIEC. Since then, there are still qns regarding the two factor authentication strength. This was further supported by recent case like the ABN ambro whereby man in the middle attack was able to bypass the two factor authentication . So, my question is what will u suggest to improve the current situation of the two factor authentication?

Hi Darrius, I think the real issue is that most banks and other financial institutions are not yet using true two-factor authentication -- they're using two layers of single factor (i.e. password) authentication.

True two factor authentication requires a factor that is *not* stored on a server, e.g. a fingerprint, keycard, etc. used in conjunction with a stored password.

What most banks do is ask you to store both a password and either answer a few questions (mother's maiden name, birth city, etc.) or remember a sitekey (an icon like a treasure chest or a butterfly or something you choose).

This is really just storing two passwords in the same place -- even if they're stored on different servers, they're still vulnerable to data theft, whereas a fingerprint reader, card reader, etc. isn't.

The bottom line: the banks have been lazy and have taken the cheapest path to try to make their customers feel protected when in fact the additional protection added is pretty thin; it'll change when enough consumers complain (and are willing to pony up the extra charges the banks will ask to provide you with a fingerprint reader).
Actually, banks are using two-factor authentication, they just aren't widely using it for their customers. For privileged (from an IT perspective) users, two-factor authentication is pretty much ubiquitous at the banks I've been at. But I don't think there's a need to "improve the situation," since two-factor authentication is not meant to solve against real-time credential attacks. There are no magic bullets against all attacks, and there never will be. There are alternate means to defeat MITM attacks, such as reverse-channel presentation (the server sending some pre-defined information to the user; the best example of this is in use by Bank of America for their online banking) to allow the user to verify that they are speaking to who they think they are speaking to, and not some attacker who has inserted themselves into the connection.

The real issue is between time-driven and event-driven token authentication. Most of the two-factor identification that is being handed out is RSA tokens, which are time-driven. Most implementations allow replay attacks for the one-minute life of the token. An alternative is an event or time+event model. For example, the tokens we use generate a new set of 16 credentials every minute. If I were to connect using the third credential, the first through third would be immediately invalidated, and I would have to display a new credential - perhaps the 5th or 6th - in order to log in a second time,

Very few 2-factor solutions are designed to address MITM attacks, the purpose of 2-factor authentication is primarily to eliminate specific weaknesses of reusable passwords, not as a security panacea.

The primary goals of 2-factor authentication for consumer banking are to provide greater accountability (protect the bank from the customer fraudulently claiming "my account was hacked") and to eliminate the trivial store-and-forward type of trojan where a keystroke logger intercepts your reusable password, and the criminal uses that password hours or days later to connect to the banking site and execute a transaction.

2-Factor authentication is very different from "Know your password and the answer to a security question". True "two factor" authentication means presenting two out of three possible factors in order to authenticate, where the factors are:
1) Something you KNOW (a password, mother's maiden name, a PIN).
2) Something you HAVE (a SecurID hardware token, a smartcard, an ATM card)
3) Something you ARE (Iris Scan, fingerprint reader, hand geometry)


Please note that a RSA SecurID deployment does NOT "allow replay attacks for the one-minute life of the token". The tokencode can only be used once, and must be used within a few minutes of when it was generated (the window is slightly greater than 1 minute).

Links:
http://honor.trusecure.com/pipermail/firewall-wizards/2000-December/009739....
http://en.wikipedia.org/wiki/SecurID
Kevin Kadow also suggests these experts on this topic:
Jason Lamar
Vin Mclellan

In this specific case, the MITM attack was based on screen scratching. They sent an email with a virus, which abused the vulnerabilities of IE. Once you entered ABN AMROs website it redirected you to their site, which was a proxy mirror to the ABN AMRO website and they used the urgent payments features. And the certificate is useless as any good old crook can obtain it if they are determined enough. In this particular case use of a site key or other methods of abuse prevention would have no effect
as the smart hackers would have accounted for that. So even if you use strong 2FA it is not much prevention against really determined hackers. One possibility is to limit entry to a particular browser using cookies (but alas there are ways the smart hacker could thwart this) and to ask a challenge response if attempted through another browser or proxy and this should theoretically alert the user. So the moral of the story is always keep your guard up. And in this paricular case, the 2FA was not "cracked".
Cracking a 2FA, whether event or time based, and whether it has a challenge response is never really worth the effort of crooks from a cost benefit analyses. That is why it is called "strong authentication", never total authentication. Even a biometric layer as a form of 2FA would fail in this case as that would still be relayed over the proxy. We develop 2FA soft tokens and secure mobile banking and payments products so we always have to keep an eye out for potential threats. And unfortunately the weakest link is not technology but human mistakes. So avoid IE, use Firefox or Safari or Opera, use Linux or Mac if you can, don't accept emails from banks, or open zip files and .rar from people you do not know and avoid .vbs or .exe files. Without 2FA though, the incidence of fraud at ABN AMRO would be thousands more as keyloggers, phishing attacks and trojans are pieces of cakes even for illiterate hackers.
So 2FA does work in that regard. Fraud has always existed. Before online banking fraud there was ATM fraud, Check fraud, forgery fraud, branch teller fraud etc.... 2FA makes it costlier for crooks....

It's important to remember that you can't prevent MITM attacks without implementing a mechanism to strongly authenticate the server you're trying to talk to. If you don't strongly (i.e. cryptographically) authenticate the server, you might be getting MITMed.

Virtually all existing two-factor authentication schemes being deployed by banks and others are about authenticating the *client*, not the *server*. Strong mutual authentication is the only solution.

On another note, you should look at PhoneFactor - phone-based two-factor authentication; it's available free. See www.phonefactor.net. (disclaimer: I'm the CTO of the company that sells it.)

Links:
http://www.phonefactor.net
http://blog.phonefactor.net

Since the FFIEC two-factor authentication requirement went into effect, there has been an outpouring of misunderstanding and failure on the part of banks trying to save money on issuing tokens.

All of the research into technologies like mouse-click keyboards, PassMark, SiteKey, CAPTCHA and the rest of the the snake oil has shown that they are still vulnerable to phishing.

It's also worth mentioning that even token-based two-factor authentication is not impervious to attack. If the client is compromised, session hijacking and screen scraping still work. I don't think that this is a problem that authentication can solve.

For more info on vulnerabilities in PassMark and other interesting research into phishing, check out Chris Soghoian's blog.

Links:
http://paranoia.dubfire.net/2007/04/deceit-augmented-man-in-middle-attack.h...
http://paranoia.dubfire.net

Nope.

I use a lot of services used by banks, and have never come across them implementing two-factor authentication (that is here in the UK).

However I would consider the forms of authentication already employed as 'as good as' two-factor authentication.

I do not share the view that two-factor authentication is necessarily the best.

I think that very few banks have actually implemented true two-factor authentication, and are simply implementing multiple layers of first factor authentication - a case where 1 plus 1 does not equal 2. Alternatively, your point about the vulnerability of two-factor authentication solutions being vulnerable to MITM attacks is completely valid.

Consequently, I would still remove the biggest vulnerability to online banking and e-commerce through the implementation of true two-factor authentication. The fact that two-factor authentication is vulnerable to MITM should not stop banks from closing the MAJOR vulnerability they have to their existing solutions.

Additionally, there are innovative solutions to MITM attacks that leverage novel implementations of two-factor authentication that block a MITM from successfully gaining access to the system. In the spirit of full disclosure, I am the CTO of a company that has one such solution, Anakam.

Bottom line - banks would be a lot better off than they currently are by simply adopting true two-factor authentication for the end users. Additionally, there are solutions available now with those two-factor impementations that eliminate the vulnerability created by a MITM.

Links:
http://www.anakam.com

Many of the currently deployed security measures guard against a compromised communication channel between client and server (traffic encryption, SSL server certificate against MITM on that level), or against unauthorised clients (username/password authentication, strong authentication, whatever).

Even if you assume that all of these measures work as they are intended to, this still does not take into account the problem of a compromised client system (which is what essentially happened in the ABN Amro case) - which is not what security measures such as 2-factor *session* authentication are supposed to guard against.

To begin addressing a compromised client system, you would need to not just authenticate the client when he connects to the server, but you actually need to "strongly" authenticate individual transactions the client makes (even over an already authenticated session). A proper implementation does not prevent an attacker from observing client data, but it should prevent him from making unauthorised transactions (e.g. money transfer).

Doing this the right way would involve a challenge-response scheme where the client can visually verify the relation between the challenge which is presented, and the actual transaction he wants to make.

E.g. for a money transfer, suppose that the client has a hardware token which generates one-time codes based upon the current time and upon an entered challenge code. The client would enter the desired transaction: destination account number and amount to transfer. The banking server would then require this transaction to be validated by a one-time code. The challenge presented by the server for the generation of this code could be the destination account number, followed by the amount. This can be visually verified by the client as corresponding to the transaction he wants to make (preventing an attacker from modifying a transaction on-the-fly). You could append a strong random number as third challenge component, as added replay protection (next to the time-dependency of the generated one-time code).

A banking server would need to enforce this transaction authentication for any money transfer (irrespective of the amount) to prevent attackers from making small, "hidden" transactions.

Cumbersome and user-unfriendly? Probably, yes. I guess this is another example of a typical trade-off between user-friendliness and assurance ...

I believe your example of the man in the middle attack shows the need to move beyond just looking at authentication as your security solution.

Two factor only applies between the human and the machine used to input the two factors. So to truly have two factor authentication you need to trust the machine receiving the two factor inputs. The design flaw in most online banking is trusting the customer's machine. This design flaw is partially at fault for being exposed to phishing, man in the middle, etc.

What needs to happen in the online banking space is a true risk assessment and design review (BTW most security teams that I know at banks have already done or are doing this) and architect the application to minimize all the threat vectors.

Things to look at are:

Out of band communication methods for: second factor authentication, sensitive data delivery, account modification, etc.

Data minimization: Minimize the amount of data exposed during a transaction. If both you and your customer knows the data element then either don't provide it or mask it. Data not exposed isn't available to compromise.

Behavioral analysis: Monitor authenticated sessions and be ready to challenge the customer for a second factor authentication if some new behavior happens. New location, new browser, new action, etc.

Review application design to minimize required trust in non company owned equipment. Have each tier of the application responsible for a single element of the application: View, controller, model, etc.

Design in excellent auditing and logging. Aim for full forensic level capability.

Banks who have implemented 2FA are stronger protected than the ones that haven't, as they will be less likely to be targeted. There are no cases, to my knowledge, that 2FA based on one time password generators are broken. 2FA can be bypassed by MITM or MITF (man in the front). Lessons that should be learnt here is that 2FA is not sufficient by itself, but should be complemented by other measures. Such would include strong client protection (if needed with terminal services), strong user awareness, security monitoring. Note that if the client workstation is well-controlled, the risks related to 2FA are still small.

Two factor authentication can be strengthened by introduction a third element such as an identity, i.e. "who you are".

The big three factors in use are:

1. "Something you know", a password, PIN or an out of wallet response.
2. '"Something you have", a mobile phone, credit card or hardware security token.
3. "'Something you are", a fingerprint, a retinal scan, or other biometric.

Great examples of strong two factor authentication measures are the use of timed security token devices that not only require the user to input their userid and password (often 8 alphanumeric or more in length in addition to symbols making password guessing difficult with periodic forced changes) but require a token that generates a random number that needs to be inputed to gain access. the random number changes every few seconds.

If you have not noticed, Ebay's Paypal has employed RSA tokens and other banks are following this method. Biometrics "who you are" are also being used where credit card, debit card transactions are executed by fingerprint readers in addition to pins. I noticed a few banks utilizing and experimenting with this. A few retail stores in particular Albertson's and others use biometric method as well government agencies.

More and more the use of strong password policies, usage of tokens with timed random changing numeric and alpha-numeric displays along with biometircs will be common place with banks.

I thought there would be nothing left to add after so many responses, but reading through the many good comments I feel there is one remaining key issue: usability.

While there are some very strong authentication solutions (e.g. smart cards with digital certificates) that are quite resistant to man in the middle attacks, these solutions frequently pose usability challenges. For example, a smart card system requires deployment of card readers and installation of smart card drivers on each client system. And they're not easily used at a kiosk or internet cafe.

So banks are always faced with a tradeoff between usability and security. A lot depends on what is culturally acceptable. In the USA most end-users don't want any kind of physical authentication device (e.g. card, token, etc.) for online banking. In Europe there is a stronger desire for visible, tangible security.

As a result, most of the big banks use a "layered" approach where a combination of techniques are deployed. They'll use the strongest authentication that is acceptable, usable and affordable up front. (Maybe a username & password plus device fingerprinting plus challenge questions). They will very commonly use back end transaction monitoring software to look for patterns of unusual activity, and as a result will block certain transactions or require step-up authentication to a stronger method. (Based on IP Geolocation for example, if you're logging in from a new location you may be asked more questions or sent an out of band one time password to your mobile phone, etc.).

The threats keep evolving, and the state of the art authenticators keep evolving, so banks are looking for platforms that will let them mix and match and keep on experimenting/evolving also.

(Entrust makes authentication & transaction monitoring solutions but so do a number of other fine folks. The comments above are generic.)

Links:
http://www.entrust.com/consumer-authentication/