A Plea to Web Developers

There’s a growing trend on web sites that require a login, and it is getting annoying.  And I can’t see any real upside to the decisions that web site designers and developers are making.
What I’m referring to is sites that attempt to disable password managers.  They’ll use all kinds of tricks, ranging from a simple ‘autocomplete=”off”’ to JavaScript that clears the form, to building form elements dynamically so they aren’t picked up by browsers or password managers, among others. 

I believe that they are thinking that this increases a site’s security by preventing unauthorized logins.  You know, someone other than the authorized user logging into the site, being able to do so because the password is automatically filled in.  While that makes sense, the bigger issue is that they are actually reducing the site’s security with this behavior.

Why do I say that?  Because it forces people to use really, really bad passwords.

In today’s world, there is basically no such thing as a “good” password generated by a human.  People notoriously pick passwords that are way, way too easy to crack.  Even when we think we are being clever, some hacker somewhere has already been just as clever and coded the method that we think is unique into a password cracking library.  Basically every method you’ve come up with for creating a password, a hacker has already done it.

So the only good passwords are those that are generated completely randomly.  Using what we call a cryptographically secure pseudo random number generator.  Only passwords created by a PRNG can be considered secure enough to thwart hacking.  They should also be long too – 12 characters at an absolute minimum.  These passwords are virtually impossible to remember, especially considering that every web site we visit should have its own unique password.  Honestly, could you remember your passwords if every site’s was unique and they looked like x^HsNpeGo}V%Xd~, [lfGY%KW$4McJ(3l, or Jo@Rl-p4Vc7Esy?  I seriously doubt it.  So people using good, secure passwords use password manager software to generate and remember these kinds of passwords for them.

(I can honestly say I have no idea what my passwords are on 99% of the web sites I visit. In most cases I’ve never actually even seen them.)

Unfortunately it seems that many web site developers think you can remember these kinds of passwords.  Otherwise they wouldn’t be trying to disable password managers.  They are intentionally trying to force you to remember your passwords.  So they’re forcing people into using passwords like “monkey123” or “k3lly@96” which they can remember, but would be cracked by a hacker in a matter of seconds (or even milliseconds), and since people are bad at remembering passwords they’ll reuse the same passwords on multiple (if not every) site(s).

So while their intended effect is to prevent unauthorized logins, what they’ve effectively done is make their user’s accounts much easier to hack.  Not only are their user’s passwords bad, they’re probably the same as another site that has already been hacked. 

Intended effect: improved security, actual effect: horrendous security.  The law of unintended consequences strikes again.

So, please, if you are in charge of designing or developing a web site, resist the urge to prevent users’ browsers or password managers from filling passwords in for them.  The site will be far more secure if you actually allow users to use secure passwords.

(While I’m on the subject, having a site suggest a secure password when a user creates an account isn’t a bad idea either.  It should be displayed on the page so they can see what it is, as well as pre-filled into the password fields.  Most browsers and password managers will automatically pick up on data pre-filled into those fields and save it for the user.  Oh, and always use HTTPS for any page that requests or displays account data.)

P.S. You can always get a truly random password from my web site.  The passwords aren’t saved anywhere, and only you ever see it.

P.P.S. If you aren’t using a password manager, you should be.  The one I like is LastPass.  If you’re concerned about your passwords being accessible to someone, just choose a really, really good password for your account.  These sites include your account password as part of the encryption key, so nobody can get to your password data without it.  And you can make it even harder to crack by turning on Two-Step Authentication too.

Why Web Sites Don’t Need to Store Your Password

It seems counterintuitive, but web sites that require logins don’t actually need to store your password.  And they actually shouldn’t – it is a very bad idea to do so.   We see too many leaks of account databases for it to ever be safe to store passwords in any form, even if encrypted.

So how can a site validate a login if it doesn’t store the password?  The answer is something really cool called a hash function.  I know your eyes just glazed over, but bear with me, the concept is actually simple.

A hash function is a way of processing data that is one-way… you can put data in, and always get the same result coming out, but there is no way to reverse the process to get back the original data.  I won’t get into the specifics of how hashes actually work, but I can describe a very simple hash that will illustrate the principle.

Say, for the sake of simplicity, we are creating a web site that uses a 4-digit PIN as a password to log in.  We know that storing the PIN itself is dangerous because it could be leaked out or viewed by site administrators, so instead we add up the four digits and store that sum.  So if my PIN is 2468, we store 20 (2+4+6+8) in the database.  When we go back to the site to log in, the site can add up the four digits we enter for the PIN, compare that result against the sum in the database, and validate that we know what the correct PIN number is.  A hacker that gets his hands on the database only knows that the sum of the digits is 20… he can’t possibly know that the original PIN was 2468.  They’d have to guess what the original PIN number was by trying different combinations.

Of course this is overly simplified.  This demonstration hash function wouldn’t really work in the real world because it is too easy to figure out combinations that would let hackers in.  This situation is called a collision… 8642, 5555, 8282, 1991, and 6446 all produce the same hash value of 20.  But real hash functions used for account login verification are much, much more complicated, and aren’t normally subject to problems with collisions.  But you get the idea.  Instead of storing the actual password, we store a value that is calculated from the password.  We can validate that someone knows the password without actually storing that password.

This has other advantages as well.  For example, using a hash function there is no limit to the length of the password, because hash result values are always the same length regardless of the amount of data going in.  Someone could enter 6 letters, or 200 random symbols, and either one can be hashed down to a value of a standard length that can be stored in the database. 

Because of this, you can sometimes tell web sites that don’t use hashes to securely store passwords because they enforce a maximum length for passwords.  This isn’t always the case, but it can be one indicator that the site’s security has been poorly designed.  But if you are signing up for an account on a web site and they have a low limit on the length of the password, like 12 characters, you might look for other signs of poor site security or privacy policies.  And definitely don’t reuse a password from another site.  Or just steer clear.

The down side to using hashes is that if you forget your password the site has no way of sending it to you… because they actually don’t know it.  That is why sites generate a brand-new, random passwords that they send to you via email when you forget your password.  They honestly have no idea what your password was, so the only solution is to create a new one and use that temporarily until you create your own.

The whole process is considerably more complicated than I’ve described here – or at least it should be.  Just using a hash isn’t sufficient, either, because we’ve got affordable computers these days that can calculate billions of hashes per second and are therefore capable of brute-forcing short passwords very quickly.  (A 6-letter password, for example, would be cracked hundreds of times over in just one second using a simple hash).  But for a site to use a hash on passwords is one step in the right direction.