Entries Tagged "phishing"

Page 10 of 10

New Phishing Trick

Although I think I’ve seen the trick before:

Phishing schemes are all about deception, and recently some clever phishers have added a new layer of subterfuge called the secure phish. It uses the padlock icon indicating that your browser has established a secure connection to a Web site to lull you into a false sense of security. According to Internet security company SurfControl, phishers have begun to outfit their counterfeit sites with self-generated Secure Sockets Layer certificates. To distinguish an imposter from the genuine article, you should carefully scan the security certificate prompt for a reference to either “a self-issued certificate” or “an unknown certificate authority.”

Yeah, like anyone is going to do that.

Posted on December 1, 2005 at 7:43 AM • View Comments

Scandinavian Attack Against Two-Factor Authentication

I’ve repeatedly said that two-factor authentication won’t stop phishing, because the attackers will simply modify their techniques to get around it. Here’s an example where that has happened:

Scandinavian bank Nordea was forced to shut down part of its Web banking service for 12 hours last week following a phishing attack that specifically targeted its paper-based one-time password security system.

According to press reports, the scam targeted customers that access the Nordea Sweden Web banking site using a paper-based single-use password security system.

A blog posting by Finnish security firm F-Secure says recipients of the spam e-mail were directed to bogus Web sites but were also asked to enter their account details along with the next password on their list of one-time passwords issued to them by the bank on a “scratch sheet”.

From F-Secure’s blog:

The fake mails were explaining that Nordea is introducing new security measures, which can be accessed at www.nordea-se.com or www.nordea-bank.net (fake sites hosted in South Korea).

The fake sites looked fairly real. They were asking the user for his personal number, access code and the next available scratch code. Regardless of what you entered, the site would complain about the scratch code and asked you to try the next one. In reality the bad boys were trying to collect several scratch codes for their own use.

The Register also has a story.

Two-factor authentication won’t stop identity theft, because identity theft is not an authentication problem. It’s a transaction-security problem. I’ve written about that already. Solutions need to address the transactions directly, and my guess is that they’ll be a combination of things. Some transactions will become more cumbersome. It will definitely be more cumbersome to get a new credit card. Back-end systems will be put in place to identify fraudulent transaction patterns. Look at credit card security; that’s where you’re going to find ideas for solutions to this problem.

Unfortunately, until financial institutions are liable for all the losses associated with identity theft, and not just their direct losses, we’re not going to see a lot of these solutions. I’ve written about this before as well.

We got them for credit cards because Congress mandated that the banks were liable for all but the first $50 of fraudulent transactions.

EDITED TO ADD: Here’s a related story. The Bank of New Zealand suspended Internet banking because of phishing concerns. Now there’s a company that is taking the threat seriously.

Posted on October 25, 2005 at 12:49 PM • View Comments

Phishing

My third Wired column is on line. It’s about phishing.

Financial companies have until now avoided taking on phishers in a serious way, because it’s cheaper and simpler to pay the costs of fraud. That’s unacceptable, however, because consumers who fall prey to these scams pay a price that goes beyond financial losses, in inconvenience, stress and, in some cases, blots on their credit reports that are hard to eradicate. As a result, lawmakers need to do more than create new punishments for wrongdoers—they need to create tough new incentives that will effectively force financial companies to change the status quo and improve the way they protect their customers’ assets.

EDITED TO ADD: There’s a discussion on Slashdot.

Posted on October 6, 2005 at 8:10 AM • View Comments

Phishing and Identity Theft

I’ve already written about identity theft, and have said that the real problem is fraudulent transactions. This essay says much the same thing:

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.

Posted on May 10, 2005 at 4:24 PM • View Comments

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.

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

Fixing Unicode

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.)

Posted on March 13, 2005 at 9:31 AM • View Comments

Unicode URL Hack

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&amp#1072;ypal.com/

Secuna has some information on how to fix this vulnerability. So does BoingBoing.

Posted on February 16, 2005 at 9:17 AM • View Comments

Phishing by Cell Phone

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.

Posted on December 7, 2004 at 1:58 PM • View Comments

1 … 8 9 10

Sidebar photo of Bruce Schneier by Joe MacInnis.