Hacking Two-Factor Authentication

Back in 2005, I wrote about the failure of two-factor authentication to mitigate banking fraud:

Here are two new active attacks we’re starting to see:

  • Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
  • Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

Here’s an example:

The theft happened despite Ferma’s use of a one-time password, a six-digit code issued by a small electronic device every 30 or 60 seconds. Online thieves have adapted to this additional security by creating special programs—real-time Trojan horses—that can issue transactions to a bank while the account holder is online, turning the one-time password into a weak link in the financial security chain. “I think it’s a broken model,” Ferrari says.

Of course it’s a broken model. We have to stop trying to authenticate the person; instead, we need to authenticate the transaction:

One way to think about this is that two-factor authentication solves security problems involving authentication. The current wave of attacks against financial systems are not exploiting vulnerabilities in the authentication system, so two-factor authentication doesn’t help.

Security is always an arms race, and you could argue that this situation is simply the cost of treading water. The problem with this reasoning is it ignores countermeasures that permanently reduce fraud. By concentrating on authenticating the individual rather than authenticating the transaction, banks are forced to defend against criminal tactics rather than the crime itself.

Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card’s existence isn’t even verified. The credit card companies spend their security dollar authenticating the transaction, not the cardholder.

More on mitigating identity theft.

Tags: , , , , , ,

Posted on September 22, 2009 at 6:39 AM • 98 Comments

Comments

A Nonny Bunny • September 22, 2009 7:20 AM

Surely two-factor identification does prevent a whole host of other exploits. I wouldn’t throw it out simply because it doesn’t solve every problem. I doubt anything will ever solve every problem.

I suppose perhaps a bank could send a text-message with the transaction details as well as a confirmation code. That way you know what transaction you’re committing to, and you can see whether a man in the middle has added anything.

Ricky Bobby • September 22, 2009 7:21 AM

Why do you think authenticating the transaction will fix everything?

Don’t you think someone will learn how to circumvent this transaction authentication as well?

Nothing is perfect.

igor • September 22, 2009 7:26 AM

My bank already authenticates transactions. Every time I try to make a transfer or other sensitive operation, I get a text message “transfer: amount [sth.] from account [first and last digits] to account [first and last digits] at [time and date]. Your one-time password is [8 digits]”.

I wonder if there are any problems with that system? In my opinion, there aren’t any with the general idea. They might be in the implementation details, although I’ve never found any.

MathFox • September 22, 2009 7:29 AM

I know one bank that gives a device where you enter amount and account number of the other party in the transaction and the device gives you a checksum to confirm the online transaction.
It is not perfect (the device can be stolen), but it prevents man in the middle network attacks because the mitm has no checksum for his fraudulent transaction and changing the information of a valid transaction will cause a checksum failure. (Read up on MACs in a cryptography text.)

Franz Alt • September 22, 2009 8:10 AM

The only two ideas I have to make this better is
a) use a non-conprimisable system, for example Linux-Boot-CD for homebanking
&
b) use a client-certificate for a secure connection.
I don’t know, if b) works with a browser and https, but HBCI should be ok, shouldn’t it?

Savik • September 22, 2009 8:33 AM

I would think two factor out of band authentication would be the answer to this issue. For instance, you initiate authentication to your online banking site using user-name and password – then you get a phone call and have to enter a PIN to complete the authentication.

After you are in you could also set it up to authenticate through out of band authentication any wire transfers or high dollar transactions…that threshold can be configurable so as not to bother you with nominal transaction amounts.

One could also choose to receive a TXT message every time a transaction occurred- so it could be verified.

Nick Owen • September 22, 2009 8:44 AM

Focusing on what process is being authenticated is more helpful than the number of factors involved.

I like to break it down further into session, host/mutual and transaction authentication. Here’s an article I wrote on this topic some time ago: http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1180513,00.html.

Doing strong transaction authentication is better than session authentication, if you are only doing one! But one will not be enough. All three will need to be addressed in a real way, based on cryptographic principles.

FOK • September 22, 2009 8:48 AM

Two factor can remedy lot of attacks being performed nowadays. But only when it is done right. Simply sending authentication code via SMS doesn’t solve it much. When there is MITM, then you are talking to fake site and provides security codes that can be used by malicious party. Better is sending authentication messages with transaction identification as igor wrote. This is exactly what my bank is doing. You just check if the account numbers fit and if so, then you enters code to the form. But this is still susceptible to MITM. Just keep in mind that SMS is sent via network similar to internet. Authentication protocol on SMSC is kind of fun if not omitted at all. Just because you don’t know how to forge SMS doesn’t mean nobody can do it.
One of the banks I know was much better in protecting transactions. They use two factor authentication with strong countermeasure against forgery. You either receive encrypted message on your mobile, that is processed by banking application, loaded into your phone SIM by your bank, after entering BPIN. Or you can have special calculator where you enter your transaction details and device generates security code for the transaction based on entered data. And of course such calculator is protected by PIN.
Some banks are offering smart card authorization tokens. But There is hidden risk too. I never heard about this attack. But consider MITM between keyboard and crypto device. If you can intercept communication between computer and device, then you can generate as much transactions as you wish just replaying PIN for crypto device. Of course as long as it is inserted in USB port.

brazzy • September 22, 2009 8:49 AM

@Savik – out-of-band two-factor auth doesn’t prevent man-in-the-middle attacks any better than simple auth unless, as Bruce writes, you authenticate the transaction by including data about it with the out-of-band communication so that the user can check which transaction he’s approving.

Pixel • September 22, 2009 8:55 AM

My bank gave me a small device which reads my bank card, validates my PIN, then generates a unique 8-digit code. And that’s just to get in.

If I want to transfer money to an account I haven’t transferred to previously, I have to use the same device, again with bank card and PIN, plus the target account number and transfer value. without this, the most I can do is move money around my own accounts, or to people I have already approved.

Tobias • September 22, 2009 8:57 AM

A lot of banks in sweden got just the solution to authenticate the transaction.

You enter the code of the target account in your offline pad, got a confirmation code you enter on the website.

After that you enter the amount of money you transfer in your pad and enters the confirmation code on the website.

In that case you both enter the amount of money and the confirmation code. Then the bank checks against their algorithm to see it match.

Ofcoz you could do a MITM attack on that in some cases, but it’s not as easy as just one time pads.

Paeniteo • September 22, 2009 9:00 AM

@Franz Alt:

a) use a non-conprimisable system,
for example Linux-Boot-CD for
homebanking

There simply is no such thing as a non-compromisable system.
Practically speaking, a Linux-Boot-CD might come close to that ideal. If you know german, google for “Bankix”.

b) use a client-certificate for a
secure connection.

Pointless against trojans.

@FOK:

But this is still susceptible to MITM.
Just keep in mind that SMS is sent
via network similar to internet.

True, but the odds that an attacker is able to conduct simultaneous MITM-attacks against both your internet- and cellphone-connections appear quite low.
Also, the procedure definitely increases complexity (=costs) for the attacker.

cu, Paeniteo

Franz Alt • September 22, 2009 9:01 AM

Another idea:
After sending a bank transfer via internet, I could get an automatic “recall” to my cellphone, which reads again my ordner and I have to accept.

I think it’s quite good, but way more expensive then other solutions, but better then sending TANs to a mobile phone, which doesn’t prevents all mitm-attacks.

coffee • September 22, 2009 9:02 AM

