Most users rely upon a small number of passwords — often only one — that they use everywhere.
For their corporate domain account, their blog, their photo site, their email, their banking and PayPal accounts, and their discussion groups, one key opens them all. Despite the incredible risks involved with this practice, it is more prevalent than ever.
Password reuse is often a learned habit of jaded users who’ve been bitten by the “lost password” bug a few too many times, especially against sites that they seldom visit. Automated password management systems, such as those built into just about every browser now, help lubricate the usage of more secure passwords, but their single–PC implementations and data loss potential has many shying from trusting them.
It’s so much easier to remember one or two password derivatives than it is to remember dozens.
Of course, few will actually admit to recycling passwords like this, and instead it’s the guy using unique 20 character random sequences that are most likely to speak out. Impromptu prodding of acquaintances, clients, and contacts, along with the results of several recent security surveys, has me convinced that these security best-practice aficionados are the exception, and a large number of users, perhaps even a majority, are dangerously reusing the same password prolifically. Look at the outrage and fear when a site like Reddit loses their user’s plaintext passwords (it is hardly alone in having this happen). Of course the users could simply change their password, but the source of the outrage was because this was the one key for many of these users.
If someone discovers your password on site A, there’s a very good probability they can use it to access site B, and C, and D, and E, and so on (especially when your username is your email address). The security of your online reality relies upon faith in a lot of people who you shouldn’t have faith in. The weakest link can make it all unravel.
On sites that I’ve architected, I’ve tried to minimize the potential damage of a hypothetical exploit by eliminating the target surface area.
Following this philosophy, not only do I not want to store your password — of course I only store a hash and not your original password, which should be a universal practice even among “low value” sites — but I never want your probably-reused password ever hitting the site in the first place.
Instead of sending your password to be hashed on the server, I want it hashed on the client end, before it even gets sent down the wire.
The SHA1 algorithm is easy to demonstrate (albeit also extremely easy to “crack” — it was built for speed — so don’t use it in practice), so in the example I used the excellent SHA1 implementation by Paul Johnston. Implementing it was trivial, and a simple example demonstrating how to use it for this purpose follows.
Note that this is purely an example, and in the wild you would want to use something much more computationally demanding, such as multi-rounds of blowfish. Something that makes brute force matching much more unreasonable.
<input id=”passwordHash” type=”hidden” value=””>
Email Address: <input id=”emailAddress” type=”text”
Password: <input id=”password” type=”password”
<input type=button onclick=”DoLogon();” value=”Logon”
<input type=hidden id=”variant” value=”” />
var username =
var password =
var hashString = password + ‘|’ + username + ‘|’ + document.domain;
var hash = hex_sha1(hashString);
document.getElementById(“passwordHash”).value = hash;
/* Remove the password element from the form before
/* Submit the form. */
Of course this scheme still suffers a critical weakness: If, somehow, a nefarious agent could replace the server side scripts, and somehow my remote server validation scripts failed, they could simply alter it to pass through the original password. While that scenario is far more remote and unlikely than the already remote and unlikely database delving or line monitoring, it does demonstrate why the optimal situation would be intrinsic browser support: Instead of creating a site-specific custom script to secure and individualize the password for a specific domain, which allows users to reuse passwords without actually giving the password to any specific site, the browser should support this functionality directly, and it should be uniquely evident in the UI when such a secure password element is in use.
In addition to the password input type, there should be a secure password type (with obvious, non-spoofable graphical indicators that it is a secure password box) as a basic HTML element, automatically incorporating this sort of enhancement. HTTP already supports digest autentication, which is similar, but unfortunately it is incompatible with the form logon approach commonly used, not to mention that it has its own failings.