How to Manage Passwords and Prevent Phishing

February 8, 2006 by Ping

I have an idea about how to solve the phishing problem.  Although proposals to solve phishing are not yet as common as proposals to solve spam, there certainly have been quite a few of them, so you would be right to wonder what makes this proposal any different or any more likely to work.

So, right up front, here is the key property of this proposal: using it is more convenient than not using it

This property makes this proposal unique (as far as I am aware).  All the other proposals I have seen require the user, on each login, to do more work than they previously had to do.  And that, in my mind, instantly dooms a solution to failure, or at the very least creates a stiff barrier to its adoption.

With the tool I propose, called Passpet, you enter a secret only once per browser session.  To fill in any login form, you just click a button.

Passwords are vulnerable due to several related problems: phishing, weak passwords, and password reuse.  Passpet combines four ideas to address these problems:

  1. User-assigned labels to identify websites.
  2. Password hashing to generate a unique password for each site.
  3. A variable amount of repeated hashing to strengthen passwords against dictionary attack.
  4. Customization to identify the tool itself and make it hard to spoof.

None of these ideas are completely new, but I think the combination is new and interesting.  Here’s how they all go together.

1.  User-assigned labels.

The reason phishing works is that users are constantly asked to enter passwords without any reliable way to know who they’re giving their passwords to.  The way things work now, login forms train users to be phishing targets.  Any effective phishing solution must provide a way to identify the other party and must get users out of the habit of giving secrets to strangers.  These two things are achieved by user-assigned labels and password hashing, respectively.

Instant messaging clients already use user-assigned labels, and they work.  With most IM clients, you can edit the names of the contacts on your buddy list.  For example, if you have a friend named John Wilson whose username is jwilson37, you could add jwilson37 to your buddy list and then edit the name to “John Wilson.” Then when you get a message from jwilson37, your IM client says it’s from John Wilson.  It is more pleasant to see John Wilson’s real name in IM conversations, but it also has a security benefit: when you see “John Wilson” you can have some confidence that this refers to the specific John Wilson you added to your buddy list, not some other John Wilson.

A Firefox extension called the Petname Tool applies this concept to websites.  It provides a text field on the toolbar.  You simply type a label into the field, and the Petname Tool associates that label with the current site’s SSL information.  The label reappears to tell you that you once again have a secure connection with the same site.  All you have to do is check the label to be sure that you are at the real site, not an impostor.

Passpet should provide this feature.  That’s not all we need, though — we know from common sense and from controlled studies that merely adding browser indicators is not enough.  That’s because checking the indicator is an ancillary activity — it’s not part of the workflow of logging in.

2.  Password hashing.

Password hashing is a technique that’s been applied to websites even longer than user-assigned labels.  It’s a simple idea: you memorize one good master password, then a bit of software hashes it together with a unique identifier for each login to produce a unique password for each login.  If the hash function is good, it will be hard to reverse, so it ought to be hard for someone who steals one of your site-specific passwords to figure out your master password.

Many password hashing implementations have been written — some of the earlier ones I know are LPWA and Site Password, and a more recent one is PwdHash for Firefox.  However, they all require more work than a normal login (you have to enter your password and do some extra step to activate hashing) and they still train users to be phished.  For example, PwdHash tries to minimize changes to the user interface, which is a laudable principle, but it means the user still types passwords into forms on webpages that can be made to look like anything.  In other words, the user is still trained to give away passwords to strangers all the time.  In my opinion this is the wrong choice; this is a part of the user interface we really must change.

To successfully change the user interface for a familiar activity, you’ve got to provide an alternative that’s more convenient.  Putting together labels and hashing makes this possible: the user-assigned label is what gets hashed together with the master password to produce the site-specific password.  The label field is also a handy place to record your username, so you don’t have to keep typing that in over and over.  You enter your master password just once in any browser session, the first time you use Passpet.  From then on, it’s one click to fill in your username and hashed site-specific password in any login form — much easier than recalling and typing in your password each time.