I think saying 2factor doesn’t solve anything is an obtuse statement. But, I think what was being said is it doesn’t solve fraud… which is equally short sighted.

The point being missed is layers of defense. 2factor can greatly reduce issues when combined with other controls, even simple controls that create a more sound environment.

Anyone relying only on one security control to solve everything will fail – regardless of the control in question. Security is a system… not a box. Moreover, applying every control in the world will not address everything… there is a balance between threat and control, cost and loss.

Attacking the validity of any one control without considering the entire environment is extraordinarily short sighted. Can 2factor be hacked? Yes. Will the hack be successful when combined with other supporting controls? Less likely.

Implying that 2factor is worthless and all your energy should be directed at authenticating the transaction (which Bruce failed to elaborate upon what exactly he means by this) is counterproductive. This is analogous to building a wall, having it fail against a specific attack, so you tear down the wall and build a moat assuming that the moat will thwart all future attacks – which is wrong, and clearly a wall and a moat would be a better solution.

I guess when authenticating the transaction fails to solve the problem, we’ll be rewarded with a similar posting on how we need to ditch that and move to something else. I think even squid know that one defense isn’t perfect, but can be made better when combined with multiple, intertwined defense tactics.

It seems to me that defense in depth got lost in his anti-2factor post.

Carlo Graziani • September 22, 2009 9:06 AM

The trouble is, these systems have been designed to authenticate customers to banks. They don’t appear to do anything in aid of the converse problem — authenticating banks to customers.

I suppose it’s the externality thing again. Banks have a greater incentive to protect themselves than to protect their customers. Probably if the banks were made 100% liable for losses due to internet-banking fraud, they’d come up with a more symmetric authentication scheme in a hurry.

BobaFett • September 22, 2009 9:13 AM

Egg credit card in the UK has occasional transaction authentication via an automated system that phones the customer when their spending patterns deviate from the norm (usually occurs with new internet based counterparts). Admittedly their incentive is greater, as being a provider of credit they are liable for any fraudulent use and not the customer (in my experience at least).

Roboticus • September 22, 2009 9:23 AM

For everyone saying something along the lines of send a text message to customers telling them “Transfer $XXX From XXXX-XXXX to XXXX-XXXXX”, I have worked with the public for 8 years now. I can tell you as hard as it may be to believe, most people wouldn’t pay the slightest bit of attention to the amount or destination account number. I can count on the fingers of one hand the number of customers I’ve seen look at the total on the customer display and make sure it matches the credit card slip they are signing.

Matt from CT • September 22, 2009 9:35 AM

Didn’t feel like my normal granola bar this morning for breakfast.

Stopped at McD’s to get my weekly grease quotient.

Their computers were down.

Took two employees four attempts at using a calculator to tally up my order.

Then they couldn’t figure out the change for a $7.03 meal from a $20 bill.

They had to ask the manager for help.

And we think devices to calculate transaction hashes are going to help us?

NoSuchThingAsIdentityTheft • September 22, 2009 9:44 AM

Trojan attack: Game over. If the bad guy has installed software on your computer, it is no longer your computer. There is nothing you can do to protect your information or transactions. Period.

MITM attack: A few years ago, real-time MITM attacks against the web browser were considered not practical, but now they are. If your web browser session can fall to a real-time MITM attack, why do you think any OOB transaction verification won’t also?

The fundamental underlying problem in any MITM attack is that the customer is not verifying the identity of the bank.

If the customer is not verifying that they are connected to and interacting with the real bank from their web browser, it is highly unlikely they will verify that the SMS message (or whatever OOB transaction verification method) actually came from the real bank.

BF Skinner • September 22, 2009 9:49 AM

Doesn’t an authenticated transaction rely on an authorized user?

Does authenticating the transaction just add an additional link. A link that can be manipulated by getting between the user and their authority to authenticate the transaction?

Michael Argast • September 22, 2009 9:56 AM

The tone of this does seem off to me – ditch two-factor because it is possible to bypass it?

While we’re at it, ditch password screens because they make it harder?

I understand your railing against passwords and authenticating the user, but authenticating the transaction has its own issues. It is really not that different than a sort of challenge-response scheme, which can be bypassed via things like MITM, or worse, make for a usability nightmare whenever anybody does anything unusual (which for many people, is all the time).

Modern security usually involves layers – the point isn’t to make it unbreakable (there is no such thing) but to make it sufficiently difficult the attackers go elsewhere or to reduce/mitigate the risk and costs.

Sure, Trojans and MITM attacks can break two-factor, but there are a lot more attacks that can break one-factor or no-factor.

Michael Argast, Security Analyst, Sophos

FOK • September 22, 2009 9:58 AM

True, but the odds that an attacker is able to conduct simultaneous MITM-attacks against both > your internet- and cellphone-connections appear quite low.
Also, the procedure definitely increases complexity (=costs) for the attacker.

Yes in computer security it is always about increasing complexity. But forging SMS is not so hard.
If you know bit about your victim and his/her bank, then it is quite easy to plot an attack if you have access to the infrastructure. in my previous career I was allowed to send SMS from my computer that appeared on receivers side as it was sent from my handy. All this via SMS gateway connecte not only to different provider but also in different country.
Now consider fact that GSM protocol allows canceling already sent SMS message. So you asks banking application to send SMSes to your phone and eventually cancels warning message that is sent to users mobile. And from now on you are the master of the account.

John Verry • September 22, 2009 10:04 AM

Glad to see that the common reaction to this blog was the same as mine — underwhelmed.

I also find holding anything the credit card companies does as being “good practice” (The credit card companies spend their security dollar authenticating the transaction, not the cardholder.) as being comical.

FOK • September 22, 2009 10:08 AM

Notice how little attention is paid to cardholder authentication.

There are also examples how cards can be more protected.
Currently card companies are issuing chip cards that are better at maintaining security than magnetic strip only cards. But before this there was one bank in our country, that was swallowed by another bank that offered card locking. You had to send encrypted SMS to the bank to unlock your card and after doing transaction you locked card by same procedure. So exposure to card misuse is quite limited.

BF Skinner • September 22, 2009 10:09 AM

@Michael Argast “ditch two-factor because it is possible to bypass it”

That’s not entirely what Bruce appears to be advocating.

This is based on an earlier argument of his (that link at top goes to a (2005) cryptogram) that 2factor works in some configurations but won’t work to deter and eliminate bank fraud.

He proposed the model of the credit card where user identites are barely addressed (when was the last time any of us were asked for a driver’s license? While writing a check right?)

But I’m having a hard time seeing how authenticating the transaction would work. CC companies assume transactions are legit until the cardholder tells ’em it’s been stolen

(…yes…they do watch transactions, once someone in Romania was using my card number to order stuff and the CC company called to ask me about it. And once they questioned the size of my tuition payment but I never called them back and they didn’t refuse to honor the payment.)

But how would a bank work that?

Paeniteo • September 22, 2009 10:35 AM

@FOK:

True, but the odds that an attacker is able to conduct simultaneous MITM-attacks against both
your internet- and cellphone-connections appear quite low.
Also, the procedure definitely increases complexity (=costs) for the attacker.

Yes in computer security it is always about increasing complexity.
But forging SMS is not so hard.

The hard part IMHO would not be forging the SMS (kinda trivial) but intercepting the “real” SMS in the first place.
I don’t think that would be possible for the common “broadband” phishing attacks but rather only for targetted attacks against single victims (which is an entirely different game).

