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.
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.
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.
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.
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.
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.)
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?
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.
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.
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.
@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.
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.
@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.
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.
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.
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).
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.
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.
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.
> 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.
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.
> 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.
@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.)
@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).
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.
@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.
"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.
"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.
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?
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?
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.
@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. [www.e-komerce.cz]
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....
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.
@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.
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.
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 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: [www.cronto.com]
"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.
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.
@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.
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.
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.
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.
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.
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.
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
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.
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!
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?
@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.
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, 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.
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.
"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.
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.
"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"...
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 [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.
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.
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.
"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.
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.
"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.
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.
"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.
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.
"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.
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?
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. [www.networkworld.com]
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 ( [www.bromium.com] I had proposed in a paper I wrote something along these lines to help fight ransomware. My ransomware paper is at [cybersecurity-hq.blogspot.com]