And now something magical has happened.  You don’t type passwords into random forms anymore.  The login habit changes from “enter my password” to “click the button”.  If you’re at an impostor website, the label you entered won’t reappear, so clicking the button won’t work!  You can’t even give away the site password if you want to, because it’s always calculated — you’ve never seen it.

There’s another nice consequence of this design, too.  If you click on a button to log in, that draws your attention to the button, and the label field is right next to the button.  Looking at the reliable site identifier is a part of your login workflow; it’s no longer ancillary.

3.  Variable password strengthening.

A moment ago, I said that if your hash function is good, it will prevent an attacker who steals a site-specific password from getting your master password.  That’s not entirely true, though, because the attacker can still try to guess your master password, and can check these guesses by seeing whether the hash comes out the same.  In other words, you still might choose a weak master password, and then you would be vulnerable to a dictionary attack.

Getting people to choose (and memorize) strong passwords is hard!  The dialog where Passpet asks you to choose your master password could provide some advice on how to pick a good password, but we’d still like to do better than that.

Dictionary attacks depend on being able to make lots of guesses and check them quickly.  If we make it harder to check a guess, then the attacker will have to do more work.  Suppose it takes an attacker a million guesses to hit upon your password.  If the site-specific password is calculated in a single hash operation, an attacker can easily check a million guesses in less than a minute.  But if it takes ten seconds of work to get from a master password to a site-specific password, it would take over 100 days to check a million guesses.

J.  Alex Halderman has proposed a nice technique for strengthening passwords that is implemented in a tool called Password Multiplier.  The strength of the scheme is based on choosing two constants, k1 and k2, that determine how much work to do when you choose a new master password and each time you log in, respectively.  The thing is, computers get faster all the time, and reasonable choices for k1 and k2 today might not be so effective in a few years.  In fact, even today, a reasonable choice for one user could easily be too weak or too strong (i.e. too slow) for another user.

So Passpet should use a slight variation on Halderman’s scheme.  Apply the same hashing strategy, but instead of doing a fixed amount of work, just keep working as long as the user is willing to wait.  As you type in your master password, Passpet should just chug away, hashing it over and over until you click to go ahead.  While it’s working, it should show you an estimate of how strong your password is — based on the amount of entropy in your password and how much hashing work it has done so far.  You get to watch the strength of your password tick up and up (”1 day to break” …  “1 week to break” …  “3 months to break”) and you just click when you are satisfied.  If you’re impatient you can go ahead after some minimum of a few seconds; if you are conscientious or your company insists on a particular policy, you can just wait until your needs are met.

A nice property of this approach is that, as computers get faster and faster, you automatically get stronger passwords (assuming your patience stays about the same).

4.  Customized appearance.

There’s still a password in this scheme, and the user still has to memorize it and enter it.  The moment at which you enter your master password is a vulnerable moment — how do you know you aren’t giving away your master password to the wrong party?  An attacker could try to fool you by spoofing whatever form or user interface Passpet uses to ask you for your master password.

Passpet reduces this risk in a few ways.  First, Passpet never pops up to prompt you for your password.  The interaction model of website logins is that a password field appears on a webpage and, in response, you enter your password.  Bad!  You’re already much more vulnerable in reactive mode than in proactive mode.  So with Passpet, you click to initiate and, in response, Passpet provides you a place to enter your password.  You are in control.

Second, Passpet does not pop up a dialog window.  Dialog windows are awful from a security standpoint — they are ubiquitous, they are indistinguishable, and webpages can pop up anything they want.  Instead, the master password field appears in the toolbar, and it appears by animating over the other contents of the toolbar, which is hard to imitate.