Mark Tinberg • September 22, 2009 10:40 AM

I reiterate, this kind of financial vulnerability could be mitigated by having a token with a keypad and having the token hash the transaction values (amount, dest account) along with the auth info. That would prevent reuse of transaction data, as long as the backend only honored a token response one time.

Bill • September 22, 2009 10:55 AM

@bruce

“The credit card companies spend their security dollar authenticating the transaction, not the cardholder.”

No, that’s not true. The VBV /secure code programs are designed to authenticate the cardholder.

FOK • September 22, 2009 11:05 AM

@Paeniteo:

The hard part IMHO would not be forging the SMS (kinda trivial) but intercepting the “real” SMS in the first place.

Unfortunately there are banks that allow you to log in via password and SMS is used only for transaction verification. And your phone number can be easily changed after you log in. They send notification SMS when someone is trying to change target number but here comes cancellation message to suppress such warning as I worte.

I don’t think that would be possible for the common “broadband” phishing attacks but rather only for targetted attacks against single victims (which is an entirely different game).

I didn’t say that it is easy. But even with two factor authentication your bank account can be robbed. And all this is in the time when other banks are using technology, that can easily prevent this. Just use SIM toolkit application that receives and send data to your bank encrypted and immediately you are on another level.
The real problem with MITM is that most people didn’t verify what is base for security code. So attacker can easily change account number and amount of money transferred and user will confirm it with real authentication code. And this of course will not be solved by authentication message. The only solution is to use independent authentication device where you have to type all transaction details and then you receive security code for transaction as I wrote earlier. It can be even application for your phone or PDA, until phone trojans become common.

RH • September 22, 2009 11:11 AM

“Two Factor Authentication Doesn’t Solve anything”… doesn’t seem fair to use Trojans. There is ALWAYS an implicit assumption that at least ONE piece of hardware is trustworthy and in the possession of the user. Specifically, whatever portion of the process is used to authenticate MUST itself be reliable. Thats like saying “SSL doesn’t help you because your computer knows the session key and it can be compromized.” If you can’t trust your own machine, then its time to stop ordering online and start going to the teller windows at the Bank for your deposits.

The only systems I’ve seen which come even close to avoiding this problem are those where the final authentication is done by the user’s own eyeballs (such as comparing a text message’s specified account number to the one you think you’re sending money to. But even that fails with modern day smart phones – how long will it be before a virus get out which gives no signs of its existence, until you try to bank with a compromised computer, then it shortcuts the text messages?

Any, like many others, my bank uses 2 factor to log in, but then for a set of “high risk” operations, such as large transactions, it asks for annother one-time use key.

We want our hardware generalized… the price we pay is not knowing what is actually getting executed.

NoSuchThingAsIdentityTheft • September 22, 2009 11:15 AM

“Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card’s existence isn’t even verified. The credit card companies spend their security dollar authenticating the transaction, not the cardholder.”

I don’t necessarily disagree, but I think that in the banking environment, comparing credit cards to bank accounts is sort of an “apples to oranges” comparison.

The reason credit cards work today is because the cardholder is not liable for fraudulent transactions! Simple as that.

Cardholders don’t check receipt totals because they know they can call the credit card company and easily dispute transactions after the fact. Since this is “credit” the cardholder has not lost any money at this point. In most cases (i.e. card signature verify, card not present, etc.), the responsibility falls onto the credit card merchant or the bank to investigate any fraud. In the worst case, the cardholder would only be liable for $50 (if that).

However, this is typically not the case with fraud related to bank accounts or debit cards (connected to bank accounts). In this case, the bank customer is liable, although I understand that some banks are better at “resetting” fraudulent transactions related to bank accounts and debit cards.

RH • September 22, 2009 11:16 AM

Also, the more hoops we make the criminals jump through, the more likely they will leave behind some breadcrumbs that make you think “hmm, thats kind of funny…” such as SSL certificates not matching up.

In the end, the challenge is reducing bandwidth usage to those of only the secure I/O between the secure device and the user’s mind. If every text message has an account number 16 digits long, how long will it be before someone simply glazes over them?

Ricky Bobby • September 22, 2009 11:19 AM

This is a silly argument. In every technology a security flaw will be found, it just depends on on the amount of money needed to find/exploit it and the time involved to exploit the vulnerability. Security 101

Will two factor authentication fix every authentication issue?

No, but nothing will.

Richard Schwartz • September 22, 2009 11:21 AM

Validating transactions via SMS raises the question of how you secure a transaction that changes the mobile number to be used for the SMS. While ordinarily sending a confirmation text to the number you are switching from seems like a good idea, if you’ve been individually targeted it’s probably not going to be that difficult for the bad guy to simply steal your phone and drain your bank account before you even have time to get your provider to disable it. Furthermore, in the ever-present battle between security and convenience there are some really thorny issues here. E.g., if you are out of the country and your phone doesn’t work on the local system, you can’t get the confirming SMS. (And if the alternative is to make a personal appearance at your bank branch to that’s not going to happen either.) So unless you’ve planned ahead and reserved a mobile number in the country you are visiting, you can’t take care of the switch in advance. Although it’s a mistake nobody is likely to make twice, ending up abroad with no access to one’s credit card is not a situation you want your security measures to put your customer in even once.

FOK • September 22, 2009 11:38 AM

@RH:
Authentication being done by users eyeballs is only false sense of security. Message sent to you can be forged so you will notice nothing. The only secure way to protect your transaction is security calculator. It is something like SecurID tokens but also takes into account transaction data you type on the keypad that must match what you type into bank’s web form. Then it works like digitally signed message. And because this device is not connected in any way to the computer, then it seem pretty secure to me. And of course the device itself is protected by the PIN :-).
If you are interested, there is an image (very poor resolution) of such device on following page.
http://www.e-komerce.cz/ec/ec.nsf/0/46984CBBA0728F33C1256C3A00499CD7

Clive Robinson • September 22, 2009 11:40 AM

Ho hum, ho hum,

I’ve posted about this on Bruce’s blog a number of times in the past.

1, It is the transaction that needs to be authenticated.

2, But importantly the bank and the user need to authenticate each other as well.

3, The authentication needs to be “tamper proof”.

It is this last bit where people get it wrong and where attacks are going to happen.

To be “tamper proof” a lot of conditions have to be met,

A, It needs to be cryptographicaly secure
B, It needs to be a secure side channel.
C, It needs to be immutable.

Humans tend to be incapable of meeting A, a mobile phone will never meet C and B idealy should be through the user.

The solution is to use a token with a keypad. whereby transaction details are entered in along with a secret (something you know) and a two part crypto checksum is created which the user then types part A of into the PC.

This gets sent to the bank which checks the transaction and sends back a confirmation check code which the user then types into the token. Part of the check code should be the same as part B of the checksum in the token if they match the token then performs an action on the rest of the check code and displays it to the user as the secure confirmation code that they then type into the PC.

The problem with all of this is reducing the amount of information the user has to type in to ease use.

Originaly I suggested using capatchers or their equivalent as this is a process designed to be human but not computer readable.

Since then the “phishers etc” have solved this problem they just forward the capatcher to somebody in the far east who gets paid some small sum (50cents or less) for typing in the correct answer….

Gert • September 22, 2009 11:49 AM

