People reuse passwords. This is not secure. But people do it anyway. So, can we make it more secure? Yes we can! In fact you can securely sign in with a single master password on all sites you visit. Plugins like PwdHash show how this can be implemented without requiring sites to change their login procedure in any way. In this post I will discuss a slightly different approach to implementing such a plugin, compare it to PwdHash, and discuss some of the usability issues related to these systems.
The basic idea of such a plugin is as follows. The browser plugin monitors all pages you visit, looking for pages that require you to enter a password. This is exactly what current password managers do. The plugin then asks you to enter your own master password. You only need one master password. And you only need to enter it once. Make it a secure one: select a 5 word passphrase. This master password never leaves the browser/plugin. Instead the plugin hashes the master password with the domain of the site requesting you to login. The result is converted to a string consisting of letters, digits and punctuation marks. This site specific password is then pasted into the password entry field in the form displayed in your browser.
(Note that PwdHash works slightly differently. Instead of restricting the user to use a single master password, you can enter a different password for each site, that is hashed with the domain of the site you visit.)
Conversion to a string must be done in such a way that the resulting site specific password is acceptable for all sites (i.e. such that it fits all password policies). In all likelihood, there probably is not a single method that fits all policies out there... In that case, several conversion strategies must be implemented, each fitting a distinct class of password policies. With a little luck, a handful will do. Then all a user needs to remember is that for certain sites he should select the right password conversion strategy. The default conversion strategy is of course the one used by most popular websites.
Some users have several different accounts at the same site. Using the technique above all these accounts would have the same password (unless you use PwdHash). To avoid this, the plugin should mix in the username when computing the site specific password. Note that the plugin assumes that users do remember their username at a certain site. We could try to auto generate usernames in a similar fashion as well, but this might turn out to be problematic. For example, in many cases the username equals the email address of the user.
Note the difference with a password manager, that encrypts a database of randomly generated passwords using a master password. With the plugin there is no need to store any passwords anywhere, not locally, not somewhere in the cloud. The plugin generates them directly from the master password instead..
The most serious problem with this idea is password compromise. Because the (compromised) site specific password is derived from one master password, a new master password has to be chosen, which changes all other site specific passwords as well. As a consequence, all other sites need to be informed of the password change. Clearly an undesirable state of affairs.
There does not seem to be a satisfactory solution to this problem yet (unless you use the PwdHash approach, see below). One option would be to allow the user to select from a list of site specific passwords before submitting it. These could be generated from the master password by hashing in a sequence number. In that case the user needs to remember which one to use. Typically that would be the first from the list, unless the password for that site was compromised. This is similar to the case where a user has to select a different conversion strategy, as discussed above.
If the plugin could maintain state (which is the case if you only ever login to websites from one single computer), it could keep a list of all sites where your password was compromised and record from which position of the list of alternatives the real site specific password should be selected. This local state could also be used to store specific conversion strategies.
In case of site specific password compromise, PwdHash shows a clear advantage: you can pick a new master password for the compromised site and keep the old one for all others. The disadvantage is that you need to remember several master passwords. Moreover, in PwdHash you enter the master password in the actual password field on the page. By starting it with a special sequence ("@@") PwdHash recognises that it should hash the master password and replace it with the site specific password. If you forget to type @@, the master password itself is sent to the site. This is clearly a security issue. This could be fixed by changing the user interface of PwdHash, and forcing users to enter master passwords in a special area in the browser.
Another challenge pose sites that require you to change your password once in a while. This raises similar issues as password compromise discussed above.
Another issue with any scheme that uses a master password to derive the site specific password is that it should be easy to obtain a cleartext copy of the site specific password. You need this cleartext copy if you need to enter the password without access to the plugin: form a different browser, a different PC or smartphone, or on the console. And you need to be certain that the cleartext copy you get actually corresponds to the site specific password. It is important to have a very clear and standardised method for deriving the site specific password from the master password, so everyone can write a small software program or script (PwdHash has a JavaScript implementation on a special webpage that runs locally in your browser) to do this.
For portability, one can also make a mobile app for this. This is useful in cases where you are using a PC on which you cannot install the plugin. It is quite a bit more cumbersome of course. But at least you can sign in if you really have to.