Third, the user interface is hard to spoof because it differs from user to user.  The Passpet button doesn’t have a standard icon — a random icon is chosen when you install it, or you can choose your own icon if you want.  The icon is initially chosen to be a random animal, and the animal has a random name, like “Betty the Giraffe.” That becomes Passpet’s persona for interacting with you.  It’s the same basic idea as Dynamic Security Skins or PassMark (a.k.a.  SiteKey): customize the interface so it can’t be imitated accurately.  But Passpet applies this technique more effectively: instead of presenting you an image that has nothing to do with your login, the custom image is the thing you actually click.  DSS and PassMark fail if the user doesn’t notice the image or forgets to check for it.  But if you’re looking for a giraffe to click on and there’s no giraffe, you can’t click on it.

Passpet goes a little further than the custom icon.  The field for entering your master password isn’t labelled “Enter your password:” — instead, it’s labelled “Enter Betty’s secret:”.  Since the persona differs from user to user, it’s hard to even ask for the password because the spoofer doesn’t know what to call it.

Deployment

There are a few other operational details about how one would use Passpet.  How do you set up a new account?  That’s easy — just put the cursor in the “new password” field and click the button; Passpet will generate the new password for you, saving you the trouble of typing it in.

What about changing a site’s password?  Suppose you’re especially concerned about your banking password and want to change it every couple of months.  That’s easy too — use Passpet to fill in the “old password” field, then change the site label (e.g.  from “Wells Fargo” to “Wells Fargo 2”) and click again to fill in the “new password” field.  Passpet remembers the edited label and you can continue as before — one click to log in.  That’s definitely easier than having to think up a new password and remember it.

What about changing your master password?  If you change your master password, all your site passwords will change, but you don’t have to update them all at once.  Tell Passpet you want a new master password, and a second Passpet persona will be created.  Click on the old Passpet to generate your old passwords; click on the new one to generate your new passwords.  When you have finished migrating, you can get rid of the old Passpet persona.

What about going to another computer?  The master password is the one secret you have to memorize, but the other information Passpet needs — the list of labels you’ve assigned — can be stored on a remote server, and picked up from there.  It should be stored encrypted (using a key derived from your master password) so that only you can make valid changes to it.  You should be able to choose any server you want.  Because the server doesn’t contain any passwords, you’re not vulnerable to break-ins if the server is compromised (or even if the server administrator wants to hurt you) — the worst the server can do is go offline.  That may be inconvenient, but not very harmful, especially if you have a backup of your data.  Your dependency on that server is much lower than your dependency on, say, a web mail provider.

And that’s my story so far.  Your thoughts?

Ka-Ping Yee on Phishing…

In “How to Manage Passwords and Prevent Phishing,” Ping writes: So, right up front, here is the key property of this proposal: using it is more convenient than not using it. This property makes this proposal unique (as far as……

 

It sounds great to me—especially the part where I don’t have to worry about making up fresh passwords myself all the time! I’ve considered using one of those extensions that makes a new password based on the host name, but it seems kind of fragile to rely on that never changing. Using the user’s nickname for the site instead is a neat solution to the problem.

The most obvious risk of such a system is that if someone does subvert it, even security-conscious types will be fooled. But that would involve finding a bug that lets you infect the XUL that implements the toolbar, or spoofing the SSL connection that validates the site or something, and these are a lot harder than just faking up a web page with someone’s bank’s logo.

Also, everyone can custimize their web browser by choosing their favourite TV character to be their toolbar icon.

Thanks for the encouraging response!

if someone does subvert it, even security-conscious types will be fooled.

Well, yes… if you subvert anything, it’s subverted. Is there something specific to this scheme that makes it more vulnerable to subversion?

 
 

“All the other proposals I have seen require the user, on each login, to do more work than they previously had to do. And that, in my mind, instantly dooms a solution to failure”

The upcoming IE 7 solution does not require more work, nor install software.

http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx

In addition, that solution can help thwart mixed ssl attacks.

The upcoming IE 7 solution does not require more work, nor install software.

I think installing a whole new browser counts as installing software.

As for requiring more work, i think it does require a some small amount of extra work. If i understand the design correctly, the user has to check the indicator to see whether it’s yellow on every login.

There are many serious drawbacks to the IE7 scheme. It requires sending every URL you visit to Microsoft; it assumes that a single authority can determine what’s good or bad for everybody; it adds inconvenience to the login process. Even if you completely trust Microsoft and ignore the privacy concerns, purely from a practical standpoint it sets up a huge central point of failure.

 
 
Peter Gutmann wrote:

>The upcoming IE 7 solution does not require more work, nor install software.

Nor will it work. What IE 7 is doing is a prime example of what Marcus Ranum calls “enumerating badness”, rating it No.2 in his “Six dumbest ideas in computer security”. See http://www.ranum.com/security/computer_security/editorials/dumb/ for the gory details.

It depends. AV engines today ‘enum badness’, yet I wouldn’t go as far as saying they ‘don’t work’.

Peter Gutmann wrote:

Hmm, you haven’t actually read Marcus’ article where he discusses this, have you? :-).

 
 
 
Mark Tyndall wrote:

