Entries Tagged "phishing"
Page 10 of 10
So, say your bank uses a username and password to login to your account. Conventional wisdom (?) says that you need to prevent the bad guys from stealing your username and password, right? WRONG! What you are trying to prevent is the bad guys STEALING YOUR MONEY. This distinction is very important. If you have an account with $0 dollars in it, which you never use, what does it matter if someone knows the access details? Your username and password are only valuable insofar as the bank allows anyone who knows them to take your money. And therein lies the REAL problem. The bank is too lazy (or incompetent) to do what Bruce Schneier describes as “authenticate the transaction, not the person”. While it is incredibly difficult to prevent the bad guys from stealing access credentials (especially with browsers like Internet Explorer around), it is actually much simpler to prevent your money disappearing off to some foreign country….
When something goes wrong, the bank will tell you that you “authorised” the transaction, where in fact the party who ultimately “authorised” it is the bank, based on the information they chose to take as evidence that this transaction is the genuine desire of a legitimate customer.
The essay provides some recommendations as well.
- Restrict IP addresses outside Australia
- Restrict odd times of day (or at least be more vigilant)
- Set cookies to identify machines
- Record IP usually used
- Record times of day usually accessed
- Record days of week/month
- Send emails when suspicious activity is detected
- Lock accounts when fraud is suspected
- Introduce a delay in transfers out—for suspicious amounts, longer
- Make care proportional to risk
- Define risk relative to customer, not bank
These are good ideas, but need more refinement in the specifics. But they’re a great start, and banks would do well to pay attention to them.
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.
The Unicode community is working on fixing the security vulnerabilities I talked about here and here. They have a draft technical report that they’re looking for comments on. A solution to these security problems will take some concerted efforts, since there are many different kinds of issues involved. (In some ways, the “paypal.com” hack is one of the simpler cases.)
A long time ago I wrote about the security risks of Unicode. This is an example of the problem.
Here’s a demo: it’s a Web page that appears to be www.paypal.com but is not PayPal. Everything from the address bar to the hover-over status on the link says www.paypal.com.
It works by substituting a Unicode character for the second “a” in PayPal. That Unicode character happens to look like an English “a,” but it’s not an “a.” The attack works even under SSL.
Here’s the source code of the link: http://www.p&#1072;ypal.com/
From an alert reader:
I don’t know whether to tell you, or RISKS, or the cops, but I just received an automated call on my cellphone that asked for the last four digits of my Social Security number. The script went:
Hello! This is not a solicitation! We have an important message for J-O-H-N DOE (my first name was spelled out, but the last name was pronounced). If this is J-O-H-N Doe, Press 1 now!
(after pressing 1:)
For your security, please enter the last four digits of your Social Security Number!
I have no idea who it was, because I’ll be—damned—if I’d give out ANY digits of my SSN to an unidentified party. My cell’s display is broken so I’m not sure whether there was any caller ID information on it, but I also know that can be forged. What company expects its customers to give up critical data like that during an unidentified, unsolicited call?
Sadly, there probably are well-meaning people writing automatic telephone scripts that ask this sort of question. But this could very well be a phishing scheme: someone trying to trick the listener into divulging personal information.
In general, my advice is to not divulge this sort of information when you are called. There’s simply no way to verify who the caller is. Far safer is for you to make the call.
For example, I regularly receive calls from the anti-fraud division of my credit card company checking up on particular charges. I always hang up on them and call them back, using the phone number on the back of my card. That gives me more confidence that I’m speaking to a legitimate representative of my credit card company.
Sidebar photo of Bruce Schneier by Joe MacInnis.