Entries Tagged "phishing"

Page 10 of 11

Impressive Phishing Attack

Read about it here, or in even more detail.

I find this phishing attack impressive for several reasons. One, it’s a very sophisticated attack and demonstrates how clever identity thieves are becoming. Two, it narrowly targets a particular credit union, and sneakily uses the fact that credit cards issued by an institution share the same initial digits. Three, it exploits an authentication problem with SSL certificates. And four, it is yet another proof point that “user education” isn’t how we’re going to solve this kind of risk.

Posted on February 22, 2006 at 7:41 AM • View Comments

Petnames

Interesting paper:

Zooko’s Triangle argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.

Though no single name can have all three properties, the petname system does indeed embody all three properties. Informal experiments with petname-like systems suggest that petnames can be both intuitive and effective. Experimental implementations already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.

Posted on February 8, 2006 at 11:25 AM • View Comments

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

1 … 8 9 10 11

Sidebar photo of Bruce Schneier by Joe MacInnis.