Around here (South-Africa) many banks use a single use code send via SMS for certain transactions. Successful attacks have been done using phone company employees…

In addition, initial login asks for 4 random characters from a password, which usually mean that the user needs to be fool into entering his complete password on a site for an login to be practical…

Bryan Feir • September 22, 2009 12:06 PM

As Clive mentioned, really, the ultimate solution is really a token with a keypad. The cryptography on the token can be used to perform the authentication of the bank AND THE ATM to the customer as well, which is the side of this that is currently not done much.

I remember seeing descriptions and photographs of prototype systems like this back when I was in grad school… and that was in 1992. This was a Visa card with a standard contact pad, a one-line LCD display, and a keypad. The card had its own built-in encryption key, as well.

So, why isn’t this sort of thing used?
– The cards/tokens are significantly more expensive to produce.
– The cards/tokens are significantly more fragile, and need to be replaced more often.
– Customer education is a pain, because people tend to be lazy.
– There’s no actual requirement for it, and the banks tend to be lazy, too.
Most of it boils down to externalities again; a truly secure system would cost the banks more than cleaning up the mess from less secure systems. Also, a truly secure system would cause more problems with customers being blocked from their own money.

uberdilligaff • September 22, 2009 12:07 PM

@Tinberg – I think you have it correct. Authenticating the transaction by hashing the desired amount and account and out-of-band transaction code info means that your desired transaction will succeed, even if passed through a MITM. However, the MITM attempt to alter the transaction to his benefit will fail. The MITM could cause my transaction to also fail by not forwarding it along to the real bank, but I can live with that outcome.

I disagree with Bruce’s assertion that 2-factor solves nothing. Such procedures reduce the ability to attack my transaction from “anybody anywhere on the Internet who has stolen/bought my account and password, at any time of day or night, without any participation on my part” to “someone who can redirect my connection to his site and hope I don’t notice the certificate error, only at times when I initiate the connection, and only by causing my transaction to fail”. I like those odds much better.

FOK • September 22, 2009 12:15 PM

After writing my last post I started to wonder since when is such authentication calculator offered. I found that the bank that was offering it started its operation in 1997. So it is more than 10 years without any significant improvement in other banks. Unfortunately such bank doesn’t exist anymore.
it looks like banks doesn’t care about their customers money. Or how can one explain such lack of security for online transactions.

@Brian:

  • There’s no actual requirement for it, and the banks tend to be lazy, too.
    You are completely right. There are several regulatory requirements on the IT security but nothing in case of transaction authorization.

Steven Murdoch • September 22, 2009 12:36 PM

The extent to which people, even within the security community, believe that 2FA will solve their problems has always surprised me. Not only is 2FA weak in theory, but criminals are already carrying out attacks in industrial levels, with the “Man-in-the-Browser” variant being the most problematic.

I’ve described this attack in my blog post “2FA is dead”:
http://blog.cronto.com/index.php?c=1&more=1&pb=1&tb=1&title=2fa_is_dead

I wholeheartedly agree with Bruce’s conclusion that transaction authentication is the way to go. My post also discusses how the Cronto visual transaction signing system can defeat such attacks. For further details, see:
http://www.cronto.com/visual_cryptogram.htm

casey • September 22, 2009 1:35 PM

One bank I use has an image that is chosen by me when I created the online account. If that image is not on the login page, I know that something is wrong. I am still suceptible to the second attack.

The real question is who is getting ripped off- me or the bank? Who’s job is it to protect the money? I could be wrong, but I thought I hired the bank to do this specific task.

NoSuchThingAsIdentityTheft • September 22, 2009 2:37 PM

“Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card’s existence isn’t even verified. The credit card companies spend their security dollar authenticating the transaction, not the cardholder.”

When comparing credit card and bank account transaction authentication, you have to think about what is being authenticated and to who’s benefit.

Credit card transaction authentication is really for the benefit of the Merchant. When the Merchant authenticates a transaction, they are doing it to ensure they will get paid (i.e. the credit card account is valid and there is enough credit on the account to pay for the transaction). Nothing in the online transaction authentication (i.e. verifone) actually verifies that the real cardholder is authorizing the transaction.

On the other hand, bank account transaction authentication is for the benefit of the account holder. When the account holder authenticates a transaction they are doing so to identify themselves as the real account holder and to authorize the transfer the requested funds.

So, Credit card transaction authentication is more about ensuring the funds exist than it is about ensuring the real cardholder authorizes the transaction. Whereas, bank account transaction authentication is more about ensuring the real account holder is authorizing the transaction than it is about ensuring the funds exist in the account.

Maneesh • September 22, 2009 2:56 PM

I don’t see ‘Man in the Middle’ and ‘Trojans’ as failures of 2 factor Authentication. These are different problems that need to be dealt separately.

Jeffrey • September 22, 2009 3:25 PM 

 I use the IronKey's Secure Sessions service to secure my personal transactions.  Using their DNS service (which is ran through their Secure Sessions SSL connection) they attempt to authenticate and verify the authenticity of the connection (checking for malicious activities) before allowing your secure connection to be made to the final destination website.

https://www.ironkey.com/personal-solutions

Wouter Verhelst • September 22, 2009 5:12 PM

@ricky bobby: “authenticating the transaction” means having the user review the transaction, and sign that actual data to the bank.

For instance, on my bank, when I want to transfer money to an account that is not either the bank account of a large company, or already in my list of bank account numbers that I often transfer money to, then I have to enter the bank account number and the amount of money that I want to transfer into my digipass, which then generates a cryptographic signature.

Of course the security of the whole thing hinges on the security of the digipass (the algorithms of which are not public), but the principle seems sound.

Lionell Pack • September 22, 2009 5:29 PM

I tend to agree with Bruce: two-factor authentication over one channel is now easily reducible by fraudsters to the equivalent of one-factor.

I prefer the term “Two Channel Encryption”, but even then there’s exactly the caveat Bruce mentioned: if you use both channels to authenticate the PERSON, you haven’t added anything.

In the web-banking/SMS model, the website password authenticates the person. The transaction DETAILS are then sent over a different channel, along with a one-time password. This puts the onus on the user to authenticate the transaction, but still achieves the goal: to authenticate both the person AND the transaction.

The difficulty of simultaneously compromising a person’s web access AND their SMS receiver is orders of magnitude greater than the difficulty of compromising one.

Clive Robinson • September 22, 2009 5:50 PM

@ Gert,

“which usually mean that the user needs to be fool into entering his complete password on a site for an login to be practical…”

Unfortunatly not…

As you note,

“Successful attacks have been done using phone company employees…”

Which means that all previous SMS’s etc are available via the employees as well.

If the bank uses a predictable way of making the choice for the “4 random characters from a password” then potentialy the password can be ‘reconstructed’ from the previous messages etc.

Cryptographicaly reconstructing a password is one of the oldest techneiques around and is a known problem to the attackers.

However I suspect that it is an unknown art to the average bank code cutter.

Clive Robinson • September 22, 2009 6:40 PM

@ Steven Murdoch,

“the Cronto visual transaction signing system can defeat such attacks.”

Did you fix that side channel issue I highlighted 16 months ago?

http://www.lightbluetouchpaper.org/2008/04/09/new-banking-code-shifts-more-liability-to-customers/

@ All

Bruce has bloged on this back in 2007,

http://www.schneier.com/blog/archives/2007/05/interesting_spo.html#c176007

