The Failure of Two-Factor Authentication

Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.

The problem with passwords is that they’re too easy to lose control of. People give them to other people. People write them down, and other people read them. People send them in e-mail, and that e-mail is intercepted. People use them to log into remote servers, and their communications are eavesdropped on. They’re also easy to guess. And once any of that happens, the password no longer works as an authentication token because you can’t be sure who is typing that password in.

Two-factor authentication mitigates this problem. If your password includes a number that changes every minute, or a unique reply to a random challenge, then it’s harder for someone else to intercept. You can’t write down the ever-changing part. An intercepted password won’t be good the next time it’s needed. And a two-factor password is harder to guess. Sure, someone can always give his password and token to his secretary, but no solution is foolproof.

These tokens have been around for at least two decades, but it’s only recently that they have gotten mass-market attention. AOL is rolling them out. Some banks are issuing them to customers, and even more are talking about doing it. It seems that corporations are finally waking up to the fact that passwords don’t provide adequate security, and are hoping that two-factor authentication will fix their problems.

Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.

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 real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.

Recently I’ve seen examples of two-factor authentication using two different communications paths: call it “two-channel authentication.” One bank sends a challenge to the user’s cell phone via SMS and expects a reply via SMS. If you assume that all your customers have cell phones, then this results in a two-factor authentication process without extra hardware. And even better, the second authentication piece goes over a different communications channel than the first; eavesdropping is much, much harder.

But in this new world of active attacks, no one cares. An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can’t do it himself. And a Trojan attacker doesn’t care, because he’s relying on the user to log in anyway.

Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.

This essay will appear in the April issue of Communications of the ACM.

Tags: , , , , , , , , , , , ,

Posted on March 15, 2005 at 7:54 AM • 132 Comments

Comments

Chris Becke • March 15, 2005 8:29 AM

The man in the middle attack should be simple enough to mitigate if the two channel authentication is used. I mean, some client side java could treat the SMS value as a secret value that now the bank, and customer knows, but the attacker does not. By using it to encode the password and transaction stream the man in the middle would end up watching an encrypted stream.

Of course, were back where we started, building a secure channel to communicate over, ironically over the old secure channel (SSL) we originally built to solve the same problem (being man in the middle).

AC • March 15, 2005 8:49 AM

Continuing to what Chris said: Why wouldn’t banks simply start to use client SSL certificates? Shouldn’t this make MiM attacks harder? If my bank requests client cert, and MiM doesn’t (and there’s no chance that they know the client cert), I guess there’s no current browser that will complain? Isn’t that a first thing that needs to be fixed (once I import a client cert for some address, browser shouldn’t allow me to connect to what appears to be this site, if that site doesn’t use my client cert). Is the above scenario consistently covered by SSL?

NR • March 15, 2005 9:02 AM

AC: Client certs sound great in theory, but in practice they’re almost impossible to support on a large scale. Different versions of different software have varying levels of support for certificate related standards. What works in one product doesn’t work in another product. There’s the trusted root problem (how does a bank get their root CA certificate distributed to the trusted root stores of the various software products? Or should everyone be forced to buy from Verisign?) Certificates expire and have to be renewed. Validation is a mess. Windows/IE will at least try to retrieve a current CRL. Most OpenSSL based products (read: most open source products) don’t even check the validity date on certificates; they only concern themselves with the key arithmetic. Forget about CRL or OCSP validation. Users need to be aware of their private key and know how to back it up securely if they move to a different machine or reload their existing machine.

And MiM attacks would still happen because most users are trained to just click “OK” whenever a warning message pops up on their computer.

Timm Murray • March 15, 2005 9:09 AM

NR:
The public key wouldn’t need to go through a central authority, except the one that is already in place: the bank. Part of signing up for an accout could be bringing a key fingerprint. The bank and its employees are already trusted by the fact that you’re willing to let them handle your money.

Guan Yang • March 15, 2005 9:10 AM

What if the bank requires every financial transaction to be separately authenticated? (This is how my bank’s two-factor authentication works.)

rcme • March 15, 2005 9:22 AM

I would tend to agree that in the “big picture”, if the technology isn’t used properly or the technology isn’t implemented properly, it doesn’t matter how many factors of authentication one has.

However, I will say that I think that two factor authentication will solve most of today’s problems and “near future” problems given it is used and implemented properly.

In the case of a Trojan attack, I tend to follow the philosophy that once someone allows “bad” software to be installed on their computer, it’s “game over”. That software can do whatever it wants, disable software like AV and firewalls, replace OS components like GDI and browser, etc. The only real mitigation here is some form of “sealed”, trusted hardware/software device.

Regarding the Man-in-the-Middle attack, the technology (SSL) already has mechanisms to detect this. The problem is that it is not being used properly (users not checking the server’s SSL certificate by clicking on the “lock” icon), and the technology is not implemented properly (browser not making SSL server certificate validation obvious and simple enough).

Also, as I recently found out, one of the “big name” SSL certificate issuers is degrading the value of SSL server certificates by issuing SSL server certificates without any real verification that the organization even exists. The only verification they perform is to check that the domain name associated with the certificate has been registered! No DUNS verification, background checks, nothing. So, without additional user education and browser UI, this additional “security granularity” (as they call it) will only tend to make matters worse, since they have now created different levels of SSL trust that are not obvious today (without actually looking at the details of the certificate, which most will never do).

Dave • March 15, 2005 9:31 AM

I don’t usually advertise for people. But, WholeSecurity has a product to battle the trojan issue. It’s a behavior-based scanner that can be loaded on the client as Active-X (oh, the horror) or a Firefox/Mozilla plugin. It then can scan for trojan malware at every login.

http://www.wholesecurity.com/

Nick Owen • March 15, 2005 9:40 AM

Many strong authentication systems now included bi-lateral authentication. and can help fight the man-in-the-middle attack. The trick for online transacation processors will be to choose strong authentication systems that do more than just add a second factor. Get an infrastructure that is extensible. Hardware tokens aren’t it.

inference • March 15, 2005 9:46 AM

Lets take with rcme has stated a step further. It is indeed game over when a user allows software to be installed on their machine, but how many users are smart enough to truly appreciate what that means. How many of us – many of us who should know better – ever fully read the EULA. If we don’t, do we expect the “average” user to?

Lets move this to a real world example – from http://www.marketscore.com, who provides a value of (cut and paste from their website states):

Defend Against Email Viruses
All at No Cost to You!

From the EULA of their software:

Marketscore can only monitor the Internet behavior and activity of your Household’s registered and configured computers. As a Member, you therefore control which computers the Marketscore service is available on. Marketscore monitors all of your Internet behavior, including both the normal web browsing you perform, and also the activity you may have through secure sessions, such as when filling a shopping basket or filling out an application form that may contain personal financial and health information. Marketscore’s proprietary and patent pending technology allows us to see the details of secure pages while protecting such content from parties other than the site to which you are connected.

While it clearly identifies at a high-level what is going on; it really only scratches the surface of exactly what is happening. How many typical users if they took the whole time to read the EULA would fully appreciate the above.

Marketscore can decrypt secure data transfers between a PC user and a web site using SSL. This is achieved by Marketscore installing its own Trusted Root Certificate on the machine allowing them to monitor SSL traffic. When you establish a connection with an SSL site, with the Marketscore tool installed, you actually trust the certificate of Marketscore, and not the business/vendor with whom you believe you are connecting to. They establish the SSL session between the Marketscore proxy and the business/vendor. This makes them privy to all the communications you believe are encrypted between you and your choice of SSL sites.

In essence this group issues you a certificate on behalf of the site you are visiting that allows them to open and decrypt all of a users encrypted traffic. Enough said!

The fact that any group/software can install and establish themselves as a certificate authority within Windows and IE and potentially other platforms should be of concern to us all.

piglet • March 15, 2005 10:29 AM

Again, Bruce, you live on planet America. This kind of authentifiation hasn’t been in use “only recently”, it has been used for at least a decade, and your readers have told you this many many times. Why is it so difficult for you to take into account experience from outside the US???

