Request for sanity in passwords. 

Passwords, and our need to remember vast quantities of them, are one of the uncomfortable nescessities of modern-day life on the net. To access our bits of the cloud without needing to rely on a single machine to do it from, to provide our credentials, are tasks we have – almost without thinking – entrusted to classic text-mode computer science processes.
While biometrics (such as fingerprint readers and iris scanners) are showing up on more ‘business’ laptops, they’re still only a local solution – there’s no standardised mechanism to send a fingerprint to a website for authentication, and once you’re sending electronic data, you can’t be sure whether the source was the authentic finger or falsified captured data, leaving you in a no-more secure (but less demanding) position anyway. Should your authentication token – your fingerprint – be compromised, it’s exceedingly difficult to change, but does offer the benefit of not relying on human memory for storage. Other people swear by automated password managers, but these are locked to a piece of hardware, and a battery, both of which will fail when they are needed most.

While we’re stuck with passwords, we should make them as painless as possible to use. My personal process is to have three passwords, at differing levels of privacy:

  • A ‘public’ password, which I use for accounts I share with friends and do not care about compromising
  • A private password, which I share across a number of services
  • A high-security password, which is super-secret and only used for services which involve money, or present themselves as an authentic me

Anecdotal experience tells me a lot of people rely on similar schemes. This is a common approach, but did anyone tell security and sign-on developers? Seemingly not because this conflicts hugely with how many websites operate. While humans exist in a world where the aim is to minimise password redundancy (ie, memorising as few as possible), many online accounts aim to maximise password uniqueness: the password must be between 4, 6 or 8 and 8, 10 or 20 characters in length; it cannot or must contain special characters, which may include or preclude any, all, or some of dollar signs, pound signs, punctuation, underscores, accented characters and spaces You can or cannot start the password with a space, if that was a permissible character. They often seem designed to best suit the security or IT manager’s existing password schema, and I imagine there’s a fascinating study out there about this already.
It’s a wild-west of password requirements, basically, but human ingenuity always finds a way. We trim our passwords to suit the per-site rules, eliminating that now-illegal space, duplicating phrases to reach the minimum letter count. We do all in our power to preserve the spirit of the password, within the constraints of the rules.
Here’s some of those rules, pulled from a random website.It tells me the rules only after I propose my sign-in password (looks like the other davemee beat me to signing up here too). Ideally, it should have let me know in advance, but at least it tells me. Let’s review the constraints it’s imposing here:

  1. Longer than 6 characters
  2. Less than 12
  3. Contain at least one letter
  4. Contain at least one number
  5. Contain only letters and numbers

This eliminates at least one of my passwords, the one I’d typically use for the level of security required here. I need to change it to conform.

On the same site, contrast with the login page (pictured below).
Without recording the site and credentials somewhere, my presumed login would fail here. I know which account I’m likely to have used, but without knowing the constraints imposed by the site, I would never be able to derive the correct password. When I enter my (illegal) credentials, it tells me my login details were wrong, but makes no mention (nor reminder) of the restrictions imposed on the password – I’d only find this out by creating a new account and having the password rejected a second time.

I’m not singling this site out, whoever they are – lots of sites do this. What disappoints me is this is such standardised, minimum-effort behaviour, which could be turned around with so little work to make the world a better place. We’d have less misleading sign-up figures from the bigger websites, more honest advertising figures, and better preservation of online identity. Sign-up, -in and -on interaction would stop being a hurdle and start being part of a sane, simple transaction.

Recommendations

I have a few ideas about what could be done here; I propose a SOS (sign-on sanity) group or marque that would guarantee predictability of registration. Minimum requirements would be to

  • Spell out admissible characters for passwords, at both account creation and log-in time (this could be inline in the page, or as a popup display)
  • Make explicit how case is treated, accented and non-latin characters are treated, and minimum/maximum size requirements
  • Not impose back-end details on password choice; for example, banning leading spaces, banning dollar signs, backslashes and other ‘escapable’ characters

I also propose a full-compliance award, which would involve the above as well as

  • A standardised set of acceptable characters, with a link to the SOS website where the characters would be made explicit
  • Visible feedback (flashes, error highlights) when an inadmissable character is entered into a password field, without stating what that character is (‘the 5th character entered was bad’ rather than ‘% is not a permitted character’), for browsers supporting this functionality.

With this approach, the guesswork is eliminated from password recall, and the need to rely on external tools, whether paper or software, is greatly diminished. There would be fewer aborted registrations and less overhead from users having password-related issues at sign in, all the while requiring no major infrastructure changes, and only minimum additions to a few pages for site managers and administrators.