How can we improve the user’s experience with, and the security of, passwords? I’m fairly sure a team at Mozilla are thinking about this; my thoughts here are utterly unencumbered by knowledge of or interaction with their ideas ;-)
Frank Stajano at the Cambridge Computing Laboratory has written a paper (blogpost) called “Pico: No more passwords!”, where he proposed a hardware token-based scheme for replacing passwords as our default form of authentication. In its final form, it uses a camera to detect the app, and then a short-range radio interface to send the password to the computer. The purpose of this blog post is not to comment on his specific proposal, but to note his list of 8 advantages that his system provides (taken from his document, and edited by me):
- The user no longer has to remember passwords.
- The user cannot choose a weak password.
- The user cannot reuse a password.
- The user no longer has to type the password.
- The user cannot be phished.
- The system can be used for all sorts of passwords or secrets, not just web ones.
- The user no longer has to manually select the appropriate password.
- The user is authenticated to the app continuously throughout the session.
These are all clearly good things, which make life much easier for a user. He notes that some of these advantages are provided by existing solutions, but not all. That set me wondering: what would it take to get most or all of them in a Firefox context?
The Firefox Password Manager in combination with Firefox Sync gives you 1, 4, 5 and 7 today, out of the box, for every password you use it for. (One could argue you don’t quite get 5 because nothing stops you from typing in a remembered password into a phishing site, but if you rely on the Manager, you get it.)
We could add 2 and 3, and reinforce 5, by adding a “Generate Password” context menu item to Firefox password fields. This would only appear if Firefox knew it was allowed to remember the password (i.e. not “autocomplete=off”) and when selected would fill all password fields in the same <form> with a single randomly-generated password. It could use the HTML5 regexps for field contents, if present, to make sure it generated a password the site would accept. If the feature was used on a page, and the password submitted was the same as the one generated, Firefox would automatically remember the login and password without prompting (but perhaps with a notification, for reassurance).
The generated passwords would be, say, 10 characters long, and a mix of upper and lower case, numerals and a punctuation character. If the site was dumb enough not to accept such strong passwords, once they got the error back the user could give up on the feature and pick a password themselves, just as they do now.
There’s also a way we could add benefit 6. It strikes me that the contents of the Password Manager section of my Weave account, and the contents of OI Safe, the Android password manager I use, are highly related. We could implement a Firefox Mobile addon or even a standalone app (like a specialized Firefox Home) which showed the Weave password store like a password app does, and also allowed you to add extra non-web usernames and passwords to it manually – e.g. the combination to a bike lock, or a door entry code. You would use the same app to retrieve them when you needed them. A standalone app might have the convenience factor required; but if we can make websites into mobile apps, with top level icons, perhaps we can also add a feature to make a Firefox addon’s UI do the same thing.
That leaves us with everything except benefit 8 – walking away from your computer doesn’t automatically log you out of the web app. This seems not all that connected to the other 7 password-related benefits; more a cool thing which happens to fall out of Frank’s implementation. Still, there are some options.
We would have to consider the privacy implications, but both websites like this and web-based IM clients might benefit from an “idle” value in the DOM, giving the time in seconds or minutes since the user last interacted with the computer. As long as the value was low, sites could assume the user was still present, and not log them out. If it got above a value the site considered unsafe, automatic log out could occur.
This would avoid the very irritating thing of sites logging you out for “inactivity” when you were sitting at your computer the whole time, just doing other things. My previous bank (Barclays) did this a lot; my current one (HSBC) at least pops up a window with a timer asking me if I want to stay logged on. Better, but also a hack.
To summarise, I propose:
- Add “Generate Password” to Firefox password field context menu
- Make a OI Safe-like Android app using the Weave store as its back end
- Standardising a DOM property for “computer idle time”
Here’s the bug for the first bullet point:
https://bugzilla.mozilla.org/show_bug.cgi?id=363372
I use sync and FF password manager and I CONSTANTLY run into trouble:
* Sites block my browser from remembering (I try to use scriptlets but sometimes there are problems, like the site doesn’t allow FF to remember the username as well as the password)
* I find myself on a different page of the site but prompted for the same login; I may have to navigate back to the home page to get FF to remember my credentials
* Somehow FF doesn’t recognize the fields as logins
This is all actually a pretty constant PITA and I observe other people dreading the more obscure websites that have a log-in — they know there’s a good chance it won’t remember the laboriously entered password.
Before I choose a “create a crazy password” prompt, I need to feel much more confident that FF will indeed remember it!
On a related note, I was pondering the idea of having the browser hash password fields before sending the form data (with a proper salt). Typically passwords should be hashed before being stored on a server to prevent username/passwords pairs from leaking if a server’s backend is hacked, see gawker password leak. The main benefit is this can protect against servers being careless with your password.
Obvious problem with this suggestion is backward compatibility.
I’ve been using KeePass for my password management and generation needs. I haven’t used the Firefox extension yet, but it’s quite nice to use. When I first started using KeePass, I made an effort to start using strong, unique passwords for every site I use now that the barrier for doing so was nonexistent.
I was quite taken aback by how many sites not only discourage the use of strong passwords, but some going so far as to outright ban them. ING bank, for example, only allows numbers in their passwords and a maximum length of 10 characters, which is laughable. About half of the passwords I was changing didn’t accept special characters (or a very small set of them). So while I’d love to see Gecko support built-in password generation, I don’t think the web is really ready for it yet.
“The Firefox Password Manager in combination with Firefox Sync gives you 1, 4, 5 and 7 today, out of the box, for every password you use it for.”
Yes, but… That is of no use when you’re using a computer that is not yours and doesn’t have sync set up, and as previous comments pointed out the password manager only works on some sites. So you really need to address 6 (preferably in Firefox as well as on a mobile device) to solve that – although you’re then giving up on 4 to some extent.
“… 10 characters long, and a mix of upper and lower case, numerals and a punctuation character. If the site was dumb enough not to accept such strong passwords …”
In my experience, many many sites are this “dumb”, including some of Mozilla’s own. 10 characters of upper and lower case and numerals is pretty good, and will work on far more sites. Also, rather than entirely random, at least one of upper/lower/number is good, as otherwise you might get a random password which doesn’t meet the site’s criteria for including a number or whatever. This is, I guess, the experience of others as well, as a couple of the password managers I’ve tried do that.
Hi Gerv, my 2c:
i) I like the idea of extra hashing in Sync
ii) I like PayPal’s gadget for the physical sense of security it gives me – doing essentially #1 above
ii) and I like the KeePass file for the same physical feel of security. Pretty much similar to the question: “Money safer in the piggybank or in the bank vault?”
…
Forcibly log the user out after a predefined period of time (presumably minutes, or in any case no longer than an hour or two)? Please don’t! I live alone, no one else has access to this computer, and I like the fact that months can go on without Bugzilla forgetting who I am. On the Wikipedia, my preferred skin (Cologne Blue) has a markedly different look & feel than the default one presented to anyone whose login cookie has expired, but I’d like to be remembered (I’d like that login cookie to remain valid) for longer than it does.
This idea is impractical. It assumes that whoever is sitting in front of an unlocked computer running Firefox is a person that should have access to any security-required site the browser’s profile contains. It also assumes people want to use the firefox password manager and is less secure because of the age-old problem that users generally will not choose and remember a reasonably strong password. Instead they will choose an easy one which will then expose all their security-required website accounts in one foul swoop.
I’d hate to see this sort of idea in the hands of a marketing team. If you do it, the marketers will spin it as the end of passwords and users will undoubtedly believe this spin and end up in all sorts of trouble.
This idea is just asking for trouble. Please bury it.
8 is perhaps the most interesting, from a security perspective. It would clearly require cooperation from the server side, but browser support might be a first step that could be taken. The tricky part would be figuring out how to do it in a way that doesn’t drive the user into a murderous anti-computer rage. I don’t have a good answer for that, but it’s worth thinking about.
6 is something some of the desktop environments have been working on, and that’s the logical place for something like that to be implemented, I think. I mean, the fact that it already works in the web browser would seem to imply that the web browser isn’t the component that still needs to implement it, eh?
1, 4, and 7 are things that we take for granted on today’s web. I believe every major browser supports them out of the box. It’s important that the user be able to turn the feature off if it’s unwanted, of course, but so far that hasn’t been a problem there, to my knowledge. In fact, I’m pretty sure every major browser defaults to requiring the user to hit a “yes, save my password” button initially for each site, which is probably as it should be.
Absolute implementation of 2, 3, and 5 would be fundamentally incompatible with leaving control in the hands of the user, which is probably the most important core tenet of open-source software, in my considered opinion. I would be very definitely against absolute enforcement of these things in principle, and I hope you would be too. Measures to try to warn the user about the dangers are good, as long as they don’t get too ridiculously in the way of usability, but absolutely _preventing_ the user from setting the password they want (the password, it should be pointed out, that they may very well have already set previously, using another computer or another browser, and may have already memorized, possibly at considerable effort — not all users memorize passwords as easily as the typical network administrator) would be very bad. If the user can’t log into their various web accounts, what use is the browser?
I want to be clear about this: I’m MUCH more security-minded than the average user, but there’s no way in the world that I would ever use (on a daily basis, for purposes other than testing) any browser that prevents me from using the same insecure password to leave comments on every random blog and forum. Such a browser would not be useful or usable, as far as I’m concerned. Delete that junk. I’m stone cold certain many other users would feel similarly.
#2 is also incompatible with the existing web, since various sites have various password policies, and no (even vaguely) secure password complexity policy would be compatible with all of them. Some sites require all-alphabetic passwords; others have egregious maximum lengths. Come to think of it, there are unfortunately still a few sites where the password is _required_ to be a four-digit number, and even more sites where the staff _tell_ users that the password has to be a four-digit number because that’s what used to be required under the old, non-web-enabled software and old habits die hard, e.g., a great many public library catalogs are in this latter category, because the old dumb-terminal-based in-house-kiosk catalogs used four-digit PINs in lieu of a real password for their look-at-your-account feature. Such sites should, of course, be encouraged to take a more modern view of security. Nonetheless, making the browser incompatible with them would be a rather extreme step.
> Forcibly log the user out after a predefined period…? Please don’t!
I have to agree strongly with this. I’ve completely stopped bothering to ever log in to Wikipedia due to their preposterously short session expiration. I’d log in, start working on an article, and by the time I submitted my changes the edit became anonymous because the session had already expired. OCAL is just as bad.
Some points:
This is not necessarily PwdHash. PwdHash’s benefits come from using the same hashing algorithm for all your passwords; this isn’t necessary in my scheme. Weave supplies the ubiquity, not a common algorithm. That doesn’t mean you couldn’t use the PwdHash algorithm, but it’s not necessary.
Jamie: you are right, we need to improve the reliability and repeatability of Password Manager too.
Benoit: that wouldn’t make any difference. The idea of hashing passwords is that if an attacker captures the hash, they can’t work out what they actually need to send to log in. If the hash is what you send to log in, then the hash _is_ the password, and there’s no benefit!
RyanVM: If Firefox started supporting this, and publicised a minimum password standard, I think it could drive change. Hey, if we mandated acceptance of
Tony: What I am suggesting would fix, not create, the problem you give. If a site already logs you out after a certain period of inactivity on that site, it can now change to logging you out after a certain period of inactivity on your computer, which would be less often – an improvement.
Again, on the point about sites having password which don’t work – the only way to change that is to widely deploy this feature, and have people complain to the site that it doesn’t allow secure passwords.
I totally second the request to add a password generator to Firefox. For quite a long time I’m using a bookmark to an online password generator for exactly this purpose. It’s quite clumsy though:
So yes, some integration would help!
It would be really good if Passwords became a “first level citizen” of HTML. How about challenge/response, rather than sending it in cleartext?
What about session cookies? Do we really need *every* webserver implementing their own “check session cookie – redirect to logon page – check password – choose new secure random session cookie – check timeout logoff – clear session cookie”
And what about SSL sessions? Client certificate authentication/Smartcard authentication integration.
The number of different implementations of the same security-critical infrastructure is baffling.
Excellent idea, this is hugely important. Ordinary users need the support of a built-in password manager – currently only power users do it properly with third-party tools. Browser security is only as good as the weakest element, and this is probably it.