Comments on: How to Manage Passwords and Prevent Phishing http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/ Every system has a user. Sat, 6 Sep 2008 19:57:12 +0000 http://wordpress.org/?v=abc By: Peter Gutmann http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-5921 Peter Gutmann Sat, 22 Jul 2006 10:05:57 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-5921 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. 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.

]]> By: Ping http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-3276 Ping Wed, 26 Apr 2006 21:04:20 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-3276 Hi! Passpet is under development. We've just gotten a paper accepted to SOUPS, which will be its first public presentation. Hi! Passpet is under development. We’ve just gotten a paper accepted to SOUPS, which will be its first public presentation.

]]> By: pdtar http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-3127 pdtar Sat, 22 Apr 2006 19:31:39 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-3127 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 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.

]]> By: rebron.org » anti-phishing summary http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2882 rebron.org » anti-phishing summary Tue, 04 Apr 2006 20:10:08 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2882 [...] How to Manage Password and Prevent Phishing [...] [...] How to Manage Password and Prevent Phishing [...]

]]> By: Ping http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2687 Ping Fri, 31 Mar 2006 23:38:39 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2687 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. 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.

]]> By: Rohit Khare http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2686 Rohit Khare Fri, 31 Mar 2006 22:58:27 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-2686 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? 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?

]]> By: Ping http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-674 Ping Mon, 27 Feb 2006 07:01:12 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-674 Sorry about the Javascript. I'll see what i can do about a fallback. Sorry about the Javascript. I’ll see what i can do about a fallback.

]]> By: Peter Gutmann http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-673 Peter Gutmann Mon, 27 Feb 2006 06:30:17 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-673 >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...). >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…).

]]> By: Ping http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-670 Ping Sat, 25 Feb 2006 19:31:56 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-670 <blockquote>The amount of setup work for the client is pretty simple, and only needs to be done once per bank account per PC.</blockquote> 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.

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.

]]> By: Bill Stewart http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-667 Bill Stewart Sat, 25 Feb 2006 05:12:40 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-667 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. 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.

]]> By: Kragen Sitaker http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-651 Kragen Sitaker Sun, 19 Feb 2006 23:09:06 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-651 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." 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.”

]]> By: Iang http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-632 Iang Thu, 16 Feb 2006 09:31:45 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-632 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? 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?

]]> By: Iang http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-631 Iang Thu, 16 Feb 2006 09:24:05 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-631 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...) 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…)

]]> By: Peter Gutmann http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-628 Peter Gutmann Thu, 16 Feb 2006 05:41:34 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-628 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. 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.

]]> By: Alan Karp http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-625 Alan Karp Wed, 15 Feb 2006 22:52:12 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-625 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. 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.

]]> By: Umesh Shankar http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-624 Umesh Shankar Wed, 15 Feb 2006 22:31:47 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-624 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.` 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.`

]]> By: Alan Karp http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-623 Alan Karp Wed, 15 Feb 2006 22:15:18 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-623 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. 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.

]]> By: Umesh Shankar http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-622 Umesh Shankar Wed, 15 Feb 2006 21:33:50 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-622 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. 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.

]]> By: Oliver Clevont http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-406 Oliver Clevont Fri, 10 Feb 2006 07:37:13 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-406 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. 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.

]]> By: Peter Gutmann http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-399 Peter Gutmann Fri, 10 Feb 2006 05:42:30 +0000 http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/#comment-399 Hmm, you haven't actually read Marcus' article where he discusses this, have you? :-). Hmm, you haven’t actually read Marcus’ article where he discusses this, have you? :-).

]]>