Usable Security

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, k₁ and k₂, 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 k₁ and k₂ 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?

This entry was posted on Wednesday, February 8, 2006 at 03:34 under Authentication, Ideas, Spoofing, Tools. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.