« Cynthia Kuo, Sasha Romanosky, and Lorrie Faith Cranor: Human Selection of Mnemonic Phrase-Based Passwords
Julie S. Downs, Mandy Holbrook, and Lorrie Faith Cranor: Decision Strategies and Susceptibility to Phishing »

Ka-Ping Yee, Jeff Nelson, Rob Franco, Diana Smetters: Phishing: How will the scourge really be killed? (Panel)

July 13, 2006 by Moira

Read the abstract here.

Ping: Users must know whom they’re talking to

Phishing is a masquerade where who you’re talking to is not who you think you’re talking to.  But your computer can’t read your mind and it can’t prevent you from talking to someone, so the best solution is to make sure users can really identify the sites they’re talking to.

Why current approaches won’t work:

Central authorities: No central entity should be allowed to decide who can(not) be on the Internet.  Like the anti-virus problem, we’re trying to generate a blacklist of phishing sites, but we’ll never get them all because they can be generated automatically and are ephemeral.

Protocols and crypto: They can’t stop you from talking.

Jeff: Apps must change

Many attacks are based on spoofing, and most of the current approaches (better passwords, crypto, bigger logos) don’t address spoofing.  Attackers can spoof virtually any pixel on the screen.  So, we need to make apps that:

  • are impossible to spoof
  • have stronger credentials (dictionary attacks work)
  • have mutual authentication indicators
  • protect from session takeovers

Rob: IE7 improvements to address phishing

IE 7 has new safety features:

  • Phishing filter: When IE goes to a phishing site, it pings a phishing web service and notifies user that it’s a known phishing URL.  Address bar turns red, and the browser prevents user from entering information.  Separates user’s identity from URL for privacy.  Also uses heuristics like using IP address instead of domain name, asking for personal information but not using SSL.  10,000,000 users since April.
  • IDN support: Prevents misleading characters from being inserted in URLs.
  • High-assurance SSL certificates: Verifies sites based on jurisdictions where they’re legally allowed to operate.  Ensures that even picture-in-picture attacks have their URL tested.
  • InfoCard: A password-free authentication system.  Log in to site with an “Infocard” instead of a password.  Runs non-spoofable credentialing app on user’s desktop.

Diana Smetters: Crypto will save the day

Make it so phishers don’t get anything worth stealing.

  • Access should require multiple factors of authentication
  • Sensitive data should not be in a form that’s useful if stolen
  • Sensitive data should be much more limited.  Why have a password for sites that aren’t protecting anything important?

Consider the alternatives:

  • Users will get smarter (but even experts are having more trouble spotting spoofs, and we trust services and widgets that tell us whether a site is secure)
  • Sites will get better (but insider attacks are increasing)
  • Appeals to authority (all sites are potentially valid, so identifying “bad” sites depends on context)

Why bother encrypting?  It reduces the risk of insider and unanticipated attacks, and lowers the burden on users, developers, and administrators.  But deployed solutions to cryptography have a lot of room for improvement in usability.

Questions and answers

Q.  How do we ensure that this is actually easier for developers? 
A.  Educate and provide tools for developers.

Q.  Are there alternatives to the two main approaches—blacklists and heuristics—neither one of which is very effective? 
A.  High-assurance ssl certificates that create a whitelist of good sites, instead of a blacklist.  Another alternative is to make users aware of whom they’re talking to — so that other people’s opinions (black/white lists) don’t matter.

Q.  Perhaps we should stop using SSNs and credit card numbers online.  Are there alternatives? 
A.  Yes, crypto.  Or IE’s InfoCard.  Apps where the client sends along a one-time-use identifier, where it doesn’t matter if info is leaked.  Single-use credit card numbers are commercially available now.

Q.  What about legal deterrence for phishing?  How can we obtain evidence against them? 
A.  In high-assurance SSL, the issuing authority would have the liability and obligation to intervene.  But high-assurance SSL isn’t necessary the best idea.  It requires that one party pay a third party in order to talk to someone.

Q.  For black/whitelists — how does Microsoft address privacy when users are sending every URL to Microsoft?
A.  Caches of known good sites, so URLs are sent as infrequently as possible.  Also, user-identifying information (e.g.  IP addresses) are stripped from query.  Runs over SSL.

This entry was posted on Thursday, July 13, 2006 at 02:02 under General. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.

Mez wrote:
July 13th, 2006 at 05:39

My personal thanks again to the panelists for doing such a great job and putting yourselves out there to make the discussion lively.

The question I didn’t get a chance to ask because there were so many others - if you had $1millionUS to spend on the phishing problem, and could not spend it on yourself or your colleagues, what would you spend it on?