And you will see I made a prediction…

Yes folks my balls are crystal not brass so please treat acordingly 8)

Jonathan Newnham • September 22, 2009 7:27 PM

My bank (in Australia) gets around this in what I think is an obvious way:

I attempt to make a transaction online. The bank sends an SMS with a confirmation code. I enter the confirmation code online.

No trojan will help an attacker, they have to have access to the SMS somehow (still possible but much harder).

dbCooper • September 22, 2009 10:18 PM

I will never be susceptible to any of these MTM, phish, trojan, authentication, authorization problems. Why? I pay cash or with a cashiers check, for everything.

The tellers at my bank know my name and the names of my dogs. On-line banking and plastic cards for debits/credits, what is the benefit? I have never ascertained any.

If one wants to learn a secure way to move money using electrons or photons, explore the methods used in bank to bank transactions.

Daniel Miessler • September 23, 2009 12:33 AM

Let’s agree that having your two-factor authentication stolen in real-time by an advanced attack is bad. Yes. Granted. Fair enough.

But can’t we also agree that having a standard username and password stolen and then sold or used MULTIPLE TIMES is far worse?

I think you’re guilty here of letting the best be the enemy of the good.

Prasanna S Bidare • September 23, 2009 3:44 AM

Firstly, It proved beyond that signal factor is not sufficient.

While, doing 2FA one needs to pay attention to do Two way authentication also. Of course with a dynamic process.

On line non repudiation taking all transaction factors into consideration into mind.

With the use of Mobile connectivity and Mobile handsets as a second true factor, the transaction trace is better.

Balanced secured Eco, training to users and use of mobile infrastructure could be a solution to look for.

hwKeitel • September 23, 2009 6:52 AM

@igor: my bank calls it mTAN (mobile)

it’s important, that the TAN changes if the transaction details change. like the account#. but i think i read something about attacking this type of TANs.
also, eavesdropping your transactions by reading your messages is possible.

Ricky Bobby • September 23, 2009 6:55 AM

Here is the issue with this argument.

We can say everything is broken and useless, since nothing is ever 100% secure. We just do the best we can, just because a MITM or Trojan can beat a technology does not mean its useless.

The If game is always present. Two factor authentication can be beat if a MITM exists. Locks can be beat if picked. The bank sends an SMS, if someone has stolen your phone this gets beat.We have security guards at my doors at work, if ninjas attack they will win.

So, should we not do anything, because an IF always exists? No

Just understand the risk.

I believe the risk is low that someone will MITM or Trojan real time any 2 factor authentication, so I see no issues.

NoSuchThingAsIdentityTheft • September 23, 2009 9:05 AM

@Yogi
“Is there a known solution for MITM?”

YES! It is called SSL. The SSL protocol was designed to prevent MITM attacks through the use of server side authentication.

Unfortunately, the problem we have today is that the greedy CAs (and name service companies) detroyed any meaning of trust in the SSL server certificates used to establish SSL server authentication.

When SSL was first introduced, the CAs all issued highly vetted SSL server certs. Getting an SSL server certificate actually meant something (aka trust), it took a reasonable period of time (about a week or so) for the CA to perform a proper background check on the company requesting the SSL server cert (the CA required evidence like DUNS numbers and letters from company officers, and actually investigated these before issuing an SSL server cert).

Today, to get an SSL server cert, the CAs don’t do any checking at all (aka no trust), all one needs is a bogus email address and a bogus domain name (which the name service companies are happy to hand out, even with a stolen credit card, no checks or waiting periods, and no checks that the domain name requested is just a simple misspelling of a national brand), they don’t care, they just want your money (aka greed).

The good news is that the CAs are at least starting to “get it” (although it may be too late), that issuing SSL server certs is about trust not just them making money. The CAs have started to issue EV SSL server certs, which seem to be going back to the original model of actually vetting the company requesting the SSL server cert to attempt to establish a level of trust.

Cgomez • September 23, 2009 9:07 AM

Considering every time there has been fraud on any bank or credit account I own, it is remedied with either

a) a phone call TO ME by the bank verifying the bogus purchase
b) a phone call made BY ME to the bank to say “what the heck is this?”

and is remedied within 1 hour…

I’d say we are protected just fine.

BangYa • September 23, 2009 9:54 AM

SSL is not 100% dont be drinking the kool-aid. While two factor authentication does have its faults, it does add an additional layer of security. To truly secure a system, you need to use a defense in depth, because there will always eventually be a way in.
Phone call wont work either, I have done work with numerous financial institutions, and have had a 100% success rate on compromising their customers accounts.

James R Grinter • September 23, 2009 10:50 AM

Oh yes, credit card companies know all about authenticating transactions rather than people.

“Hi, this is the security department at CreditCo limited. First I need to be sure I’m talking to you, Mr Customer. Can I have the first and third digits of your PIN, please?”

[Fail.]

JimFive • September 23, 2009 11:05 AM

It seems to me that what this highlights is that when you move into the digital realm, things that look like two factor authentication, really aren’t. A SecureID type fob, even though it’s on your key chain, isn’t really “something you have”. That number on the fob is a special case of “something you know that changes a lot”.

In the physical world the “know/have/are” authenticators are verified by a person. You are seen to know the code, have the key and match the photo, by a person.

In the digital realm those authenticators are all verified in the same way, by being turned into “things you know” and transmitted over the network. Which breaks the entire multi-factor protocol.

JimFive

Janitha Karunaratne • September 23, 2009 1:07 PM

I see one possible solution to this using the current computer’s address.

  • Username/Password as usual
    ** 1. Server Sends Challenge (Unique to the user’s IP which he used username/password) through SMS for example
    ** 2. User computes Response (Challenge + OneTimePassword),
    ** 3. User Sends Response.

The server would limit the session just to that address.

Steve Neville • September 23, 2009 2:21 PM

Like many of the commenters on this post, I think that Bruce has missed the fundamental concept of dealing with security in a layered fashion. Can 2nd factor authentication be defeated?

Absolutely…but only with the right attacks (there are many variants).

Does it mean that we should ‘throw the baby out with the bath water’?? No!

The concept of layered security provides a tremendous opportunity to address a wide range of attacks, including MITM and trojans (sometimes referred to these days as Man-in-the-browser attacks). I believe organizations need to look at the problem more holistically though, considering the following:
1) Defense in depth–a single solution will not solve the problem
2) Impact on the customer experience–you can’t make things too difficult for end users or they will simply take other (more expensive!) paths
3) Ability to react to future attacks–you need to be able to evolve…fraudsters are not standing still, that’s for sure
4) Flexibility of solutions chosen–it’s important that you can deal with multiple user communities
5) Affordability…it does come down to this at some point!

Considering these points, organizations should consider a layered strategy to address these attacks include deploying security capabilities like:
1) EV SSL, which provides a higher level of confidence to end users that they are on the right web site
2) Strong authentication, including tokens, out-of-band OTPs, digital certificates on smart cards, and others. This can include transaction authentication as well, but I would submit that usability will be key here…having users entering a lot of numbers/text in a small device is destined for failure!
3) Fraud detection to transparently monitor online activities and help block fraudulent transactions. Examples: being able to detect that transactions are happening in rapid succession or having traits in the communication to the site that indicate a trojan.

We do have the ability to defend against these attacks…and it’s not through a single solution! But strong authentication definitely has a role to play!