Let`s look at PIN/TAN, a type of two-factor-authentification that has been around for at least a decade and that I am using regularly. A bank sends out (by registered mail) a list of one time codes to its customers, called TANs. For each and any transactiion, the user has to enter one of the TAN codes. This system is efficient against phishing because a TAN code is necessary after logging in. The attacker cannot simulate this situation without having actually access to the customer data. So what can go wrong? The key-logging attack can still work. There is a detailed paper by some German researchers which examines this attack: http://arxiv.org/abs/cs/0410025

The weakness exploited by this attack, however, is not due to the method itself, it is due to the general fact that anything that is entered into a keyboard can be captured by a Trojan. In this case, the attack is difficult because the attacker has only a small window of opportunity and the attack can hardly go unnoticed (the atacker has to capture the TAN, prevent the legitimate user from sending it, e.g. by forcing the brwoser to close, and initiate at once his fraudulent transaction) but yes, it is possible.

So is all hope lost? Do we need expensive hardware equipment, as Bruce once argued, to secure banking transactions? My answer is no because the system can be secured with little extra effort. The solution would be to demand two TANs, or a “two-factor TAN”, for the transaction, effectively leading to “three-factor-authentification”. This sounds complicated but needn’t be. To log in, the user would need not only the PIN but also a one time TAN. For each individual transaction, the user would need one additional TAN as usual. This will prevent phishing and Trojan attacks beacause the attacker can never capture two valid TANs: The first TAN will be expired as soon as the user is logged in. If the attacker prevents the user from logging in, he won’t be able to capture a second TAN. Can anybody beat this?

Anonymous • March 15, 2005 10:38 AM

@Bruce
I beg to differ.
If I understand you correct, you seem to think that banks are wasting their money making two-factor authentication tokens (“in the end there will be a negligible drop in the amount of fraud and identity theft”). But what about all those people writing down their passwords and having easy-to-guess passwords? Will we not see a drop in fraud for these ones? Or at least make sure you can’t eavsdrop the password of my, say, golf-locker and use it on my bank account?

Social engineering will always enable an attacker to lure people into fake websites or make them install trojans. I it is worthwhile making passwords useless to an attacker without the authentication token.

I see your point, though, and agree that “two-factor authentication isn’t our savior”.

Johannes • March 15, 2005 10:51 AM

@Piglet

This sounds complicated but needn’t
be. To log in, the user would need not > only the PIN but also a one time TAN. > For each individual transaction, the
user would need one additional TAN as
usual. This will prevent phishing and
Trojan attacks beacause the attacker
can never capture two valid TANs: The
first TAN will be expired as soon as
the user is logged in. If the attacker
prevents the user from logging in, he
won’t be able to capture a second TAN.
Can anybody beat this?
Easily. If you have a Trojan installed in your computer, I think I can agree with rcme that it’s “game over”.

The attacker can for instance wait for his victim to make a transaction, and then start his active attack. Namely using the second TAN to perform his own transaction, and dropping the original one.

piglet • March 15, 2005 10:58 AM

Johannes, please elaborate. The point is that the TAN expires as soon as it is sent to the bank server. So if the user logs in with a valid TAN, the attacker may capture it but it will be invalid. In order to start his own transaction he must first log in using a valid TAN, then he’ll need a second valid TAN.

As an aside, the bank has also some opportunities to enhance security. For example, the server should notice when the same user is logged in from two different locations and could trigger an alarm.

Brad Clarke • March 15, 2005 11:17 AM

1 – Those numbers from the key fob are not random, they’re calculated
2 – No security is perfect, the magic phrase is “risk reduction”

The point is to reduce the amount of time that a captured password is valid. Since the fob output is typically only valid for a minute this means that any attacker would either need a very complex automated system or would need to be sitting there waiting for you to log in to your bank instead of just putting up a keylogger or traffic logger and coming back next week. This significantly raises the bar for an attacker and for the cost is some of the best risk reduction you can get.

3 – Do you have a better idea? Is there any reason you couldn’t use this -with- that better idea?

rcme • March 15, 2005 11:20 AM

@piglet
The attack is basically what Bruce described. In the case of a Man-in-the-Middle attack, there is basically a proxy/app gateway that presents a fake bank website to the user and acts as a client to the real bank website. This proxy/gateway just passes whatever authentication the user inputs on to the real bank website. Depending on the sophistication of the malicious proxy/gateway, it can then do whatever it wants with the real bank website and present whatever it wants back to the user (user could see web pages that look like they completed a valid transaction, but the proxy/gateway did something completely different with the real bank website). This attack works because the user doesn’t properly verify that they are communicating with the real bank website.

The same thing can happen with a Trojan attack (except the possibilities are almost endless). The Trojan could be a malicious gateway/proxy that is running on the user’s computer, or could be doing other things, like running a hidden browser app, etc., since in the case of a Trojan, anything is possible once the user allows malicious software to be installed on their computer!

Matt Secoske • March 15, 2005 11:23 AM

piglet:

Then the trojan just takes over the TAN and drops the users transaction with a “The server is currently unable to process your order” bs.

piglet • March 15, 2005 12:06 PM

The Trojan couldn’t succeed because of the need to capture two TANs, not only one.

A man in the middle attack might be possible but it looks hard to me. I think it has never been done (phishing has been tried often, but not real man-in-the-middle) although PIN/TAN systems have been used billions of times by millions of customers over at least a decade. The scenario that would be needed for such an attack is unusual for the banking customer. Customers have been told over and over again never to use any login link sent to them by email. The systems I am talking about are of course SSL protected, anything else would be ridiculous. I agree that some people might stil be fooled but the level of sophistication required is unusually high. The risk of detection is high – it is suspicious if a transaction is aborted right after entering the code. Moreover, even if some people can be fooled to do almost anything, the attack to be worthwile must be aimed at a large audience, some of whom will be suspicious immediately and notify the bank, which in turn can act at once and identify the fraudulent server.

So to summarize, Bruce may be right to say that even tho-factor-authentification doesn’t provide absolute security but we have known before that there is no absolute security. Bruce has always said this and I find it odd that he now rejects a protocol which even if it isn’t absolutely secure, offers more security by several orders of magnitude than the bad old username/password.

bp • March 15, 2005 12:14 PM

Bruce,

You’re quoted in an InfoWorld interview of March 11 as saying the following:

“To me, we’re approaching the problem wrong. The problem isn’t how to secure the user’s computer or how to authenticate. The problem is fraudulent transactions. And the solution is to make the financial institutions liable for fraudulent transactions. Think about credit cards. As long as fraud was the responsibility of the cardholder, the credit card companies never bothered improving security. But as soon as fraud was their problem — cardholders only had a $50 liability — (credit card companies) did a lot to improve security. And they didn’t worry about how well the cards were stored in the user’s wallets; they concentrated on fraud detection in their own databases. As soon as we make financial institutions liable for online fraud, they’ll figure out how to manage the risk.”

To me, the problem is that “proof” of our identities for accessing a bank account, or opening a new account, usually depends on nothing more than keeping secret information that thieves can get with little difficulty. Whether that information is a password stolen through a phishing email, or a social security number gotten from ChoicePoint’s database, the goal ought to be to make knowledge of that information alone less useful for commiting fraud. And that involves some sort of stronger authentication.

I’d agree that banks get more serious about security when there’s some legal liabililty involved. But even though banks supposedly monitor their systems for signs of credit card fraud, there’s still tons of fraud going on anyway. What exactly would you propose that banks do to prevent a stolen password from allowing someone to break into your account? Or are you suggesting that banks should somehow be able to prevent passwords from being stolen in the first place?

IMHO, the goal ought to be more along the lines of “zero tolerance” for fraud, rather than just “managing” the risk. In other words, try to prevent it in the first place, rather than focusing on how to deal with it afterwards. Now obviously, neither two factor authentication or anything else will eliminate all fraud, and fraudsters will always be seeking to work around whatever security is in place. But as others have pointed out, there are ways to deal with man-in-the-middle attacks and trojans. As fraudsters come up with new methods, banks will have to continuously refine their security.

Maybe banks should become liable for fraudulent transactions to the extent that they do not adequately provide better methods for authenticating those who seek access to existing accounts, or who want to open new accounts.

piglet • March 15, 2005 12:19 PM

“But as soon as fraud was their problem — cardholders only had a $50 liability — (credit card companies) did a lot to improve security.”
I haven’t seen any evidence of that improved security, could anybody elaborate? I guess what credit card companies are doing is to have the vendors bear the risk. This has nothing to do with improving security.

Bruce K. Marshall • March 15, 2005 12:36 PM

Yes, we must be concerned with the other avenues of attack on Web transactions. But Mr. Schneier shouldn’t pretend that beefing up authentication is without merit. We have decent countermeasures to MITM and trojan attacks now. It is called SSL and anti-virus/spyware software.

What we don’t have is an industry accepted standard for enforcing good password selection — a truly sad predicament. And since two-factor authentication effectively eliminates that concern we can actually start deterring script kids that just grab a password combo list off the Internet.

There will be sophisticated attackers who will still commit fraud using keystroke loggers, phishing attacks, session ID prediction, etc. But we haven’t given up on any other security solutions just because we knew it would only raise the bar and not eliminate the risk.

Bruce K. Marshall

rcme • March 15, 2005 12:45 PM

@piglet
“The Trojan couldn’t succeed because of the need to capture two TANs, not only one.”

Trojans will always succeed, since they have complete control of the user’s computer. They can control what apps run, what the user sees on the display, what is sent over communication channels, whatever.

As I read it, Bruce is making a distinction between what we see today, as “time-shifted” attacks, where someone’s credentials are stolen and the attack against their account is performed sometime in the future, and “real-time” attacks, where the fraud is committed in real-time using the user’s credentials to commit fraud at the same time they are (or think they are) interacting with their bank’s website.

Israel Torres • March 15, 2005 12:54 PM

It appears that no one is seeing the real issue. It is summed up in three letters:

M-A-N

As long as this is part of the key, the key will have its faults.

Israel Torres

piglet • March 15, 2005 1:06 PM

rcme, the Trojan may have control over the customers’ computer, but not over the bank’s server. You are still not getting it: the TAN codes we are talking about expire as soon as they reach the server. They can’t be used more than once. The Trojan may succeed in capturing an expired TAN but it won,t be of any use. If it captures the TAN and then prevents it from being sent to the bank server, the attacker gets one (1) valid TAN. But as I explained it, he would need two (2) valid TANs in order to make a transaction. Got it?

rcme • March 15, 2005 1:25 PM

@piglet
The Trojan scenario that I am describing is a “real-time” attack. The Trojan that has control of the user’s computer (and also the user’s session with the bank’s server) is simply passing the TAN code through onto the bank server, but as part of a “hidden” bank session the Trojan has with the bank that is different from the bank session that the user thinks they have. The Trojan is presenting a different “fake” session to the user, but using the user’s authentication (two factor, etc.) for its own session with the bank. So, the user thinks they are connected to the bank, and the Trojan can present a perfectly valid looking transaction (no errors), while using the user’s credentials as part of its own bank session. Since a Trojan has complete control over the user’s computer, this is certainly possible.

Daedala • March 15, 2005 1:35 PM

@rcme

See the Grams Trojan, which does exactly that with eGold accounts. The Trojan watches for an eGold session to open, then behind the scenes makes its own transactions while the user is logged on.

Tobias D. Robison • March 15, 2005 2:53 PM

The practical problem with tokens is very simple: If they really do a good job, then eventually I will have to carry around either 45 of them or 1 of them. It’s impractical to carry 45. And if every service that autheticates me relies on the same token, I will have too many eggs in the same basket.
– Tobias D. Robison

serlu • March 15, 2005 3:20 PM

My bank at least has some resolution to this problem. Even if there is a man-in-the-middle attack or trojan they wouldn’t be able to do much.

Any account number I send money to have to be authenticated by me using my active card. And all transactions also have to be signed. So unless the sum total of my transactions (8 digits – which is what I enter on my active card) translates to their account number they would’t be able to fake an transaction sending money to their own account.

They could of course create a nuisance by sending the money to another of my registred accounts?

(Accounts are really “bankgiro” or “postgiro” numbers)

bp • March 15, 2005 3:56 PM

“And if every service that autheticates me relies on the same token, I will have too many eggs in the same basket.”

You should only have to carry around one token that works for all your accounts. But remember, it’s two factor authentication. Maybe the same token can be used for each account, but each account would still assign its own password/PIN. So the token by itself wouldn’t allow access to all your accounts.

Eric K. • March 15, 2005 4:20 PM

@Bruce:

So, you’ve repeatedly warned us that everything’s unsecure. While it’s fascinating to read about the details of how each and every security product fails to provide security, it still leaves us wondering one thing:

What, according to you, is a secure alternative?

Eric K. • March 15, 2005 4:28 PM

@Israel Torres:

You (and apparently Bruce too) tell us that as long as man is part of the security process, it’s not going to be secure.

Fine.

So… Got any ideas on how to get man out of the process? Or are we simply suppossed to give up and say “Well, we’ll never be secure. Let’s just live with being as secure as we can.”?

I’m thinking that the point is to be aware of the lack of TOTAL security and to do as much as possible to minimize the opportunities for others to perform man-in-the-middle attacks and trojan attacks before making use of such security measures?

If so, shouldn’t we change the tone of these warnings from “You’re never really secure!!!1!” to “Here’s how to maximize security and minimize the risks…”?

Israel Torres • March 15, 2005 5:09 PM

@Eric K.

Perhaps I’ll set up a blog about my security rants and ideas. However I’m not sure how great that would actually be in the grand scheme of things. Although I can provide the suggestion that security in its modern state is being looked at more backwards than correctly. The idea isn’t that we should provide all these mechanisms for humans to jump through and expect them to succeed. The idea is that man as a whole mindset must change in the eyes of security… not the other way around which is in wide practice today. (the backwards part).

Israel Torres

Davi Ottenheimer • March 15, 2005 5:16 PM

@Bruce
Two sentences you wrote that are only a few apart, appear to clash:
1) “See how two-factor authentication doesn’t solve anything?”
2) “Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet.”

So which is it? Are you just warning everyone against thinking two-factor authentication is some sort of security panacea? Perhaps this is in response to the flurry of comments on your blog regarding remote access to a utility:
http://www.schneier.com/blog/archives/2005/03/melbourne_water.html>
utility

Piglet makes a great point about non-“US systems”. On another one of your blog comments, we know that China is already deploying USB fobs for bank authentication (according to Paul Chen) http://www.schneier.com/blog/archives/2005/02/bank_sued_for_u.html

I say Microsoft’s CeBIT announcement that they are moving to two-factor authentication is a good sign, as is their move towards leveraging identity technology already deployed:
http://www.newsfactor.com/story.xhtml?story_title=Microsoft-To-Ditch-Passwords&story_id=31182#story-start

When I take a step back from this blog entry, what I see is a message that too many companies have built authentication systems on a very weak foundation, so they now must spend a lot of money trying to improve security and win the trust of their customers. But the reality is that they will soon have real choices with regard to stronger authentication, fed by real demand. And I predict that the right combination of investment and demand, based on regulation (self or imposed), will actually lead to innovations and a drop in the amount of fraud and identity theft.

As a final thought, your blog entry reminds me of the adage that alarms do not reduce unattended auto theft for the following reasons:
1) People leave their car unlocked
2) People leave their windows/sunroof open
3) People leave valuables sitting in the open
4) People leave their keys in the ignition with the engine running

Yes, we know that car alarms cost us a lot of money and will not reduce theft alone. But that is hardly a reason to dismiss a technology by saying it “doesn’t solve anything”.

M • March 15, 2005 5:29 PM

All,

I agree with Bruce when he writes that OTP isn’t going to solve the problem as long as you can’t trust the browser or if you’re pointing at the wrong site. TANs won’t help either for the same reasons.

Still, even though confidentiallity won’t be addressed, there’s another feature OTP HW tokens can deliver that will make transactions more secure: they can “sign” parts of the input. For example, in a finantial transaction, if you require that a set of digits of the destination account is input into the token and that this result is posted together with the account number, it will be more difficult to change this info on the fly.

my ?0.02

— M

Ari Heikkinen • March 15, 2005 6:32 PM

Could rant about this all day.. I’m always amazed to read comments that claim antivirus, antispyware or some other antiwhatever software would be some kind of a “magical” solution to fix security problems. No matter what their marketing tells you, antivirus or antispyware software will only “protect” against known things. They don’t really solve any security problem at all.

The minute someone writes their own, you’ll be as vulnerable to his/her attack than you ever were, even before installing that cool brand spanking new anti-whatever tool.

Your typical user is someone who’s never seen a computer before, who goes and buys that cool’n’cheap new laptop (with broadband as a bonus, ofcourse) which usually ships with that “cool” operating system that has more holes than cheese, then they manage to boot it up, get it on the net (with the instructions that came with it), doubleclick on the browser icon on the desktop (surprice, the most broken and hardest to configure browser in the universe), and finally start surfing around the net opening and running every “cool” thing they ever come across..

Any security measures involving these people (and their machines) should start with an assumption that their machine is already hacked, already running anything they ever came across the net (spyware, trojans, viruses) or any other malicious software designed to do harmful things.

Expecting anti-whatever software to fix security problems is security through obscurity at its best..

–Ari

Davi Ottenheimer • March 15, 2005 6:48 PM

Hey, I object to bashing users over this. In defence of the poor maligned users:

I disagree completely with the point “Early adopters of the technology may enjoy a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.”

First of all, Bruce you should specify whether you mean fraud will always rise no matter what, or fraud will not drop due to two-factor auth. I know it’s a nit, but still important to my next point.

This is not about technology as much as a change in culture with regard to identity theft. Many of us have made this point on the blog before, but it never seems to hit home.

If you want to argue that a particular mechanism has a limited useful life or can be broken, then it’s a safe bet to say everything can eventually be broken. Big deal. The sun always sets.

On the other hand, if you throw Roger’s innovation/adoption curve up on the wall you might find “early adopters” on the uphill side of innovation (and return on investment) for a reason. They are trying out “new ideas in a careful way”. This might put some perspective on your suggestion that two-factor chip authentication is twenty years old and it is too late to be useful…moreover, let’s not confuse the RSA sales pitch (buy tokens or die) with fact.

I say that two-factor authentication is just about to reach the early majority, and I emphatically agree with your words of caution since careful thought during adoption will help spur real innovation, but I totally disagree with your economics. The early majority phase should remind you to change you message in order to communicate with the mass of users/adopters who are far more accepting of change and are actively shifting the culture towards an improved security posture. These are the users and system stewards who will know that two-factor is not a panacea. The sun always rises.

piglet • March 15, 2005 6:59 PM

@rcme
I was thinking of a Trojan key-logging attack as outlined in http://arxiv.org/abs/cs/0410025. The attack you are describing (I verified tha grams Trojan, http://www.securityinfowatch.com/article/article.jsp?id=3243&siteSection=339) is of course more powerful. If the attacker succeeds to compromise the customer computer so badly that he can fake whatever he wants, everything becomes possible, no matter the authentification protocol used. This must be taken seriously.

However, this doesn’t mean that we can give up trying to secure transactions. The grams attack relied on Windows/IE security holes that needn’t be there and that can be closed. And this type of attack demands much more sophistication than we have seen up to date (it seems that the grams Trojan didn’t succeed). I gather from the description that the grams attack was relatively simple. Against a PIN/TAN banking web site, the Trojan would have to be really smart to succeed without provoking suspicion (e.g. “pending transactions” must show the users unsuccessful transaction and hide the fraudulent transaction). Okay, maybe the attacker doesn’t mind provoking suspicion but this will increase the chance that the fraud is detected early.

Once again, while there will never be 100% security, financial institutions and customers can do a lot to improve it. As Brad mentioned, good security is about raising the bar. Defeatism is not the right attitude.

piglet • March 15, 2005 7:10 PM

@Ari:
who claimed that “antivirus, antispyware or some other antiwhatever software would be some kind of a “magical” solution to fix security problems”? I don’t see anybody around. It is a good thing that we think and talk about security vulnerabilities. But I prefer careful analysis to “everything is broken anyway”-defeatism, and I suggest learning from experience. And experience doesn’t tell us that security
doesn’t work. Experience shows that some systems/protocols/approaches are less vulnerable than others, and I prefer to stick with the less vulnerable.

Filias Cupio • March 15, 2005 9:08 PM

The alternative-channel second factor authentication (text to cell phone) will work very well so long as it contains enough information for the user to verify it is correct: amount transfered, account number, account name.

Without thinking deeply about it, it seems to me that it would be more secure to have the user tranfer imformation between the channels. Consider a protocol where the user requests a transaction via the web, receives notification via phone text, and needs to reply via text to confirm.

Assuming we already have a trojan on the victim’s computer, we can steal their phone, and confirm the trojan’s transactions. Or if we can predict the required return text, we can send it at the appropriate time from a different phone (if necessary masqurading as the victim’s phone.) We can spoof their phon e to the cell network, and so we receive the text instead of them.

If they have to type in a PIN from the text into the computer, it becomes harder. Not only do we have to intercept the text (stolen or spoofed phone, or evesdrop if communication is unencrypted) but we have to relay this information to our trojan in a timely manner for it to pass on to the bank.

In any case, the phone-text second channel pretty much requires that the attacker be in the vicinity of the victim, to evesdrop or spoof*. This reduces the number of possible attackers by many orders of magnitude, and greatly increases their risk of being caught. This should be enough to keep the bank accounts of ordinary people secure.

  • Unless they’ve compromised the cell phone network, which is a hard target.

Dave Pacheco • March 15, 2005 11:12 PM

I think this article may be mis-titled: it should be “The Failure of Understanding of Two-Factor Authentication”, because what it is discussing at its core is the fact that two-factor is not the panacea it has been sold as for resolving the problem of inappropriate authentication (where I have access to your account/system under your security context, whether you’ve allowed me to or not). I simply do not buy that Mr. Schneier would believe that two-factor auth is a failure because it would force hackers to find other avenues of attack: in fact, by many definitions that is a form of success. At times the best we can hope for is to make their job harder, if only to buy ourselves a little time.

Putting the Club on your car doesn’t make your car impregnable, it just makes a car thief look at the next car down the block which doesn’t have one; sometimes that’s all you want (or are willing to spend money for). All we want in this case is that if one of the company executives accesses their web-based email from a Kinko’s public workstation with a handy malware keystroke-logger on it, the logger captures information that will be useless for an attacker to subsequently log in to that email account. That’s the problem I’m trying to solve with two-factor authentication, and I won’t try to solve phishing or social engineering attacks, and I won’t even attempt to solve bank account access with it, because that’s not what the solution is being designed for.

In a layered security model, and when used with a clear understanding of the scope of the problem it is trying to address, I think two-factor authentication presents a viable and (at least recently) affordable solution to this specific problem. It has “failings” only if you try to make it protect the components of the identity transaction that it was never supposed to protect, and for which there are other solutions that, in combination, reduce the total risk to a point where the business benefit is strong enough to make it acceptable.

That last point is one of the keys for the discussion comments here: no transaction of this sort is completely risk-free and secure. However, removing the capability to do business because I am so paranoid about security that I make it impossible to conduct the transaction is a self-induced Denial of Service with 100% risk potential.

max • March 16, 2005 3:32 AM

I am working in a swiss bank and two factor authentication is standard in switzerland since the start of e-banking . Bruce is correct stating that none of the authentication schemes protect against MITM or Trojan attacks.

But what is the point of his statements?
Should we forget about firewalls, virus scanners, IDS … just because we know that attackers eventually will find a way around them?
We are fighting a war against criminals.
Would a policeman drop his bullet-proof west in a dangerous situation, because he knows, that he might get shot anyway?
He wouldnt. He would ask for the best west that is available for him.
We are trying to build the authentication schemes that makes in as hard as possible for attackers to break.
If we can stop simple phishing attacks with dynamic two factor authentication, we keep low-skilled attackers out. Thats a good thing.
So far the attacks against swiss e-banks havent been very successful. Perhaps someone was able to steal 10000$.
If we manage to keep the costs for developing a MITM attack higher than that we have done a good job.
Strong authentication alone will not suffice but it helps us to achieve this.

Michael Silk • March 16, 2005 4:09 AM

I agree with most of the comments here; it’s a pretty sad attack on two-factor authorisation.

I mean, it’s your typically ‘multi-stage’ defense system: sure, viruses can still take over a computer, keyloggers can be installed, you can steal someones phone, you can force them with a gun to type in their password, etc, but each step is harder and preventable; discussable in it’s OWN right.

One solution (two-factor, client side ssl certs, alternate channel authorisation) doesn’t need to, nor should be DESIGNED, to solve these problems.

The problems of viruses need to be solved; but it can be done seperatly – don’t lump them all in one basket and say “bah, it’s all too hard!”.

It’s your typical threat-analysis method: analyse the problem, break it down, solve the individual problems.

Again, it’s really sad to see a lame attack as this come out from Bruce Schneier.

— Michael

Michael Silk • March 16, 2005 4:35 AM

Bruce: http://www.schneier.com/blog/archives/2004/11/twofactor_authe.html

Here is you, advocating the use of “Two factor” authentication by way of SMS’s. But yet in this article you disregard that exact system.

Can we trust anything you write?

—

Not to mention your comment: “Here are two new active attacks we’re starting to see […]
– Man-in-the-Middle attack.
– Trojan attack”

“Trojans” definately aren’t “New”.

This article seems inflamatory at best and doesn’t deserve any respect or basis in a real discussion about the future of security systems; analysing problems as a bunch (as you do here) is useless.

chris • March 16, 2005 4:57 AM

I think a greater emphasis needs to be placed upon the human element within the process. I agree with Max in that these systems, though not perfect, are built in order to make it as hard as possible for attackers to break, and have for the most part been successful – no security system is ever going to be fool proof outside of the lab, but what you can do is design systems that manage and control the risk to as high a degree as possible. Max’s figure of 10000$ loss from Swiss institutions highlights this. No the system has not been flawless, but if it protects against the greatest possible percentage of attacks then this is a bad day for the crackers and a good day for the banks.

But I believe the greater emphasis does indeed lies with the human element. YES it is important for system developers to continuously evolve their systems but as time passes too much emphasis is being passed to the system administration and away from the system user. A lot of systems are broken becuase the weakest link in the chain is the human, if the human element can be strengthened THEN the system administration can be held to account more fully for their role.

People have to (or should) accept that if you wish to be able to manage, for example, a 30000$ account and 2x 7500$ credit cards online (without you having to get up out of the chair and go down to you bank in person) that this ABILITY comes with a RESPONSIBILITY and a RISK.

On a personal level I’m more than happy to spend some time memorising a small ‘collection’ of data-sets that will allow me to access personal-only information remotely using a random combination of these as identification. By combining two or three of these pieces of ‘human-memory-only’ data I can identify myself. Couple this with MY responsibility to protect MY computer, the vast majority of fraud can be elimated from day-to-day experience.

What we have at present however is a continuing move of people transferring THEIR responsibility onto the banks and system administration. Personal responsibility is not a commodity that can traded to someone else. I believe that too many people would happily choose a system which has for them the least involvement. But such a system is never going to be trustable, in the same way as ID cards are a bad idea, because once you can forge this single ‘super-verifier’ you are trusted by the system. Social security or electronic transfer systems, it doesn’t matter, it’s a case of ‘trust status’ in regards a system.

M • March 16, 2005 6:37 AM

All,

IMHO some of you are missing the point. Bruce Schneier isn’t suggesting using OTP as the 2nd auth factor isn’t a good thing. He is just saying that, by todays attack standards, untrustworthy client software and people’s ignorance, this just isn’t ENOUGH and those that choose to implement it will not have a good return for their investment.

I think this article’s message is very important because there are several organizations ready to put a LOT of money into this gadgets and they’d better think how much time those millions will buy them.

Again, IMHO, there should be an effort to evaluate the signing capabilities of some of these devices.

— M

robert ivanc • March 16, 2005 7:45 AM

some of these tokens also allow data certification, so we can do the following:
use one-time auth. for entering into the system and then use data certification for the payments. the user needs to enter data that corresponds to the transaction – like account nr and amount and the token generates a response that the server can then check.

As far as I can tell, this is the only way that i could find so far that can defeat both the trojan and man in the middle attack? or am i mistaken?

However the problem is with the users – bank i’m working for feels that it is completely unrealistic to expect users to enter all this data into their token for every transaction.
so, we’re doing a compromise – data certification is done on a package level (multiple payments) and the user types in a hash of the xml data being certified. However in doing so, the trojan can still work its magic, since the user can’t easily determine if the hash corresponds to his data or not, so the trojan can submits its own data and get’s user to certify with token, while presenting on screen the data the user expects…

Davi Ottenheimer • March 16, 2005 10:03 AM

@M
No, actually none of us are missing the point. We are helping hone it into something more than “Oh no! Bruce says two-factor authentication is useless!

I, and probably many others, find it silly that such a weak and immflammatory-style of writing was used by Bruce to make his point. Maybe some like the idea of a Rush Limbaugh of security, but I prefer a more honest and reasoned, if not lighthearted, approach.

M • March 16, 2005 10:49 AM

Davi,

In my personal opinion, given that:

(a) the current attack vectors are immune to this protection because they either (1) use phishing sites and direct on-the-fly transactions or (2) don’t rely on stealing credentials but instead use the client’s active session (and believe me, I’ve seen it happening LIVE, e.g. BHOs that modify pages and posts on-the-fly);
(b) the cost for deploying the [most simple OTP] tokens is high;
(c) the inconvenience will lower the number of times the clients will access the sites.

Given these arguments, if I had to make a huge deployment TODAY for an Online Banking site, I wouldn’t put my money into it. It simply doesn’t pay (!).

If the first argument wasn’t true or if we can use the tokens for the transactions (in a usable way), then it might still be interesting. Otherwise, I do agree with Bruce and I say “In this specific context, two-factor authentication IS useless”.

— M

bp • March 16, 2005 1:25 PM

M,

Just because it’s possible to thwart a particular type of security doesn’t mean it’s useless. Before I’d be willing to concede that 2 factor authentication is useless, I’d need to be convinced that there’s a better way to prevent online banking fraud due to stolen passwords and other personal information. Even Bruce concedes that, in the short term, 2 factor would reduce the rates of online banking fraud.

I’d agree that cost, complexity, and user acceptance are big issues in deciding whether to deploy 2 factor authentication for consumer online banking. But tokens can be implemented in different ways (paper cards with printed OTPs, soft tokens on a computer’s hard drive, USB tokens) so there are many ways to deploy 2 factor authentication. Banks need to weigh these options and costs against the liklihood that 2 factor will be effective in the short term for significantly reducing fraud, and in the longer term that 2 factor can be enhanced to counter changing attack vectors.

What is unacceptable is to continue relying solely on passwords just because every alternative that might offer better security has a downside. If you or Bruce believe that 2 factor is useless for online banking, then what do you propose as an alternative? Should banks continue to rely only on passwords, even though everyone (?) concedes that passwords alone are weak security? Or do you believe (as Bruce apparently does) that banks will somehow invent some wonderful new security mechanisms once they get “motivated” due to becoming liable for fraudulent transactions?

cc • March 16, 2005 1:52 PM

Nothing will ever stop people from being stupid. There is no security defense in the face of stupidity and I doubt there ever will be. Institutions need to wake up and stop trying to protect people from themselves and let the individuals do it.

James • March 16, 2005 2:00 PM

I may have missed my answer in the other comments listed here but isn’t a man in the middle attack useless if the bank requires two factor auth?

Peter Iannarelli • March 16, 2005 2:20 PM

Mr. Schneier:

I fail to understand the correlation between a �Trojan attack� and Two-Factor Authentication. If the underlying security mechanisms of the operating system in question permits the covert installation and execution of a Trojan, wouldn�t that be a flaw within the operating system? And, Shouldn’t the problem be addressed as opposed to the symptom? Authentication ��Trojan attack�, so based on your statement, all authentication types are susceptible to a �Trojan attack�, it just depends on the Trojan.

With respect to the �Man-in-the-Middle attack�. Problem solved. As been for about two or three years now. Consider mutual authentication. First the server, (ie. The bank�s WEB site) authenticates to the user. Following successful authentication of that server to the user, the user authentications to the server. This is only practical when using a token that supports a machine to machine interface (i.e. smartcard, USB dongle token, etc�) It comes down to a �ease of use� issue. It can work with a hardware token but not the one you described in your article.

I believe you could not be further from the truth in your article. Firstly, there is a significant drop in fraud and identify theft when the technology in implemented and used correctly. Perhaps you should speak to some of the CTOs and CIOs of these financial institutions. Two-Factor, along with Two-Factor, Mutual-Authentication is just getting started.

Peter Iannarelli
Vice President Research & Development
CRYPTOCard Corporation

Dan DeBrito • March 16, 2005 2:20 PM

Here’s a potential solution against the man-in-the-middle and trojan:
Client logs into bank via two factor authentication. Prior to any major transaction, the bank replies with a code that encapsulates that transaction. The client user then runs that encapsulation number thru their RSA cards, cellphone or keyfob or whatever which generates an encrypted encapsulation number. The client user then returns the encrypted encapsulation number to the bank server.
Bank decrypts and verifies encapsulation number and completes the transaction if everthing is kosher. The man-in-the-middle or trojan may be able to surf around the clients account but can not complete any transactions.

Steve Wart • March 16, 2005 2:21 PM

Okay, this topic has got a lot of press, but not all two-factor authentication schemes are created equal. Blaming people for being stupid or blaming Microsoft for being, well, Microsoft, is not going to solve the problem.

Based on the glib descriptions I’ve seen, I would agree that the widespread RSA keychain dongle is vulnerable, but the technique used by some Swiss banks is not.

This article has been recently updated http://www.ubs.com/1/e/ubs_ch/authentication.html

lyap • March 16, 2005 2:34 PM

I think you want to take a look at the article’s last sentence: it’s second part does not logically follow from the first, somehow.

Shane Sanders • March 16, 2005 2:35 PM

It is well known fact that passwords aren’t enough to secure online electronic transactions. The most secure method would be two-channel authentication. (Performing the online transaction, then calling an automated system and verifying the transaction with a PIN within a certain amount of time, otherwise the transaction is rolled back). Obviously this would require more effort on the part of the user, thus lowering the user acceptance rate. I believe that individual institutions could offer this as an optional service and allow consumers to decide whether to use it. Let the individuals perform their own risk assessments. I, myself, would be happy to call an automated system, enter my account number and a PIN in order to authenticate any transaction. While the advantages of modern technology are endless, unfortunately so is the number of people with malicious intent.

Anonymous • March 16, 2005 3:19 PM

I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.

Most european banks are already using two factor authentication, be it with SMS, securID tokens or the challenge “calculators” in which you insert a smartcard.

Moreover, I recently attended a presentation by a big European bank. They showed that they are working on project where they use secure hardware connected to the PC. The device has a screen and a keyboard, and each transaction is displayed on the device’s screen and must be confirmed on the device’s keyboard. Of course, all the communications between the bank and the device are secured.

Andreas • March 16, 2005 3:22 PM

As far as I know all banks here in sweden uses two-factor auth. and has been since they started their online banking (1996 or so). My bank requires you to provide a token for each transaction and that token is based on the amount you want to transfer. It’s not perfect but it limits the options of a MiM.

Rob Pereyda • March 16, 2005 3:25 PM

Why don’t banks require the client to use a piece of custom software to log in…don’t even allow access via Firefox, IE, etc.

Hans Olsson • March 16, 2005 3:50 PM

I agree with serlu, that the 2 factor can be safe if the password is never entered on any computer and you authenticate transactions and not only the log-in procedure.

The last is important since by authenticating the transactions the man in the middle must replace parts of web-pages with other contents. (For the system used by my bank).

If the transaction had been safely shown on the key-pad it would have been safe. (Assuming good passwords and strong crypto.)

It would also be safe if it had used the SMS-authentication described at the start if the SMS actually contains the transaction to authenticate.
(Assuming no man-in-the-middle in the phone-system).

mls • March 16, 2005 4:49 PM

@Peter Iannarelli

How does mutual authentication eliminate a man in the middle attack? If the MiM proxies or relays the authentication response from the Bank’s server to the User’s client software, and likewise returns their credentials back to the server.

Steve • March 16, 2005 5:55 PM

This article makes an argument that is akin to saying cardiac defibrillators don’t save lives because they don’t protect against cancer: the point is their design is to help in cardiac arrest. Two factor authentication when used with certificated sites help do 1 thing which is to authenticate the site to the user and the user to the site. That is all they do, and it is still a very necessary part of security. As far as Man in the Middle and Phishing, they are mitigated by certificates and secure sites. As far as trojans are concerned, if we as users were more careful about the use of administrative accounts, this threat would be greatly reduced.

Matt • March 16, 2005 6:33 PM

For MiM, why not devise a protocol where each hop (router) on the way to the bank’s server is authenticated? That way, the authorized hops between the client and server would be able to terminate the connection before they passed data to an unauthorized host. I have no security background and I may be totally off base, but it seems DNS names & certs can be easily spoofed on the client, but not on every network hop, unless the hacker had his own network connected directly to the bank’s server and was able to spoof its own identity. Or we could just wait for quantum entanglement to guard against MiM attacks.

M • March 16, 2005 6:34 PM

Peter Iannarelli (and all the other folks 🙂 ),

You ask “…execution of a Trojan, wouldn’t that be a flaw within the operating system?”
And the answer is: Yes, it is. But for as long as it’s there we have to adapt to it. And guess what: the basic trust-the-client-computer problem will [probably] never go away. The only thing we can do is go on with our business despite of this. And, in my opinion, we have to bring the trust outside the computer. Does that mean 2-factor auth? If we can assure the transactions, the answer is YES. If we cannot, then it’s not worth it.

Regarding Mutual Authentication: We already have SSL to authenticate the remote site. So, what’s the problem then? People. If people understood the meaning of yellow lock we might be a little better. But again, if we can’t trust the computer we’re lost: something might be scrambling your input and displaying fake output.

Where do we stand then? Let me put the problem as I see it (the worst case scenario):

(a) We’re dealing with money here. Some bad people will try to move some cash from your account to their account. Directly or through fake company payments, or…
(b) They (the bad guys) control your computer or are listening and modifying your conversation with your bank. Both ways. They will push their account number as soon as you give them the chance. A transaction, maybe?
(c) You (the client) aren’t a decryption/encryption machine. So, you’re not going to read/write and decode/encode a complete session rubbish on the display/keyboard.

So what does this mean and what are the options?

(1) For as long as you use the computer for reading/writing you must assume the confidentiality is gone. Is there another way around? Only if you completely encrypt above this layer with some autonomous trusted machine that might make some use of the computer only for communications (if it was a bit more elaborate it might even drop the computer and use the RJ45 directly);
(2) Is there some way to cut the bad guys� account push? Is it usable (from the user perspective)? Will the cost be worth it? If we deploy it, will the evildoers loose their interest and move on (to another scam, maybe)? WELL, IMHO there is: As I wrote earlier, 2F auth (as it is being used) won’t do the trick BUT if we use it to “sign” a subset of the destination account (the last 4 digits perhaps?) and post the result with the account number THEN the dongles will be useful. Otherwise they won’t. I believe that If this is done, we�ll be rendering the attacks useless and other problems (like amounts, etc) will loose significance simply because no one will be loosing their time if they can�t get to the bucks.

Again, remember these conditions were used to setup the worst case scenario. Is it the most likely? No, of course not. If it was, we sure wouldn’t be online banking for quite some time now. And the probability game is what Banks have been playing. And winning. Will the odds change? I think they will and that�s why it�s important to secure the transactions.

Nuf said.

— M

piglet • March 16, 2005 7:14 PM

Bruce says: “Here are two new active attacks we’re starting to see:”
The two attacks, MITM faking the banking session to the user and maintaining its own session using the users credentials,
and a Trojan taking control of the banking session initiated by the legitimate user, are not conceptually new but may I ask whether we are really “starting to see” them? After an extensive web search, what I found is the e-Gold Trojan grams (http://www.lurhq.com/grams.html) and that’s it. And that attack didn’t work out, apparently because of a stupid bug. Too bad, implementing such an impressive scheme and then letting a stupid bug spoil everything. Haven’t those crackers heard about quality control? 😉

Anyway, I think it would be useful if this kind of discussion could rely a bit more on facts and figures instead of all that speculation. How many attacks of that type have really been observed and how effective were they? What security weaknesses did they exploit (what grams does with IE really shouldn’t be possible) Bruce seems to be saying that everything is possible with those attacks so thinking about authentication protocols is a waste of time. But is that true? I don’t think generalizations like that are helpful. I think we should spend some time analysing concrete examples. Many attacks (the grams Trojan once again) rely on the possibility to automatically fill out and submit a web form (in an invisible browser window). But this can be fixed with good old Turing numbers that have to be read and entered manually as part of the transaction.

So far, well-designed banking platforms with two-factor-authentication have proved to be effective and secure. Maybe new threats force them to develop new responses. But I certainly haven’t seen any evidence on this discussion page that would allow to conclude that two-factor-authentication has become ineffective.

Tim • March 16, 2005 9:09 PM

A device which has its own screen and keypad,
A device with its own hardware, to be incompatable with trojans [OBSCURITY!!],
A device which uses public-key cryptosystem keeping the decryption keys stored on the device and at the bank,
A device which encrypts those keys with a PIN,
The PIN which expires after three consecutive mistakes,
The PIN requiring to be changed every 3 months or so…
… could be defeated with a Video Camera and theft of device.

Other than that, it’d be rather good 🙂

NeilBrown • March 16, 2005 10:00 PM

I’ve read about authenticating at login to a bank, and authenticating each transaction, but what I would really like my bank to do is authenticate each relationship.

My banking transactions are to a very small number of recipients (a dozen or so). I have a relationship with each (my land lord, my electricity supplier, etc).

I don’t think it would be a big problem if someone broke into my bank and transferred extra money to my land lord as I’m sure I could get it back.

When I create a new relationship. i.e. give a new destination for money, I would really like that to require extra authentication. Maybe an email:

You have asked to create a new relationsip with XYZ Inc, 
using Cust. Number 1234 and with a
relationship cap of $300 per month.

If these details are correct, please
enter the code ABC123 into the authorisation 
box on the "Relationship" page of the
internet-banking web site.

It seems to me that this would be minimal inconvenience for substantial improved security.

If I was allowed to submit a GPG key which would cause that mail to arrive encrypted, so much the better.

chris • March 16, 2005 10:14 PM

It’s great that you’ve given us a synopsis of what’s wrong with two-factor authentication but, come on! If you can’t even suggest an alternative, how am I supposed to believe you know what you’re talking about.

Kevin Weir • March 16, 2005 10:44 PM

I agree with the author to a degree but he is missing the point.

Using two factor authentication, while not a security pancea, doesn’t make it any less imporant. Any opportunity to reduce the number of attack vectors is welcome.

Defense in depth!!

Regards
Kevin Weir

sv • March 16, 2005 11:47 PM

This is a lively discussion.. Can I make an observation. Internet banking is a service provided by banks. It’s based around four basic premises: Ease of use, Cost, Portability and risk. Each bank evaluates these factors with the view of getting the balance right. It’s not hard to make it much more secure and thereby reduce the risk, but that will affect cost, ease of use and portability. Thus a balance between the four has to be struck. This balance is now undergoing re-assesment by most banks towards reducing the risk. However as it affects other factors, it’s not a simple “just do it”. The best option is to provide a choice to users. Those who would like a full range of online bank services and transact high amounts may choose to use higher levels of security. Others who don’t use services that increase the riks of finanacial loss, plus don’t transact high amounts may not want a complicated security system.

Prasanna S Bidare • March 17, 2005 5:46 AM

Hi!

In my opinion, with the current technology one can make hack resistant systems but not totally secured systems. This means security process to be out sourced to competent and capable agencies. Who can make some ‘look ahead’ procedure to counter the attack.

Next, offering security per secession is the better process to be followed.
On the other hand let us also see the ‘multiple factors’ that are in hand like Web, Wi, Wi Max, Mobile and PoT, allow customer to ‘pick two factors’ out this while using their known TWO FACTORS too.

May be use of SSL with strong key management process under enterprise or banks control will offer better non repudiation control.

May be one should follow old �Churchill’s� policy of not using same path to commute twice in the near vicinity. This means security system need append the multiple choses !!!!

Simple to use but multiple system is better than strong single system.

Any comments on my two cents!!!

Marwijn • March 17, 2005 6:49 AM

Hello NeilBrown,

What you are suggesting is exactly what ABN-Amro in holland is using. I think it is fool proof with regards that nobody can wire money to an account that I have not given authorisation for. Viewing my private information like saldo etc. is a different Story.

rcme • March 17, 2005 9:07 AM

This is certainly a rather lively discussion!

In the end I think it comes back to the stance that Bruce is taking wrt two factor authentication. Which as I understand it, is that in the face of the specific attacks he mentions, active Man-in-the-Middle attacks (works by user not verifying server) and active Trojan attacks (works by user installing bad code), two factor authentication doesn’t provide a lot of additional value. With this I would have to agree.

He also proposes that in general, attacks are moving from passive (time shifted) methods to active (real time) methods, which is what makes them especially effective against two factor authentication. Again I would have to agree.

However, one has to take into consideration the “work factor” of moving from passive attacks to active attacks. I think that two factor authentication is a great technology that will overall increase security by “raising the bar”, forcing the attacks to get much more sophisticated (which will tend to filter out all but the most determined attackers).

@M
You ask “…execution of a Trojan, wouldn’t that be a flaw within the operating system?”
And the answer is: Yes, it is.

Not really. The operating system is just running a program the user put there. It generally doesn’t know “good” programs from “bad” programs. In fact, most OS’s, including Windows, provide users protection from installing programs unintentionally. For most activities, especially Internet oriented, users should never be logged in as a user with admin level privileges, but many (most) do. Why? Because many programs will not run properly unless the user is running with admin level privileges. This is not really a Microsoft OS problem, but a problem with the developers of these programs (what I call LPS, or Lazy Programmer Syndrome). Most programs that today require users to have admin level privileges, don’t really require admin level privileges to run, but due to LPS, they were written that way, which is just another part of the whole security problem.

@M
Regarding having the client digitally sign some part of the transaction, I agree that this can help with a Man-in-the-Middle attack (assuming the transaction isn’t setup such that the server sends data to be signed to the client), but nothing will help against a Trojan attack (where the Trojan can change the data to be signed without the user knowing it, could replace the user’s digital signature software, in part or in whole, completely replace the browser app, or whatever).

Anonymous • March 17, 2005 9:57 AM

RCME,

You say: “The operating system is just running a program the user put there”

and I continue: “or let itself in through a vulnerability and grabed a feature (like hooking the keyboard)”. And please, let’s not talk about common users doing maintenance. It just isn’t real. Either the system is selfhealing or, at least, we have to make [the core of] it as stateless as possible. (and one last point: let’s try to keep the core and the apps as simple as we can; there are some features that shouldn’t be there in the first place, e.g. Browser Helper Objects ?!? Come on…)

You say: (regarding sigs) “…nothing will help against a Trojan attack…”

I say: “…unless the Trojan doesn’t control the sig mechanism AND the user action doesn’t depend on some data from the Bank” I do concede that the last condition MAY be the killer. And I’m thinking in a scenario where the Trojan might induce the user to sign something that wasn’t really necessary and the user falling for it (even though the users might be aware that, say, they should only have to sign the … whatever). But when we get to this point we’re already performing without net.

One last thought: I truly think we should be putting more money on awareness. Big players have tried for years to keep the down side away from the news (to gather customers) but I think the time has come to educate people on the Do’s and Dont’s in an open way. In the end, it’s always on their side.

(and this has been a kool discussion 😉

— M

piglet • March 17, 2005 11:02 AM

@rcme: “He also proposes that in general, attacks are moving from passive (time shifted) methods to active (real time) methods, which is what makes them especially effective against two factor authentication. Again I would have to agree.”

What is the evidence for this claim? Do you know of several such “active attacks”, and how successful have they been? Again, I would like to see more facts and less speculation. I am not convinced that those real-time attacks are so feasible in practice, at least not without provoking suspicion (aborted transactions etc.)

I’m also not convinced that an attacker only has to fool the most stupid internet users. In Germany, the last wave of phishing and keylogging attacks wasn’t successful because the fraudulent transactions were detected early. At least this is what the banks are saying, which you may chose to believe or not.

piglet • March 17, 2005 11:25 AM

@NeilBrown & Marwijn: My Canadian bank, Desjardins, is doing something similar. For this reason I accept their internet platform even though I am not satisfied with their security (password only). First, they have a fixed list of businesses to which customers can make bill payments. This covers most of what most people need (like utilities) and is low-risk. Only recently, they added the feature to make payments to individual accounts (this could be the landlord). For authentification, the customer needs to enter date of birth and SSN, which is bad security. The feature has to be activated – they call back to verify – and can be deactivated. It’s not very flexible and user-friendly. But transfers to individual acounts seem to be rare in Canada, whereas in Germany, almost all money transfer is done by “Ueberweisung”. Thus, theGerman banks obviously had to care a lot more about securing transactions.

Davi Ottenheimer • March 17, 2005 12:12 PM

@piglet

http://www.guardian.co.uk/crime/article/0,2763,1439847,00.html

“Police have foiled an audacious attempt to steal ?220m from the London offices of a Japanese banking group, it emerged today.”

Nothing is said about how Police detected the attack, but apparently keyloggers and small fund transfers were picked up as anomalous, and the small transfers led to arrests. The article goes on to say:

“‘The rise of keyloggers poses a real threat to companies and this may be the first time we have evidence of organised criminals using the equipment to attack a bank,’ Alan MacDonagh, managing director of the fraud consultancy Hibis Europe told the Financial Times.”

piglet • March 17, 2005 4:01 PM

Interesting, but doesn’t seem to be related to internet transaction fraud. All the article says is that they used keyloggers to capture passwords and that the attack was detected – or at least suspicions were raised – quite early. It is regrettable that no more information is made available about how the attack was supposed to work and what security weaknesses were exploited. Of course, banks don’t want to see any of that published but it would be good for security if it were.

Curt Sampson • March 17, 2005 7:15 PM

I don’t think that two-factor authentication itself is the problem in the Internet banking case. The problem looks to me to be that you authenticate yourself once, and at that time you also obtain authorization for an unlimited number of any sort of transactions. As others have suggested above, if you use two-factor authentication to authorize individual transactions, the problem lessens. Essentially, what I’d like to see would be that any time a transfer from my account is requested, or a repeating transfer is created, I’d like to get an e-mail to my phone with a link to click on to authorize that transaction. So I’d initiate the tranasction on my PC, but complete it on my phone.

Robin Balean • March 18, 2005 12:02 AM

I have also been uncomfortable about man-in-the-middle attacks on two-factor authentication devices. However, I think your recent article on the subject was too quick to dismiss them, as they have evolved in recent times far beyond the simple OTP token.

For example, Vasco has a product which allows the user to enter data specific to a transaction which is combined with the OTP to create a hash for the transaction. A man-in-the-middle attack in this case would be confined to observation rather than using the OTP to authorise a different transaction from the one the user intended. Also, the phone-based second factor you mentioned in your article could be made to work if the message sent to the user displays the transaction that is being authorised along with a confirmation code. In this case, if an attacker had substituted a different transaction then the user would find out about it and would not send in the confirmation code – the attacker could not do it because they never get to see it (assuming the phone link is secure…). The real problem in this case is that SMS messaging is unreliable, so this type of scheme have never really got out of the pilot phase as far as I know.

Of course the complete solution is to use a client-authenticated SSL session instead of wasting time with tokens as this prevents a man in the middle from even getting in at the authentication stage. The costs of issuing and managing user certificates in a managed PKI solution are comparable to issuing OTP tokens.

Liam Tohms • March 18, 2005 3:18 AM

Two factor authentication is the new thing for ‘secure’ internet access, with banks / trading companies and Microsoft too touting this as the way forwards.

Except it isn’t workable.

Because people will be issued with a plethora of fobs to carry around which will become extremely inconvenient. I currently have 3 SecurID tokens and they are bulky to carry in a pocket. Users will NOT want to have to carry a fob for every service they want to use – they will return to less secure but more practical passwords.

One solution would be for a single fob to be registered to an individual and then used for authenticating against any number of services / companies… I haven’t made any assessment of the sharing of fob registration details between companies – is there a risk here? Or is there an impact on the fob vendor’s bottom line by selling only one fob rather than n to each individual and so this solution isn’t actively proposed.

Just Someone... • March 18, 2005 8:14 AM

RE two-factor authentication and online banking.

Postbank in the Netherlands has implemented a slightly different twist on the SMS scheme as an authentication form. SMS authentication is not required for logging in, but is required for confirming transactions.

A user defines one or more transactions, and when he is ready to send them he is asked for a confirmation code that is send to him as an SMS.
The SMS text contains a sequence number, the total amount to be transfered and the authentication code, this information is also displayed on the web site where the code is to be filled in.

This means gaining access to the site by the two means mentioned is not enough to illegaly perform transactions and (assuming the user checks the amount and the sequence number) hitchhiking on other transactions is not possible.

piglet • March 18, 2005 10:07 AM

“The problem looks to me to be that you authenticate yourself once, and at that time you also obtain authorization for an unlimited number of any sort of transactions.” (Curt Sampson)
Well, that is the wrong way to do it. My first internet banking experience in Germany back in the 90s involved authenticating every transaction with a TAN code, and I was surprised to learn later that there exist banks in the world that don’t have that level of security. Those of you who believe that “two factor authentication is the new thing for ‘secure’ internet access”, it’s time for you to realize that you have been fooled by your banks. They haven’t given you the security you deserve for your money.

Anonymous • March 19, 2005 11:37 PM

I recently came across a two factor ssl vpn called igate. It claims to prevent man in the middle attacks.

Alexander Hughes • March 20, 2005 12:56 PM

Two crucial elements seem to be missing from this argument: scope and solution path.

To the issue of scope: What are the relative frequencies of Man-in-the-Middle and Trojan attacks? How difficult is it to effectively mount such an attack? (Schneier implies that a high degree of skill would be required to successfully mirror the look and functionality of the spammed site; which, in turn, suggests a lower threat level.) The current argument has an alarmist tone because it fails to effectively scope the problem.

To the issue of a solution path, simply, So what? Every security measure has one or more counter measures. The purpose of security is not to make it impossible to break into something, but to limit the players capable of such a break-in. Does two-factor communication effectively limit the field of potential hackers? A guru should ask questions that make you think, and, critically, provide a degree of insight. Where’s the insight?

longtime_coder • March 22, 2005 1:04 AM

I apologize for the length of my comment in advance.

For years, I’ve been quietly observing and sometimes commenting (by way of casual conversation) on the changing face of technology and the progress of Information Security and the computing industry (or lack thereof.)

This is a great discussion because it invites opinions from all sides of the spectrum. Some more fierce than others.

Man-in-the-middle (MiM or MITM) attacks, while achievable, present more of a technical challenge to the would-be criminal. This is why trojan horses and security exploit tools have become the method of choice for compromising a system over the ‘net. Exploitations have become so pervasive, that it’s turned into a daily cat and mouse game to keep your system secure.

While there are a myriad of opinions regarding which authentication method is best suited for the task, I believe that the answer lies in combining the strengths of existing technologies in order to come up with a viable and relatively (and I stress relatively) fool-proof solution. Since financial institutions are governed by the “Safeguards Rule” implemented by the FTC, among a host of others, their systems have to adhere to strict guidelines regarding information security. That doesn’t mean they are completely immune, but at least there is a dedicated staff to address security issues at a moment’s notice.

With that being said, I believe the four keys to online transaction security consist of:

  • Secure infrastructure on the financial institution’s side or online retailer
    (Side note: Internal security incidents are on the rise and need to be addressed soon!)
  • Strong cryptographic cipher to curtail eavesdropping
  • Feasible and not-so-cumbersome authentication method (Note: A key ring full of fobs is not practical)
  • Secure interface on the client side

The latter of course being the biggest problem. In scrambling to implement stronger security, companies are pouring large capital assets into information security, much of which is past onto the consumer by way of higher fees and such.

To address the last issue on the list, I suggest that financial institutions and online retailers get together and develop a standalone bootable CD (Mac/PC friendly of course) using an agreed upon distribution of Linux. In doing so, the loop of security will be completed and safer transactions can take place. Granted, everything works great in theory but I think this would be a step in the right direction. Throw in the likes of a PIN/TAN system, and things would be pretty secure. IMHO of course!

Before people start bouncing off the walls, I am not a Linux evangelist. While I rarely use it, I have conducted quite a bit of research on it and commend the open source community for its efforts. The use of Linux is preferable because there are no licensing restrictions and the source code will be open to the general public for scrutiny. This solution would not be mandatory as the CD would merely provide a sanitized environment, and therefore be geared towards the average consumer. Since bootable “Live” CD’s do not affect the software installed on the user’s machine, it should be clearly stated on the label so consumers won’t think their data will be deleted by its use.

Distribution of such CD’s would have to be thought out carefully in order to prevent criminals from cloning the media and pawning it off as official. Social engineers would be hard at work trying to lure people in so consumer beware!

To tie it in with the article: The two-factor authentication method provides for added security, but isn’t the elusive “Silver Bullet”, which I think is the point of the article. Upon reading through the comments, it is obvious that some users are taking the conclusion with a grain of salt and cast it off as a synical view of the industry. I don’t share that opinion and applaud the efforts of security advocates that aim to shed light on the true state of information security.

Best of luck to us all!

ahoh • March 24, 2005 6:48 AM

After reading some of the comments I can not resist to drop my two cents:

My Bank is using PIN/TAN longer than they are using SSL (I used to use dial in and telnet sessions in the early 90s).

Since last year they offer authentication via smart card and they try to push it by subsidizing the reader (they recommend amongst others
http://www.reiner-sct.de/produkte/e-com.php ).

I would feel fully confident to use it,

  • Something I have (the smart card AND the certified reader)
  • Something I know (the PIN)
  • Something to verify what I am doing (the display on the reader)

BUT there is a trade off which keeps me from switching:

As the the system is soooo secure, I will have problems to shown that I HAVE NOT done the transaction in question, so it is safer for me to use the weaker system (provided I follow the terms and conditions).
I have as risk a reasonable fee (the costs of the rollback and the retention the insurance imposes) for the hint that my computer got hacked.

Al • December 13, 2005 2:33 PM

If you all think 2 factor is a flop you obviously have not looked into the tecnological innovation called KoolSpan
They finally came up with something that’s easy to use and even easier to install. If DISA and NSA can’t break it, it’s good enough for me. IPSEC and SSL move the heck over!!!

LeFreak • February 13, 2006 2:22 PM

I only remember here the sentence everybody should write in very large letters onto their foreheads: Security is a process and not a product.

No single technology will implement security in itself. Security does consist of processes and Bruce is fully right to say that 2-factor authentication alone is not the solution to all authentication and security issues.

Of course MiM Attacks are hard to achieve, especially if we also talk strong encryption, but honestly how many people would simply click OK if they get a certificate warning or how many people would not recognize the little padlock at the bottom of IE or other browsers at all? Problem is also not that processes are too complicated, too many etc. problem is the stupidity of the user to ignore common sense and processes because they cause maybe a little inconvinience, problem is also that security sometimes causes too much inconvinience and goes OTT, which then of course forces the user to attempt circumventing a security meassure to gain the convinience back. In case of 2-factor auth for example write the token PIN on the back of the token which renders it useless. And yes the missing interoperability of tokens from different vendors contributes to the Risk. Nobody wants to run around with a multitude of different tokens. I think in total 2 tokens must be enough to cover all authentication requests. One for OTP and one USB token or SC to cover any certificates. I will personally require both very soon for the majority of our users. The OTP token will be used for authentication of any system remotely and access to network equipment or admin access to any server, the SC or USB token will be for Pre-Boot authentication and to hold any encryptiing or signing certificate (for e-mail etc.). This is combined with an auto-lock that locks a users workstation as soon as they token is removed. Clue this to the building entry card and you force users also to lock the WS if they are not attended (one of the thorns in my sore eyes). Of course there are also systems out there that combine USB tokens and OTP in one device, but if you have USB ports only on the back of the machine this becomes a bit of a hassle, even though it would probably be fun to watch users trying to enter the OTP, but Health & Safety would kick us if we have every user complaining about a pain in the neck (in every tru meaning of the word).

Many times it’s also based on the fact that developers try to sell their lousy products as THE security solution for all problems (come on we all know the marketing talk of self protecting networks etc.). Again 2-factor authentication is only one little part of an overall security program, but it can never be the solution to all security problems. Same with ID Cards and biometrics…. Governments try to sell these as THE solution against ID Theft etc. however the Dutch system is already half way cracked as data can be freely read from up to 10 meters distance and it is only a question of time until it can also be freely written. And then we have governments that try to sell biometric ID cards but still allowing that somebody can say Joe Blogs when asked by police for the name instead of making the usage of false ID Data plain illegal. So it happened to me that somebody tried to get a credit card in my name (which was denied as the person did not have my secret password i implemented on my credit report). I went to the police just to hear that the plain attempt is not illegal and nothing can be done unless somebody nicked my money due to ID Theft.

Also please consider that Bruce said that 2-factor authentication is not the golden egg of security and not that 2-factor authentication is useless in all scenarios. I have to agree with Bruce that 2x auth is overhyped by banks etc. and is sold as the golden solution that will prevent all fraud simply by being implemented.

The same happens here with LloydsTSB who not too long ago changed from a simple password system (username/password) to a 3 step authentication that asks for a random pick of 3 characters of a predefined additional password. However now they allow that the username/ID can be saved on the browser (even if stating that it should not be done on PCs that are shared with multiple people, but how many people do ignore that…. over 80% as a wild guess), so effectively minimizing the entire system to a 2 step system again. Makes really sense and such nonsense should be illegal. Either I implement a 3-step authentication process or i don’t.

Even if we would implement biometric IDs on such accounts it would not help to 100% prevent any potential for fraudulent transactions, even not if we combine this with additional 2-factor authentication and statistical Intrusion Analysis (i.e. user makes more typos than normal or deviates from the normal pattern of site usage, such as usual the pattern for the user is to first check the account balance, then detailed statement, then transactions). Just because a attack technology today is not feasable to be exploited does not mean that it is not easily exploitable tomorrow, MiM in encrypted sessions included, and as said the old Granny in the flat above will certainly simply click yes if i am able to conduct a MiM and to gain access to the private key or a certificate…… well enough trojans out there take nowadays already care of that, then combined with weak passwords and voila we have a security breach. 15 years ago nobody talked about MiM attacks, nobody talked about 2-factor auth to be honest (except geeks and nerds). And what does stop any attacker from brute forcing his way into a password protected certificate? In most cases a brute force will only take minutes as people of course use well known dictionary words.

The SMS solution is certainly nice and tricks any attacker that works plainly on remote attacks and relies on information transfered, but what if somebody gets hold of the mobile (or the 2-factor token)?

2-factor is certainly not the solution of all problems, but it can make life for an opportunistic attacker very difficult if not impossible. But no matter what solution we select the protection will never stop a real determined attacker with enough resources and criminal energy at hand, except where he meets his match on the white hat side. And even then there is still enough potential for a security breach. Is Internetbanking therefore unsafe to use (Internetbanking just as an example as it was used so often here)? It is not more insecure than if you go personally to your bank or if you use an ATM, I personally prefer the Internet than ATMs, at least i know 99.9% for sure that nobody can look over my shoulder unless they can install a camera in the right place to watch my monitor and keyboard (please note this is my preference and not a statement about what is more secure. The ATM can have a skimmer installed, my PC can have a keylogger installed. The ATM has in most cases enough oportunities to be monitored by hidden cameras that cannot be detected, my house doesn’t offer this oportunity that easily and any attacker has it harder to hit me over the head and steal my card if i am in my flat).
And if somebody asks me what the best way to protect ones bank account i only remember at the times where one had to go to his/her branch to do anything. Staff at the bank knew each customer by name and if somebody would have tried to claim to be me they would have put a stop to it and called the cops. Is this nowadays still feasable in this fast paced world? No, of course not. We want globality and service availability around the clock This causes increased Risk, which can be mitigated by the use of 2-factor authentication, but once again it does not solve the problem, it only mitigates it.

And Bruce is also right with the comment about the ever changing face of security and threats. 10 years ago 2-factor authentication was better of an idea than sliced bread, but attacks have evolved and there are (even if many are theoretical for now) many ways around any authentication.
One example here is that users should not be allowed to install software, sure its fine and good and will prevent accidental user error, but if an attacker has physical access to a machine this is just a doddle to circumvent. On Unix simply boot into another OS and hack the passwd and shadow, on Windows use the Logon Bypass method to gain %SYSTEM%. And where this wouldn’t help because of some fancy new technology simply replace the authentication API to accept any password and you are done.
Or how about Disk Encryption with pre-boot authentication? Nothing except time restraints will prevent an attacker from going down the route of brute forcing. And what user has a true 128 bit Entropy? No system does allow a permanent lockout after x amount of failed attempts (at least none that is commercially viable), but then it would also not be very userfriendly or feasable to use a lockout without any provisioning of an Escrow procedure (which in turn could be brute forced again).

Just my 2p on security and that there is no 100% secure system. Maybe its because of human nature that there can’t be any 100% security. We seem to be somehow much better in finding ways around security than in creating security. You can watch a public place and cordon of a section that lies in the direct path between 2 points. It will take only minutes until people start to circumvent this security meassure. If we use tape it will happen faster, if we use temporary walls it is less likely. If you put up a 6″ fence it is less likely that people will climb it, but then watch it during night time when the pubs close and you will get all sorts of drunks and jokers climbing over the fence. If you put a few Rottweiler (not fed for a week or so) into the fenced area you still wil get the occasional idiot climbing over the fence regardless of the danger.

And where technology doesn’t help an attacker social engineering always does the trick. I claim that we run a good user education program with regards to password safety, and yet i just had two weeks ago a user with a problem and for troubleshooting i had to request a username and password for accessing a specific site. Instead of providing me with my own account the user simply sent me his details. After pointing (again) out that nobody must share their account details the answer i received was: I thought as you are the security manager and this is OK. My answer: Especially I as security manager should not get hold of any other account info. I know what I have to do in a non-trackable way to cause you a lot hassle in your life. All you will wonder about after being picked up by the police is what just happened there (and you will never understand). Then an explanation why this is legally not even an intrusion if the user shares willingly his password details (at least here in the UK it can’t be seen as an intrusion and any court would kick the case out), and then suddenly a very white face. And despite all this i guarantee that this user next time around will gladly tell us his password again if asked. Will 2-factor auth ever prevent this users stupidity? Never. Just call him and ask him for his PIN and the current displayed passcode.

This just as an example on how easy it is.

I think Bruce only wanted to point out the fact that 2-factor auth is hyped over the odds as solution for everything and that it will be THE solution to prevent all future security threats. It is not, never will be, never can be.

michael endrizzi • July 10, 2006 2:07 PM

Check out e-gold.com authentication. Simple, cheap, server based, stops MIM, client administrated, etc. Pet rock of authentication IMHO.

dreez

Want Feedback • November 17, 2006 5:32 AM

What about Keystroke Dynamics (Rhythm)? This seems to be a viable option that ties in what you are with what you know as a second factor. Consider script kiddies, phishing, social engineering all go away since the rhythm of a typer can’t be duplicated. The FAR is the same of biometric devices.

Santosh Rajan • February 6, 2007 1:52 AM

I do agree that it is very difficult to implement a two factor authentication system using digital certificates. But how are the people going to save their hard earned money without putting some effort of getting educated about the technology we professionals build.

I had implemented a similar solution last year for a large financial institution where we used digital certificates which were in turn embedded in smart cards and all certificates were X.500 v3 which is being supported by most products. We integrated the authentication system with SafeSign products which generates high quality challenge strings using a HSM. These strings were sent back to the client application which in turn digitally signs the challenge and submits back to the SafeSign application. The signature gets verified for integrity and the certificate is extracted from the signature and verified against the directory of the a commercial certifying authority using OCSP protocol. The authentication systems implemented at the CA end should be treated as the best in the present world. If verified the customer would be given an access to the resource.

Now the question is what if there is a MiM attack at the client application. Since the signature is generated on the smart card, there is no way he can manipulate the signature because we have embedded the public key in the hash before encrypting it with the private key. The attacker can make a copy of the signature but there is very little he can do with that. If he replaces his certificate in the PKCS 7 envelope, the signature would not match and also there is very small chance that the CA would issue duplicate certificates for him to impersonate the customer. There was a threat of the Smart Card PIN getting known to the attacker. We have encountered using the DH and AES algorithms implemented between the Graphical User Interface and the smart card service. The client and server communcation were using SSL protocol.

Well if the attacker can bypass all these things and get authenticated successfully then hats off to his knowledge.

Now comes about renewal and re-validation process. These can be resolved using a well thought business workflow which is to be done by the business analyst and well supported by us. We have integrated PKI solutions into Identity Minder concepts.

Brendan Bell • February 19, 2007 7:55 AM

As I am currently studying this topic as part of a university thesis what about the use of public key cryptography to provide the second authentication. at the moment this is just an idea i am playing with and i’m not sure if it has been implemented but the system i am invisioning would work in following way.

user registers with the system and provides the site with their public key. whenever the user wishes to access the system the system generates a random string, m , and encrypts it with the users public key (lets call it u(m)) and then encrypts this with the systems private key (giving s(u(m)) ) and sends this to the user (either though a separate client or through the browser itself) the user then decrypts this with the systems public key (which has been verified by a certificate authority to prove its actually the system they want) giving the user u(m) and then the user decrypts u(m) with their private key to give m1. the user then encrypts m with the systems public key giving s(m1) and sends this back to the system, the system then decrypts s(m1) with its private key to give m1 and compares m if they are both equal then the user is authenticated.

Apologies if the above seems long winded.
It is likely that i would design a piece of client software which would enable most/all of the users actions to be carried out automatically.

does the above sound like a plausible solution?

Juz • February 20, 2007 9:45 PM

I haven’t seen a single argument against the method currently being used by my bank (National Australia Bank). EVERY time i want to make a transfer to an external account, i am required to input a 7-digit code that has been sms’d to me via the bank. Given this code is different for every transfer I do, how will a hacker (without my mobile phone) ever be able to surpass this??

bandersnatch • February 28, 2007 10:16 AM

As to people clicking on certificates to view them as a security measure this is like asking a fake policeman for ID. The fake cop will present something, if they have half a brain, and a certificate will be accepted if it looks right

Most users, and I would guess all users with no background in security, myself included, could not tell the difference between a fake certificate and a real one and most citizens have no idea what a policemen’s ID card should look like, and certainly could not detect a reasonable forgery.

And of course if the reward is big enough the bad guys will just set up their own CA or, at less cost, use the BBC (Bribery,Blackmail and Coercion) on an existing CA’s employees.

relayer • March 4, 2007 8:53 AM

A solution that I have considered (but not deployed at this point) is to combine two technologies. Of course using any technology solution still requires that implementors be diligent in their focus on keeping their infrastructures secure, but I think they are hard to defeat with currently known methods.

1) Financial institutions should consider some type of application streaming technology so that users do not operate through a browser installed on their own machine. Both Citrix and Softricity(now Microsoft) have shown that this technology works well. Can a trojan still get in the middle of this? Well, maybe, but it would be very difficult to write, and easier for the institution or end user to detect.

2) Use a keystroke analytics technology to ensure that passwords are actually typed in by the person assigned the password. ie: http://www.biopassword.com

Anyway, as many others have said, these methods can be defeated, but the global population of individuals with the combined lack of character and skills to do this becomes much smaller each time we improve our technology.

RocketRon • June 18, 2007 1:52 PM

It seems like this subject has gone on for a while but the question is. How do we know the clients attaching are who they say they are? From the reverse angle. How does a client know a service is who they claim to be?
Mutual authentication is key!
Two factor is something you know and something you have. It is up to user to hold safe the something you know. It is up to IT systems to ensure authenticity of something you have. The problem with a simple token system the item passed to another user can still function. Therefore criteria of functionality must be specified as strict as the system requires.
Remember a web page that is viewable by everyone is hackable by anyone.
Is web based security really secure? Would Fort Knox be so secure if everyone could walk up to the front door and have a go?
Biopassword seems neat but what if you have an injury or are getting distracted.
If a user has been to the same touch type school would they pick up similar patterns?
Anyhow this seems to bolt onto the ever increasing arsenal of product used to maintain a evermore porous firewall.
Consumerisation is a trend that is adding ever more pressure to let more application through to the network.
We need to dump the old system and think up a new structure for network security otherwise we are doomed to addon and spendmore.

Nick • January 3, 2008 12:53 PM

It seems that two factor authentication with a two-way SMS message would work. A number sent to the phone must be typed into the computer, and a number shown on the computer must be typed into the phone and sent as a reply to the SMS.

This would ensure both the phone and computer are in use by one person, as well as mitigate any threat from Keylogger software.

This assumes that the message sent from the phone can’t be spoofed – I’m not sure if an attacker changing his caller ID would be able to get around that.

Dom • January 13, 2008 9:54 PM

Just a thought: RSA has tokens that are also USB flash disks. If you were issued a read-only version from the bank, which contains online banking software (possibly running in virtualised/isolated environment) and a client certificate, surely this would resolve the issue with unsecured browsers, because only the trusted token would be able to establish a connection to the bank, eliminating MiM attacks.

When logging on, users would provide their username and password as normal, but the number on the token would have to be entered by clicking with the mouse on numbers that would appear at random locations on the screen, hopefully bypassing keyloggers.

This may add complexity for end users (and possibly create other headaches for the bank), but would improve security.

Any thoughts???

Rhyre417 • March 21, 2008 4:56 PM

Perfect security is not feasible. Like a good cryptosystem, you just want to increase the amount of work that the attacker has to do, until there is no longer an economic incentive. When only Bill Gates, Donald Trump, and George Soros have to worry about ID theft, that’s good enough.

Right now, it’s easy to do phishing and MiM because people are trusting of what they get via insecured e-mails. You can certainly deploy a more paranoid browser, but until the web servers also get more paranoid, and check for browser certs, there’s not much hope.

Banks could send a set of one-time-use keys on a flash drive, since most computers have USB. The FSF has a “Privacy Key” the provide new members.

If the two-factor devices only cost $5, banks can use them as inducements to open accounts with them.

JT • June 3, 2008 9:19 PM

You need to understand that different people have different requirements that two-factor authentication can solve for them. If you think of using two-factor authentication in a corporate environment desktop machines are locked down tightly with employees having no administrative rights.
Two-factor authentication shines here as your password management has now become a lot simpler. Employees do not have to remember an abundance of passwords, and you can also install certificates on devices like smart cards or smart tokens to enable digital certificates and e-mail encryption. Not to mention the benefits of implementing Single Sign On for the abundance of devices, servers, and web applications you need to log onto.

I would prefer to see a write up of the failure of passwords and hello Two factor authentication.

Anonymous • June 13, 2008 4:48 AM

We can generate a new dynamic web page for every request from the client and delete the already existing page and assigns a URL to that page at the same time generate a random pasword which he has to enter on to that page and sends that URL and password onto the mobile device of that user, The user on receiving the SMS has to enter that URL in his browser and the browser will open that page if he is connected to the actual serverbecause the required page is present on the actual server onlyand if he is connected to the proxy server the server cannot have that page and will send a request not found reply thus defeating phishing attack. Once that page is open he can enter the password and gain access of the system.
If it still can be breakable you please tell me how it can be.

Chris Hills • June 13, 2008 6:32 AM

My bank has introduced a system using two-factor authentication for logging onto its internet banking site, as well as sending funds.

In order to send funds, I am given a code to enter into a security device with a keypad, display and card reader. In combination with my (chipped) bank card, it generates a response code. The beauty of this system is that the authentication (question) code contains digits of the recipients bank account number, so if the numbers do not match up it is evident that an attack is being attempted.

Mario Finetti • August 14, 2008 11:36 AM

Dear All,

Let us suppose to provide our users with a USB token equipped with a LCD display and an “OK” button.

Before performing fund transfers of any kind, the application is required to generate a simple message containing a summary of the operation being authorized. The message is transferred to the USB token that will show it on the LCD display. The user is then asked to check the message and press the “OK” button on the USB token if he agrees to authorize that operation.

When the user confirms the operation, the USB token electronically signs the message and gives it back to the Web application. As far as the USB token is a trusted environment, the entire process is secure, even if user’s client computer is not trusted.

Theoretically, instead of the USB token, we could provide our users with a sheet of paper containing a simple table of “transaction confirmation codes”. In order to authorize the transaction, the user would be asked to enter the confirmation code found at the cross of the “transaction ID” row and the “transaction amount ($)” column.

Please follow the link below for more details on this proposal: http://www.scmagazineuk.com/Web-application-security-in-un-trusted-client-scenarios/article/110448/

Thank you for your attention and best regards,
Mario

dlt • February 11, 2009 4:11 PM

I know I’m coming into this long after the conversation has probably died but here goes.

People in general will favor convenience over security. A system that is too complicated is not widely accepted until it is a standard way of life.

I think Bruce’s point rings clear still today if not louder than ever, two-factor authentication is not a savior. Security in layers and done with diligence is the key. In many scenarios I have seen the cost of protecting an asset exceeding the value of the asset. This is not good security. It is simply just throwing money at a problem only to learn it will require more money later as risk changes.

Clive Robinson • February 11, 2009 6:11 PM

@ dlt,

“In many scenarios I have seen the cost of protecting an asset exceeding the value of the asset. This is not good security.”

Unfortunatly if is very often difficult to judge the value of an asset, especially when it is not a physical item but information. It is worse when the asset being protected has low value in of it’s self but can confer an unknown high value (such as an SMS confirming a funds transfer).

The solution is to step back from the problem and work out what you are currently doing and what you should realy be doing.

In the case of online banking what you need is not n-factor authentication of the users but two way authentication of the transaction.

This should be via a shared secret and out of channel secure authentication bassed on the key factors of the transaction including time.

The authentication using the transaction key factors prevents them being modified by a MITM attack, and the use of out of channel secure authentication prevents false display of transaction details by trojan etc. Finally the two way authentication assures both users that they are seeing and agreeing the same transaction.

However for some transactions this will effectivly be more expensive than the transaction is worth, but for others it will be a very small price in comparison to an individual transaction.

longshadow • June 17, 2009 3:16 PM

Two way authentication, as described above, doesn’t solve the problem.

Modern malware (Zeus being a great example) captures keystrokes from virtual and physical keyboards, the transmitted data, and it takes screen shots of the infected host. version 2 can do more things (like search the host for specific data) but for the point of this conversation, everything that is stored or transmitted from the infected host is available to the malware operator.

Once they capture your user ID, Password, and Shared Secret, they can simply establish their own session with the server and run their transaction scripts.

The only thing that a traditional Two Factor Authentication solution really gives you is some perimeter security (meaning the captured ID & Password won’t give an attacker what he needs to establish a vpn connection into the targets corporate network) and it gives you some audit logs that you don’t get with some out of the box vpn solutions (like Citrix Access Gateway)

Him • July 12, 2009 1:22 PM

You didnt state anything wrong with the technology! Yopu just said that viruses could disrupt the use of this product. Even if you are only mildly familar with computers you can stop virues with a decent anti virus product. Viruses are so easy to stop. Come on! Think up a better arguement.

otmar • September 22, 2009 11:07 AM

The SMS technique as described by Bruce isn’t what has been deployed by all major Austrian bank over the last two years:

Here, the SMS contains the transaction details and a TAN code that the user need to enter on the web which can only unlock just that transaction as seen on the SMS.

As long as the users check if the info in the SMS is correct, no man-in-the-browser (zeus ..) can break this scheme.

What this basically gives you over any simple smart-card solution is the display on the trusted device (or at least a second device) that the malware can’t deceive.

Where this scheme might break down is on smartphones, where you combine the webbrowser and the cell phone in a single (potentially vulnerable) device.

Phishers have all but given up on Austrian banks (for now).

s000 • December 24, 2009 2:53 AM

A company is having problems with its password security systems and decides to implement two factor authentication. What biometric alternatives could the company employ? What are some of the factors it should consider when decideing among the alternatives?

Clive Robinson • December 24, 2009 6:05 AM

@ s000,

“What biometric alternatives could the company employ? What are some of the factors it should consider when decideing among the alternatives?”

The first question you should ask is what does biometrics in general get me and for what price.

Or to put it another way they are generaly costly unreliable and have way to many false indicators (both positive and negative) for a general purpose system with more than a handfull of employees.

Then if you still want Bio-metrics consider those that are not contentious with users. Fingerprint and Retina scans are deamed by many as to intrusive (they also have maintanence and health issues respectivly).

Then consider what your fall back options are and what they are likley to cost.

For instance a hand geometry device is not going to be a lot of use to some disabled or temporarily incapacitated person (think RSI supports and plaster casts etc etc).

As a general rule of thumb bio-metrics are not the answer to authentication systems due to numerous issues that are not considered by the system designers.

There is of course one aspect to them that is almost invariably ignored. You cann’t change an individuals bio-metric easily (or at all) without harm.

Further bio-metrics are equivalent of PII of “data subjects” which brings a whole heap of other legal issues etc crashing down around the system depending on where you are in the world.

I would seriously take a long hard look at the alternatives first and decide why they are not acceptable prior to thinking about bio-metrics.

Then look at the down sides and decide what your liabilities are and how to mitigate them.

Then how you are going to mitigate people who have no or poor biometrics. And what you do when your chosen biometric fails due to injury etc.

Then how you are going to deal with maintanence and health issues relating to the biometric.

Then…

AvgJoe • August 12, 2010 3:47 PM

Thanks for pointing out the potential flaws; now, what are possible solutions? It’s easy to find fault, now try proposing a solution.

Until somebody builds a better mousetrap, these two-factor auth methods are all we have to rely on and they still help me sleep better. Besides, we all know the biggest threat is the one from the inside, from which there are even fewer courses of action.

Clive Robinson • August 13, 2010 11:46 PM

@ AvgJoe,

“… now what are possible solutions? It’s easy to find fault now try proposing a solution”

I came up with a solution back in the 1990’s to some of the issues (and have posted about it on Bruce’s blog a number of times in the past).

However you have to remember that many of the organisations using very weak systems have many many customers and they don’t want to be spending the money…

So instead as we have seen they go for a low cost system which is almost invariably weak in the way it is implemented by them. And as they know the system is weak and has more holes than a second hand string vest they also have a set of non negotiable rules that externalise the risk back onto the customer or the merchant or who ever as long as it’s not them picking up the tab.

Untill this cost-risk issue is solved the situation will not change irrespective of how cheap or effective any given solution is….

james • March 8, 2012 9:40 PM

everytime when the customer choose to make any purchase of any item online (when using credit card payment) the website will redirect to the bank website and a msg is send to the customer the customer may need to type in the code given by the bank + the password inorder to buy the item , unless the attacker has the customer’s cell phone or else it is not possible for him to compromise the customer’s account.

Peter E Retep • March 8, 2012 10:46 PM

As long as you believe this is enough, you are a sheep to be shorn.

The odds against you having a birthday which is the same date
as a stranger born in a leap year are 1/366;
but in a classroom of 23
there is even money that
two persons have the same birthdate.

A battering ball hurled by a trebouchet
would almost never succeed in hitting
a particular stone in a castle’s wall,
but it would hit any number of stones,
and knock them loose.

Ivan • April 19, 2012 8:43 AM

The bank can send you a text notifying you of every transaction, and put the transaction on hold for a few hours, in which you have some way to cancel the transaction if you find it suspicious. If the transaction is legitimate, you don’t need to do anything.

This works as long as the attacker doesn’t have access to your cell phone as well as your password, and as long as it is not easy to change your phone number through the web interface.

Clive Robinson • July 8, 2012 9:37 AM

Hmm, looking back on the comments made over they years on this post tells an interesting tale.

I advised against using SMS some years before for a number of reasons (mainly because it is “an unreliable service” and spoofable on smart phones) and low and behold the attackers found another way around them which was to “call the phone company and tell them the phone was lost/broken and transfere the service to another phone”.

It’s obviouss with hindsight but as usual it was a weakness in the system that was not thought about and used a simple fact of “non aligned interests” between the phone service provider and the banks leveraging the phone service for something it was never designed for.

I’ve always said (for basic liabilty reasons) that the solution should be provided by one of the two interested parties with vested interests (ie the bank, as the bank probably won’t trust a customer solution no matter what the advantages).

I’ve also said the solution should authenticate the transaction not the users at the start of communications (ie to limit MiTM attacks).

But also and more importantly the authentication process shouls put the customer in the loop and not alow modifications to the PC at any level to alow an “end run” around the security.

The implication of this is of course a side channel device (token) that is supplied by the bank and is not connected to the computer in any way and is preferably immutable so it cannot have malware put on it. So far such implementations are at best rare, so have not yet been considered by attackers in any great depth yet.

It will be interesting to see if they can think of ways around a properly implemented version…

I guess time will tell 😉

David • June 11, 2013 10:49 AM

I’ve heard that there is something called igate which apparently stops man in the middle attacks in their tracks. It’s what’s known as a two factor SSL VPN.

Jason • October 26, 2015 10:54 AM

This is a great cautionary tale on the need for defense in depth. There are many ways to break into a system and you can’t just watch one of the doors to the castle. I still would argue that two-factor is not useless since guessing/stealing passwords is rampant. Either by eavesdropping or stealing a hashed password database and brute-forcing the passwords. This is particularly damaging since users tend to re-use the same passwords over and over again on multiple sites. Having a second factor greatly reduces the likelihood that this type of break-in will succeed. I have blogged about this here.

bigdaddy • March 10, 2016 12:37 PM

You’re an idiot. You’re essentially saying two factor authentication doesn’t solve any problem because people are stupid. No, you are stupid. It does certainly add an additional layer of protection not afforded by un/pw alone. That’s like saying, don’t bother to secure your account with a password because you will be stupid enough to give it to someone anyway.

C U Anon • March 10, 2016 5:41 PM

@Bigdady

You’re an idiot.

This blog page was posted eleven years ago and has one hundred and twenty five comments.

It would help if you actually said who you thought was being idiotic/stupid, wouldn’t it?

You’re essentially saying two factor authentication doesn’t solve any problem because people are stupid.

If you are saying that about the actual post by the host at the top of the page, then it’s fairly clear you have not read it correctly or have chosen to misconstrue it.

It’s fairly clear that the problem being identified is either a “Man In The Middle” (MITM) or a malware attack because of the use of an insecure network (Internet).

Have another read of the post and then be a little thoughtfull how you post your next comment.

bil • March 21, 2016 3:18 PM

i am speaking from ignorance. so please be patient with me.

what would happen if all keyboard output is sent to ram which is hardwired to be read only to the rest of the world (services,software etc)

this approach would allow a comparison to be always made between a software generated command vs a hardware generated command.

so…for critical transactions, involving an ignorant user….part of the protocol of that transaction would be to look at the critical transaction command comparison and if the command did not originate from the keyboard, the transaction is terminated.

any thoughts?

Mike Scott • August 5, 2016 8:27 AM

It seems worth pointing out that U2F 2FA devices solve some of these problems (while admittedly introducing others, of which the main one at present is that they only work using Chrome or Firefox on a computer, not a tablet or phone). Because the authentication is site-specific, the credentials that are provided by the key to a phishing site or an MitM attacker will not work when the attacker passes them through to the real site. It’s still no defence against a Trojan taking control of your computer, of course (except that the attacker will have to wait for you to actually push the button and log in to perform the activity that you want to compromise).

Ano • September 26, 2016 9:44 AM

Sorry but that’s bit too easy: The author is just complaining about something without naming better alternatives / proposals.

//Chris • June 21, 2017 3:26 PM

NeilBrown
I think that this is the way its implemented everywhere in EU certainly in Sweden Norway and Finland, since the Internet started to cook, so mid 90:s when online bangking was introduced, it was done this way allready back then.

Everything you do with the bank is a “transaction”, and needs to be authenticated
Adding new recipients, paying a bill, they all require separate authorisations, as an european i find this funny, are you over there living in the stoneage 🙂
And ofcourse the login needs an authentication, they are 2 different things and 2 different algorithms.
Its made as a challenge response, that also require your pinnumber and your smartcard. Or a Calculator Device that is unique to your identity.
These are the variants i have see in the Nordic countries.

So you login, it gives you random number, you turn on our device
enter the pinnumber so the device is turnod on, and choose if you are doing
an authentication or an authorisation, then you enter the digits in to the device
and it gives a long number back, that you then enter into the webpage

And all things that you then do when you are logged in, needless to what it might be, needs to be separately auhtorized, with the same method…

//Chris

Beny Freshfeet • November 3, 2017 4:35 PM

That is good the author and other commenters say that two factor authorization is still useful. And as far as the Man In The Middle (MITM) and Trojan attacks anti-malware programs have advanced a lot since the this article came out. I am pretty confident that my paid anti-malware program prevents these kinds of attacks because it claims a lot that it does, and there are separate togglable functions for them, so hopefully for these kinds of attacks people can get a good anti-malware program.

Hana • July 17, 2020 5:36 AM

That is good the author and other commenters say that two factor authorization is still useful. And as far as the Man In The Middle (MITM) and Trojan attacks anti-malware programs have advanced a lot since the this article came out.

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.