Reply to this comment
 
Jeff Nelson wrote:
July 13th, 2006 at 06:04

Diana Smetters gave a surprisingly plausible argument that phishing is not the problem. Instead, we need to re-engineer the credentials so that the values of SSN, credit card number, and passwords are not lost by revealing them. This could be accomplished through IBE, PKI or ZKP techniques, albeit replacing the credit card infrastructure is not going to happen over night.

If we were choosing a winner for the panel, she smacked us around like a rented mule. So my million would go to start a credit card company based on PKI.

Reply to this comment
Ping wrote:
July 13th, 2006 at 07:36

I’m not convinced.

Let’s try to follow what you and Diana suggest to its logical conclusion. If we want credentials that don’t lose their value when a secret leaks or is given away, what does that mean? It seems to me the only alternative would be physical tokens. So your credit card becomes a cryptographic token with an embedded key. Fine. Now what do you do if you lose your wallet?

Probably, you call the bank to report a stolen card and get a replacement. Okay, now how does the bank know they can trust your call? Do they ask you your address? Your account number? Your birthdate? Your SSN?

But this personal information was supposed to have no value that could be lost by revealing it. So how do you recover from failure? It would seem that there’s no way to fix the problem on the phone. So now you have to show up in person. And in person, what can you give them to prove your identity but perhaps some other piece of ID — which will also have to be a cryptographic token? And what if you don’t have your ID because it was in your stolen wallet?

The point of my story is to show that authentication has to bottom out somewhere. Stripped of all your possessions, your only sources of identity are your mind and your body. Today we use the mind: the final recourse is your memory, your knowledge of yourself. Some are proposing that we switch to using the body instead (biometrics), which is a troublesome idea (in part because you can’t replace body parts after a biometric is compromised).

I don’t think it’s possible to build a system that bottoms out in hardware tokens because tokens cost money, can be lost, and can be stolen. Not everyone has the ability to obtain a token. But everybody has a mind and has the ability to remember information about themselves. It’s impossible to get away from the fact that this information is valuable.

Reply to this comment
 
 
Mez wrote:
July 14th, 2006 at 02:11

OK Ping, so where does your (funny) money go to then? With limited resources, what do you choose to target?

Reply to this comment
 
Diana Smetters wrote:
July 14th, 2006 at 03:53

This is definitely one of the hardest parts of the problem to solve effectively. My best theories at the moment come down to things like: maximize the simplicity of the common things (logging in from the same machine you’ve logged in before, using a token) and make the riskier/more infrequent things harder (e.g. replacing a token, if you have one, or recovering your credentials from backup). The trick for the latter can come down to trusted path — how do they authenticate replacement of credit cards today? They send them to your physical address. Especially if one makes it harder for an attacker to change that without you detecting it, it may not matter who convinces the credit card company to do it. (And that’s only the simplest option.)

I agree that tokens (or other sorts of helper devices) are not the universal easy answer to everything, and that we need to take advantage of simple things humans can do when we can. But I will argue that what people can do on their own is limited, and vulnerable to attack, and we need to find better technological (or other) means to help protect that limited and vulnerable resource. Right now we’ve got the equivalent of a “financial biometric” — passwords, SSN, credit card number, mother’s maiden name, etc — that is also difficult to revoke or change, and can act as a key to get access, money, etc once stolen, but that is possible to trivially type into a computer or read out over the phone. I think we can be cleverer than that.

I think passpet is one good example of how to begin to be cleverer than that, in an easy and short-term-deployable way — I have a password for a site that I don’t know, that I need to get through a tool that will try to refuse to give it away to the wrong person even when I want to. As I said in my talk, we need to start by raising the bar wherever we can, I just find it personally preferable to do that with an eye on where we really want to get to in the end, even if it takes a while.

Reply to this comment
 
Andrew wrote:
July 14th, 2006 at 05:01

I give my money to Ping.

I think, in the short-medium term, the only viable solutions are ones based on confirming to users that the site they are currently at is the site they registered with earlier. Solutions like cookies and Passpet are in this category. Solutions based on centralized authorized or revised encryption methods require more time and effort and money than can be delivered in the short term.

This is an incomplete solution, however, because it assumes that the site was legitimate during the first visit. There are also other risks, but the approach is feasible in the short term and probably usable by a large portion of the Internet population.

Reply to this comment
 
Mez wrote:
July 14th, 2006 at 05:58

The nice thing about incomplete solutions that reduce the problem to first time visits is that they substantially cut down on the scope for attack. Maybe enough to make them unprofitable enough to drive them into the corner that all scams of such sort have been in for a while.

Reply to this comment