Darren • September 24, 2009 2:48 AM

The SMS backchannel seems to be a fairly strong compromise, but there have been cases of identity theft where the attacker could use the mark’s credentials to transfer their telephone number.

Having stolen bank login credentials previously, the attacker simply transfers all the money to a mule and it’s done with before the mark has put 1+1 together.

PIN dual-factor and SMS backchannel is probably as strong as you can get with the untrustworthy internet.

Yogi • September 24, 2009 3:55 AM

@NoSuchThingAsIdentityTheft

Ya i have read about SSL, however my query is if somehow an MITM were to change the certificate before the SSL handshake were to happen between the client and the server, currently is there a solution that can mitigate this attack?

Tom • September 24, 2009 6:41 AM

Natwest do this (authenticate the transaction) to an extent.
Initial logon is customer number and then random characters from a pin (different to your atm pin) and password.

Any transactions to a NEW payee then have to be authenticated via a card reader that reads your chip and pin card, prompts for your pin and then issues a one time passcode.

Once the payee has been set up you do not need to use a one time password for further payments to that payee.

I imagine it works very effectively for them, reducing fraud with little over head for a cheap plastic card reader.

NoSuchThingAsIdentityTheft • September 24, 2009 9:24 AM

@Yogi
“…if somehow an MITM were to change the certificate before the SSL handshake were to happen between the client and the server…”

I am not sure I understand your question. The SSL server certificate is what tells the client they are connected to the real bank web server. If a MITM forces the client to a bogus web server (with a bogus look-a-like domain) which provides a bogus SSL server cert, then the client would easily be able to detect this to know they are not connected to the real bank website when they verify the SSL server certificate. This is the server authentication part of SSL that specifically prevents MITM attacks.

Keep in mind that the SSL server certificate is simply a container for the server’s PKI public key, provides identifying info, and is digitally signed by the CA (who is attesting to the validity of the identity and that the identity is in possession of the PKI private key).

Now, if you are asking if a CA would ever allow the creation of (and digitally sign) a SSL server certificate for a bogus web server (and bogus domain name) that would be similar enough to a real bank’s domain and SSL server certificate so that it could fool a non-vigilant bank customer? Then I would say yes, it could happen. In this case the problem is not SSL server auth, but the greedy CAs which would allow the creation of such bogus SSL server certs with bogus identities and domain names.

Ian Eiloart • September 24, 2009 10:57 AM

Bruce, can you explain what you mean by “authenticate the transaction”, please? I’ve seen you use the term several times, but have no idea what it means. Can you give an example of a measure that can be used?

Bruce Schneier • September 24, 2009 3:42 PM

“Bruce, can you explain what you mean by “authenticate the transaction”, please? I’ve seen you use the term several times, but have no idea what it means. Can you give an example of a measure that can be used?”

Sure. Think of credit cards. For all the identity authentication schemes built into the system, no one really bothers with them. Few merchants look at signatures. And you can use credit cards to buy things over the phone — no authentication at all.

What credit card companies do is authenticate transactions. They know what sorts of things people do when they steal credit cards. They know what normal spending patterns look like. When a transaction is fishy, they block it. Sometimes they call the cardholder — this happened to me a couple of weeks ago — and sometimes they just cancel the card.

How would this look with electronic banking? I don’t know, really. Maybe the accountholder would get a phone call if he tried to transfer his entire bank balance to Romania. That would be nice.

Bruce Schneier • September 24, 2009 3:44 PM

“Is there a known solution for MITM?”

Dealing with MITM is easy, but requires authentication on both sides.

The AT&T TSD (remember the Clipper phone?) would display a code — I forget if it was two- or four-character — on each phone when the pair went secure. The people talking were supposed to verify that they had the same code on their phones. If the code was different, there was a MITM attack going on.

Bruce Schneier • September 24, 2009 3:51 PM

“We do have the ability to defend against these attacks…and it’s not through a single solution! But strong authentication definitely has a role to play!”

Of course. And if we had infinite money, infinite time, infinite patience, etc., we would implement lots of partial solutions. But we don’t, and the question is what security measures actually give us value for our time, patience, and money.

A security measure that forces the attackers to make a change in their tactics without actually reducing fraud is, in my opinion, not terribly useful. (Of course, those who implement two-factor authentication will see a temporary reduction in fraud, as attackers shift their attacks to banks who have not implemented the technology. But when the technology is everywhere, the attackers will just shift their tactics.) I’d rather see security countermeasures that actually reduce fraud instead of move it around.

William • September 25, 2009 2:17 AM

A couple things this article does not clarify:

  1. A man-in-the-middle attack meant to compromise two-factor authentication is a very specific attack. The fraud/phishing scam targets very specific users and must automatically pass through all authentication credentials. This is a costly and time-consuming effort for the criminal that provides less rewards, oftentimes, than a general phishing attack against a large user base (like phishing against Paypal).
  2. Trojan attack described here has a lot of the same features as a man-in-the-middle attack. For it to be effective as noted in this article, the trojan must be specially crafted for a specific banking or ecommerce site in order to piggyback on the session and begin performing transactions. Again – a much smaller group of victims available through this method. The trojan must recognize a user logging onto a site, must recognize “authorized” status, must recognize a session, and must know how to interact with the application.

The premise of this article is that NO authentication method is strong enough because these attack vectors don’t care what authentication steps occur.

I don’t buy it.

Clive Robinson • September 25, 2009 5:18 AM

@ William,

“The premise of this article is that NO authentication method is strong enough because these attack vectors don’t care what authentication steps occur.”

I disagree to me the premise of the artical is that the authentication is applied in the wrong way and has been demonstrated to have been defeated by various attackers.

The old CIA triad (Conf/Integ/Auth) is the usual argument, however it has a hidden assumption which is “trust”.

“Security trust” is effectivly the opposit of “human trust” for various reasons, however it is fairly clear that no user PC can be trusted for a whole host of reasons (and for that matter neither can the banks computers or most of their security moduls).

For authentication of any kind to work you have to have a communications path where the “end points” can be trusted at “all times”.

There are two issues with this, the first and most difficult to deal with is establishing the “trusted end points”. This is because DLL “Shims” etc are between the users eyeball and the application and therefore can do an “end run” around the application.

Secondly, the majority of systems currently out there only authenticate the setup of the communications path, and assume incorrectly that the authentication will remain good for the entire communications. A MITM attack can decide when and what to pass through or change.

When a “shim” and MITM attack are combined it is game over unless you,

1, Extend the communications end point beyond the reach of the attacker.

2, Ensure all the critical parts of the communication are fully authenticated.

Problem 2 means, that it is the “transaction” that must be fully authenticated not just the comms setup.

Problem 1 is a little more subtal due to side channal attacks. It requires a cryptographicaly secure method by which the user is included in the trusted path in a way in which the trust cannot be attacked.

The simplest way is to have an external device that cannot be tampered with that the user has to authenticate too to use (a pin and smart card are the ATM way of doing it).

When a critical “transaction” is to take place the user has to work through the token on the out bound (to bank) and in bound (from bank) communications.

Importantly the communications must go through the “user” in a secure, verifiable and auditable way (unlike an ATM).

The technology exists to do all of this but few if any organisations get even close to the required level of security.

I’m against the use of mobile phones for a couple of reasons,

1, They are not reliable technology.

2, They are not secure.