There are some other use-cases you haven’t written about: the first is having Passpet take over your existing accounts - which would require a visit to each site to find the “change password” form. Of course, you may not want to do this all in one go; and some accounts (such as my bank) may not have password changing facilities on the web.

Another is retiring Passpet and surrendering control of its passwords back to (a) the user or (b) the default password manager if it’s an add-on and not a built-in replacement.

Good point. Any scheme that tries to make your passwords stronger is necessarily going to require changing your passwords so they aren’t all the same. With Passpet you don’t have to change them all at once, though. The common usage pattern is that after installing Passpet, the next time you log in to a particular site you change your password there. Over the course of a few weeks all your commonly used passwords are strengthened, and it’s not too terribly onerous to do.

Retiring Passpet is a matter of changing your password and typing in something you made up instead of clicking the Passpet button.

 
 
Alan Karp wrote:

The first password hashing scheme I came across is SuperPassword by YanQiQi, which is dated April 2000. Unfortunately, the download site at thinkingsoft.com is no longer reachable. Please let me know of any earlier references to this idea.

 

Thanks for the powerful ideas and this proposal. Even without adding in the ideas about hashing, I think that using browser history and signals of a user’s past evaluations of trust are better ways of solving the phishing problem.

Thanks!

Just to make sure I understand you, are you saying that you see user-assigned labels as a good solution because they are an application of browser history and signals of past trust decisions, or are you thinking of other ways of using historical information that you consider better than the user-label approach?

Both, really. I question the idea of asking users to come up with labels for websites that they trust, as it seems like overhead that might degrade the user experience and get in the way of the core browsing task. A light(er)weight solution would be to indicate when they’re at an SSL page which they’ve been at before, or an SSL page that they’ve bookmarked or tagged or otherwise indicated as being what it claims to be. Essentially an indication that the user has decided to trust that site before, so they don’t have to repeat the trust-judgement on every repeated visit.

Coupling that with a label allows password hashing, which is an ingenious example of killing two horribly unusable security birds with a single rock of simplicity, but I see that system as one that could be overlaid on top of the more basic anti-phishing solution.

I’d encourage you to read and comment on: Sending the Right Signals, a paper I’m putting forward to the W3C’s upcoming workgroup on usable SSL authentication systems. Heck, I’d encourage you to come to the workgroup, if you’re not already. :)

Trust is in the user’s head - the browser can never know what that is, as it is of necessity an individual, human attribute. All the browser and any tool can do is repeat what it has been told, in more and more convenient ways.

What I see as ideal is a progression of historical information: having seen a cert before, how many times, having bookmarked a cert, having tagged it, and having labelled it with a petname are all progressions in better information that can be displayed to the user. A great tool would present all these to the user, rather than try and choose one or the other as “better” in some sense. (Of course, that leaves aside implementation details…)