That is they may or may not offer a secondary comms channel depending on the phone cell coverage and number of inuse phones in the cell.

And as has been seen on a number of occasions not just the phones but the networks have been subject to succesfull attack.

Oh and a third reason arrises,

How do you know that the user is not “browsing the web” from the phone?

If they are then realisticaly there is no “independent second channel”…

Alinda • October 2, 2009 7:26 AM

If the phone requires no network coverage or connectivity at all when generating an OTP, then it can realistically be regarded as an independant second channel, like http://www.fivebargate.net/ for example. Moveover, such a solution can be used to authenticate each and every transaction without data overhead or SMS costs etc.

Eric D • October 15, 2009 9:15 AM

Most Belgian banks are already authenticating the transactions. It works pretty well but there were some thefts already.

How the system works:
You get a Digipass device (http://www.vasco.com/products/digipass/digipass_readers/digipass_800_range/digipass_810.aspx) where you put your bank card.
At login, the website gives you a number, you type it into the digipass, enter your pin and give the result to the website.
Then, for each transaction, you have to enter your pin, a random number given by the website and the amount of the transaction. That gives you a number to authenticate the transaction.

This means that an attacker has little use of your original login. There was an incident with Dexia bank where a trojan was using the open session of the users to do some transactions, popping up the authentication screen. While most people followed the instructions on screen and therefore signed the fraudulent transactions, it also attracted attention from more paranoid users.

The best attack in that situation would be to hijack the authentication of the actual transactions and to instead preform fraudulent transactions of the same amount. This would probably be discovered within a few days though.

Sherwood Botsford • October 15, 2009 12:50 PM

The out of band is not fool proof against a MITM attack:

User logs in to MITM site.
MITM uses credentials to log into BANK.
Transaction proceeds normally.

MITM now has user login.
MITM logs into Bank as user.
MITM finds phone number of user for out of band verification. (This is something that users can change so it should be in their profile.)

User logs into MITM site
MITM logs into BANK as user.
MITM pretends to do transaction.
MITM phones customer.
Customer punches in PIN in response to phone call.

Transaction is not completed.

MITM logs into BANK
MITM changes phone number for call back.
MITM places transaction that drains account.

To protect it the out of band needs to be initiated twice — once from each end. E.g. The above fails if the user cannot give his PIN over the phone in answer to a call from the bank, but rather must initiate a call to the bank with the verification code.

Clive Robinson • October 15, 2009 2:33 PM

@ Eric D,

“Most Belgian banks are already authenticating the transactions.”

Err no, not from what you are saying,

“Then, for each transaction, you have to enter your pin, a random number given by the website and the amount of the transaction.”

If what you are saying is correct then all you are authenticating is the amount to be transfered not the whole transaction.

As the “to which account” part is not authenticated, there is nothing to stop malware presenting to ou what you think is the right account detail whilst sending an altogether different account number to the bank.

Clive Robinson • October 15, 2009 2:47 PM

@ Alinda,

“If the phone requires no network coverage or connectivity at all when generating an OTP, then it can realistically be regarded as an independant second channel”

Sorry no it cannot.

The reason being that due to the phone connectivity, and that the phone is mutable you do not know if the application running on the phone is good or bad.

This leaves it potentialy open to attack.

Chris Drost • October 15, 2009 4:21 PM

Bruce, I just wanted to comment that this was actually an omission that I recalled from one of your entries last year:

http://www.schneier.com/blog/archives/2008/12/credit_card_wit.html

I have a Rabobank account, so I’ve had to deal with this little PIN device for a while now.

At first I thought, “Oh, what a great idea! The problem with security is that your computer is not trustworthy because it can run everything, including malware. Why not keep the authentication device separate?”

But it strikes me more and more that if there was malware on my computer, it could quite possibly manipulate my user-experience anyway, so that the “You are paying for rent!” user-experience becomes, on the backend, “You are donating to the ‘Help the Needy Nigerian Criminals’ charity!”

Of course, I use Kubuntu GNU/Linux, so I’m not targeted much by those sorts of attacks. But for two-factor to be Done Right, it always seemed to me that your bank needs but to hand you a custom BSD distro on a read-only USB stick, so that you can be sure that the user-interface and SSL components of the transaction are unimpeachable. The second factor isn’t a secure PIN-device; the second factor is a secure user-interface.

Now, I agree that banks can use transaction-profiling to cut down on the problem considerably. But while profiling might be the most cost-effective solution right now, it also doesn’t strike me as great. It only works when it’s cost-effective to tell the criminal transactions apart from the real transactions. What do you do with the transaction, “Chris sent 200 euros to some Paypal account”…? What do you do with a transaction that looks like it was made from a retailer that your bank doesn’t personally know?

Sure, they’re no longer stealing your nest egg. But when people start to view these deductions as a minor inconvenience rather than a major problem, the criminal becomes free also to continue stealing from you over long time-scales. With a lot of indifferent people, I imagine they could still earn enough money to fund the transaction-prettifying schemes that could hide them from traffic analysis.

Clive Robinson • October 16, 2009 2:58 AM

@ Chris Drost,

“The second factor isn’t a secure PIN-device; the second factor is a secure user-interface.”

Your wrong and right.

The “PIN-device” or token needs to authenticate the whole transaction value and account details. Which normaly a “PIN-device” does not do.

Therefore it is token that needs the “secure user-interface”.

The secure token should be the last item in the communications chain before the user, not the PC which can modify your outbound traffic to the bank or lie to you by changing the information the bank sends befor displaying it.

As I have said in the past,

1, The user needs to authenticate to the token

2, The token needs to authenticate to the bank

3, The bank needs to authenticate to the token

4, The full transaction has to be typed into the token to be “signed”

5, The user types the full transaction and signature into the PC and sends it to the bank.

6, The bank evaluates the transaction and signiture and if ok sends back a secure confirmation based on the transaction information.

7, The user types the secure confirmation into the token.

8, The token evaluates the confirmation against the transaction if it is ok the token calculates a secure autherisation based on the secure confirmation which it displays to the user.

9, The user then types the secure authorisation into the PC and sends it to the bank.

10, The bank checks the secure athorisation and onli if valid does the bank carry out the transaction.
Anything less is open to attack.

Importantly the token must work through the user in both directions not directly with the PC otherwise the possability for a covert channel is opened whereby the token can be influanced by malware (which is also the reason why the token should not be an application on a mobile phone or other device that has a communications path other than through the user).

The problem with all this is the user has a lot of typing to do both on the token and on the PC.

However it is a requirment otherwise an attack is possible.

Markus Thomas • October 16, 2009 5:40 AM

Using my German online banking, I am issued a specific one-time transaction pin via text messaging to my mobile phone. The message states the requested transaction with recipient’s account number, bank branch code and amount to be transferred.

Of course my mobile phone could be compromised, especially, if I was using a smartphone to do my internet banking and to recieve the text messages. However, if someone had access to my phone and internet banking login without my knowledge, one could easily create “legitimate” transactions, which could prove almost impossible to prove fraudulent.

Clive Robinson • October 16, 2009 3:30 PM

@ fullmoon,

“This sounds like what IBM is doing out Zurich.
They are using a USB device for the second factor.”

I’ve had a quick look but there is to little info to make a sound judgment.

My main concern is that it is connected via USB to the PC as a USB-MSD.

If there are any weaknesses in the IBM design then the malware on the PC will have a high bandwidth connectivity to the device to exploit it, without the user seeing anything happening.

It’s an attack vector that is all to likley and I’m far from confident it could be made “exploit proof”.

One reason to be wary is “how is the device programed” with the secrets, and are the secrets unique to each device in their entirety or is the SSL key common etc etc.

Likewise I’m not 100% certain it is going to pull up the transaction details (account sum info etc) reliably. A weakness with the bank end of the software might enable transaction information that the device does not recognise but the bank does (say using a multi octet char set as opposed to the standard HTML ISO char set).

There may be other worries I could come up with after a little more thinking but it would be unfair as the device gives every indication of still being in the final development phases.

However the major advantage is that if it works as advertised then it’s a single key press.

As I noted above the direct connection is a very real security risk, which ten years ago I decided was one that for security should be avoided. The downside of this choice is a lot of typing on the users behalf and thus a much more limited information capacity.

So the trade off IBM has is a potential attack vector -v- a lot of user typing and less information bandwidth (no guesses which would be prefered by most). The single button also increases reliability and reduces cost so it’s probably a prefered option to the way I sugest (which is probably best for security).

As for the downside the TechRepublic author noted about needing “multiple devices” for multiple accounts, I’m not realy sure that is a major issue for most people. And if it was IBM could solve it quite simply with a SIM reader to get the critical details off of a bank card.

shahram karimian • October 18, 2009 9:44 AM

@ clive

Excellent ideas. The payment authentication makes a lot of sense but how would that work with the login process?
I agree with Bruce about Time, money and patience.

Clive Robinson • October 18, 2009 10:31 AM

@ shahram karimian,

“but how would that work with the login process?”

1, The user types in their username on the website and sends it to the bank.

2, The bank sends a chalenge back.

3, The user starts up the token and types their pin in to unlock it and then select the login menu etc.

4, They type in the chalenge from the bank into the token, which displays a response.

5, They type the response into the web page and send it to the bank.

6, The bank processes the response and checks it is valid and sends back an acknowledgement.

7, The user types in the acknowledgment into the token and the token tells the user if the login process has compleated or not.

There are a number of ways the chalange / response / acknowledge can be done and in some cases it can be reduced.

For instance if with public key systems a “first cut” system would be,

When the user identifies themselves the bank looks up the users public key in it’s login database and uses this to encrypt a random number which it then encrypts with the banks private key and sends the result to the user.

The users types it into their token which decrypts it with the banks public key and decrypts the result with the users private key to get the random number back.

The token then does some transform on the random number (that is known to the bank). Then encrypts the result with it’s private key and encrypts the result with the banks public key and provides it to the user as the response.

The user sends the response to the bank, where there systems decrypt with the banks private key, then the users public key and checks the result is the same as the original random number that has been transformed by the same process. If the result is the same both ends have authenticated to each other.

The ack is just a way for the bank to tell the token it has authenticated to the bank or not as the case may be.

I say it is a “first cut” as there are a number of other things you need to do to make it secure but they are not required to explain the principle.

Clive Robinson • October 18, 2009 2:06 PM

@ shahram karimian,

“Wouldnt this method be suceptible to a MITM session hijack?”

In what way are you thinking it would be affected by passing on an untrusted path?

The user name is needed as the key into the bank database.

It can be sent as plain text or encrypted, if encrypted it would have to come from the token.

Also if encrypted it would need to be different every logon thus it would have a time and random number attached to the username prior to encryption.

In practice I don’t think encrypting it gains you much compared to the extra work involved.

What the next step does is send a “ticket” from the bank in a way only the bank can do (ie via it’s private key) and the users “public key” stored in the banks DB (but not generaly public).

Although a person in the middle could “unwrap” the encryption with the banks public key they end up with a ticket that is encrypted with the users public key which is not a lot of use to them.

The users token however can unwrap the ticket from both the banks private key and their public key.

The ticket should be in a format whereby it can be verified by the users token as valid (there are various ways this could be done such as appending a hash etc).

The users token performs some kind of transform to the ticket such as ADD and XOR then MUL mod a prime. This transform is effectivly a shared secret between the users token and the bank.

The users token then puts the response in the verifiable format, encrypts it using it’s private key and the banks public key and sends it back.

Providing the transform and the verifiable format are both orthagonal to the public key operation a man in the middle could not (except by chance) manufavture a valid response to the bank.

The bank decrypts via it’s private key and the users public key and checks not just that the response is correct in the verifiable format, but also that the transform has been correctly carried out.

If it has then the bank can be reasonably certain it is talking to the users token.

It then sends back an ack with a timestamp etc that it encrypts with the users public key and the banks private key.

On decrypting this the users token is likewise reasonably certain that it is talking to the bank.

For the man in the middle to pass himself off as the bank he would have to know both the users “public key” and the banks “private key” or pass through unchanged the users tokens ID and banks chalenge unmodified. Likeise to pass himself of as the user to the bank he would additionaly have to know the users “private key” and transform.

The man in the middle can change and modify other traffic however actual transactions are protected.

If I’ve missed something let me know and I’ll check it.

shahram karimian • October 18, 2009 10:06 PM

@ clive

So once the token authenticates with the bank (out of band) the user can log in?

What if the attacker does a MITM by getting the username for the session and waiting for the for the user to authenticate via the token and then logging in instead of the user?

As long as i can share a passwords with another user, MITM is possible. Meaning if i can call you you on the phone and you can give give me your username, password and OTP and i can login from my computer.

Maybe installing an SSL cert on the desktop would stop this attack but whats to stop malware from stealing the key?

Clive Robinson • October 18, 2009 10:53 PM

@ shahram karimian,

“So once the token authenticates with the bank (out of band) the user can log in?”

No the user has logged into their token (by entering their pin into it and therby weakly authenticating to it).

The users token and the bank are authenticating to each other (strongly).

The user does not actually log into the bank so their pin never gets sent down the wire.

The bank and user private keys are not known (or should not be) to any individual.

Likewise the user does not need to know their public key only the token and the bank need to know that.

And importantly the values for the orthagonal transform is a “shared secret” only known to the bank and the token never to the user.

Effectivly the user has not logged into the bank all they have done is establish a chain of authentication,

1, User to token (PIN).
2, Bank to token (chalenge and ack).
3, Token to bank (response)
5, Bank through token to user (Ack).

Dan Deighton • October 24, 2009 9:22 AM

Cross-site Request Forgery (CSRF) attacks are another active threat that bypasses two-factor authentication.

Jamey Heary • October 24, 2009 4:43 PM

The effectiveness of two-factor depends on the type used. For example if you use User based certificates as your second factor and perform mutual authentication then the man-in-the-middle attack is rendered defunct. A trojan based attack would still be effective when running through its victim host but otherwise would not be able to steal a non-exportable certificate to perform the attack on another host.
http://www.networkworld.com/community/node/31124

Glenn • July 10, 2014 1:07 PM

I also agree mutual authentication is a big gap in what is done for most banks. Would we be able to compartmentalize a banking application to prevent and/or perhaps further end-point protection via micro-virtualization such as those being implemented by Bromium ( http://www.bromium.com/innovations/micro-virtualization.html)? I had proposed in a paper I wrote something along these lines to help fight ransomware. My ransomware paper is at http://cybersecurity-hq.blogspot.com/2014/03/ransomware-challenges-posed-by-cyber.html.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.