(Comments won't nest below this level.)
 
 
 
 
Oliver Clevont wrote:

For the PetNames extension, why even require the entering of a pet name? If you trust the site, isn’t it enough to just have a checkbox which says “User trusted”? And along with it, just color the address bar green for trusted sites, and white for undecided sites. No typing involved whatsoever. The only fear is if one trusted site tries to impersonate another, but then you wouldn’t trust someone like that in the first place.

Like Alan Karp says, “I trust my bank with my money but not with my children; I trust my relatives with my children but not with my money.” So, in general, it’s not enough to have a checkbox that says “User trusted.”

 
 
Umesh Shankar wrote:

Has anyone here used a program called Roboform (www.roboform.com)? It’s a password manager in Windows, attaches as a toolbar to IE and Firefox, uses a master password to encrypt the password files, allows you to login to a site easily by remembering the login page and login fields, and shows you matching passwords when you visit a URL. This last property serves as an implicit “petname”–if Roboform does not have a password for a site that you think you’ve registered at before, you’re probably being phished. This appears to have many of the same properties as this proposal. As for portability to multiple machines (the main drawback to non-hashing schemes), well, yes, you have to sync them, but I also sync to my Palm device for when I’m on the go. Note that the proposal here also has a sync requirement. It’s free to try–I urge those who haven’t to evaluate it. I’m curious to hear opinions.

Peter Gutmann wrote:

There’s a pile of plugins that provide different variations on this, generally providing some form of per-site password capability, which goes beyond the built-in password manager facility. As with the pile of Trustbar-type plugins for Firefox, it’s the sort of thing where you’d expect that after seeing a dozen plugins to do this it’d be a sign that it’s time this functionality was integrated into the mainstream code base.

 
 
Alan Karp wrote:

I just tried RoboForm. It’s an interesting tool, but it does fill in passwords on http pages. Since the entry is keyed to the URL, you are protected from phishing, but you are still vulnerable to pharming. Also, synching doesn’t help if you’re at a friend’s house and need a password.

Umesh Shankar wrote:

Keying to SSL cert instead of URL is a pretty easy change. As for portability, there are a number of solutions; I use my Palm, and the Roboform guys have a USB key-based solution that requires, according to them, no software install. See http://www.roboform.com/pass2go.html .

Lest anyone be curious, I have no stake in Roboform, but I have used it for a few years and found it very effective. In fact the original purpose, form-filling, was what drew me to it initially.`

 
 
Alan Karp wrote:

If you key to the SSL cert, then what do you do about sites that don’t have an https logon, such as facebook?

USB keys are a good approach, as long as you have yours with you. One nice thing about hashing is that the only thing you need, your master password, is in your head. People are comfortable with that model. Now, if we could just make the password calculator ubitquitous …

Bottom line: Put password wallets, such as RoboForm, and hashers into the market. My guess is that there’s room for both.

 

Your key property “using it is more convenient than not using it” is quite interesting. Thinking about it briefly, the only crypto tools which I have found that have achieved this are Skype and SSH. Both have been phenomenally successful and I think that more than coincidence. What else is there?

 
Bill Stewart wrote:

SSL Client-side Certificates are really the right choice here. There are probably some man-in-the-middle attacks that work against them, but they’re restricted to active attacks which are much harder to pull off successfully and untraceably than passive steal-the-password-for-later-abuse attacks. They won’t stop phishers from sending con mail until almost everybody uses them or something like them, but they can at least keep banks that use them from getting phished much. The amount of setup work for the client is pretty simple, and only needs to be done once per bank account per PC.

SPF and DKIM are also useful things that aren’t being deployed by banks or other phishing targets, and would cut out a lot of the phish mail because ISPs can reject mail sent from inappropriate IP addresses without the recipient having to do any work. That won’t stop phishers from registering domains that look cleverly similar to real banks, but again it’s at least a start.

The amount of setup work for the client is pretty simple, and only needs to be done once per bank account per PC.

So if you use a desktop computer, and an emergency happens while you’re away from home, there’s no way you can access your accounts? I’m not so sure this is going to fly.

 
Peter Gutmann wrote:

>The amount of setup work for the client is pretty simple

. The amount of work required for client-side PKI is outrageously high, so high in fact that almost no-one even does it (or those that do drop it pretty quickly). Look at the research done at Xerox PARC, where a bunch of people with PhDs in computer science rated client-side PKI as the hardest computer task they’d ever been asked to accomplish, taking on average over two hours even though they had step-by-step instructions with screenshots to guide them. When informed of this, the manufacturers of the gear they were using were baffled that anyone would even try and do this. There’s a reason why virtually no-one uses client-side PKI in practice…

(BTW Ping, why do I need to have Javascript enabled just to use your blog? Mumble mutter…).

Sorry about the Javascript. I’ll see what i can do about a fallback.

 
 
 

Part of the ‘problem’ is the HTML input type=password; it’s a dangerous sort of input field that we could have done more to ‘protect.’ is it a fair understanding of how passpet works to imagine that browsers should display the passpet button instead of a textfield?

That is, from a DOM perspective, could passpet replace the default password input widget?

Yes, it could, though i suspect such a design might be more vulnerable to spoofing. If you never draw the user’s attention out of the document area, then it’s harder to give the user an unspoofable identifier for the site.

You can use the same “pet icon” trick to try to make the in-page UI hard to spoof, but i think it would be weaker than a pet icon in the toolbar. I think some users would learn to click on any in-page button next to a “Password:” label regardless of its icon, whereas they would be less likely to click on a toolbar button with the wrong icon.

 
 

[...] How to Manage Password and Prevent Phishing [...]

 

Hi Ping

Is Passpet still an idea or have you moved to active project? I have long recommended Password Safe, in part because I have confidence in the dev team, and it is unaffected by browser changes. Now that Fx has matured I am willing to reconsider.

I don’t bring any coding skills to the table but I’m interested and would enjoy participating.

Hi! Passpet is under development. We’ve just gotten a paper accepted to SOUPS, which will be its first public presentation.

 
 
Peter Gutmann wrote:

I’ve had the Passpet concept on my shopping list of cool security UI ideas for awhile, recently I started thinking about implementation details and realised that the password-strengthening you propose (hash until done) doesn’t actually work because there’s no good way to put a UI around this, nor will it work easily with existing crypto APIs.

The UI problem is that there’s no easy way to communicate what’s going on to the user. I thought of adding some text to the password dialog along the lines of “The longer you’re prepared to wait before clicking ‘OK’, the string the protection will be. Note that this delay will occur every time you enter your master password. Current protection: 1 day to break”, but this is just plain ugly, there’s too much for the user to absorb, and even this lengthy explanation won’t be enough for most users. Furthermore, the more explanatory text you add, the longer people will be delayed before they click OK, creating an irritating problem whenever they enter their password in the future. In the worst case this delay time is unbounded, for example if the phone rings before they can click OK, or (a more common case) they pause to write the password on a post-it note to stick to the side of their monitor before clicking OK. It’s just too awkward and un-controlled.

A second problem is that most (all?) crypto APIs don’t give you this level of control over password hashing unless you’re working at an extremely low level. Most just follow the functionality of standard password-processing mechanisms like PBKDF2, where you input a password, salt, and iteration count, and wait until it spits out the result. You can’t interrupt this at an arbitrary point when you get bored.

After thinking about this a bit I figured a more workable solution woul be to provide a slider from 0…10s (default = 1s) and the text “To strengthen your password protection, you can add a processing delay to the password each time you enter it. The longer the delay, the stronger the protection”. This puts the user in direct control, and makes explicit what’s happening, rather than overloading the ‘OK’ button with unexpected functionality.