A recent discussion got me thinking about what might be the right number of passwords. There are plenty of references that still say you should have a different password for every service, and breaches such as Adobe’s last year show why. If you use the same password on two different websites and one of those gets compromised, either by phishing or loss and cracking of a password file, then both accounts are put at risk. So when you hear of one such compromise you have to try to remember which other websites you’ve used that password on, visit each of them and try to work out how to change to a new password.
But, honestly, there’s no way I could remember a different password for every service and website I use every day, let alone all the occasional ones that I need once in a blue moon (and usually have to reset when I want to revisit the site anyway). I’d be surprised if any of our users can, either. So what’s the solution? I hope a couple of relatively new technologies can help…
Single-Sign-On (SSO) is sometimes criticised for having the same “shared fate” issue as reusing the same password on multiple sites. Yes, if your SSO password is compromised then the person who now knows it has the ability to access your accounts on all the SSO services. But there are a couple of key differences. First, the SSO password only needs to be stored (salted and hashed, please) in one place – the SSO authenticator. So there are many fewer opportunities for someone to steal the password file, and the SSO authenticator is a sufficiently critical system that it should be being well managed. Second, if the password is compromised then it can be immediately disabled and changed in a single location: I don’t have to go around all the services individually to do it. And, because the SSO authenticator is a well-managed central point, I’d expect it to have a better chance of spotting any unusual login patterns that follow a compromise too. So for my work accounts SSO, preferably federated so I can also authenticate to other organisations’ systems, looks like a good bet.
That leaves me with all the other external sites I use for information, to book conference places, tickets, etc. etc. Many of them now offer logins using social networks, but I’m not comfortable with the amount of information sharing that that involves. Instead I’m sticking with a unique password for each service, but using a password vault to manage and in many cases generate them for me. That does make the password for the vault a critical part of my security, but that one is much longer than any feasible rainbow table so should be crack-proof. Also (like my federated SSO password) I only ever have to type it into a single, familiar interface so the risk of phishing should be reduced too. If I ever lose access to the vault then I’m back at requesting password resets, which was my fallback position for most of those accounts anyway.
Sadly, although the number of passwords I have to remember is greatly reduced by this approach, it’s not down to just two. Some sensitive services use two-factor authentication, but I can cope (so far) with the small pile of dongles, tokens and phones. But there are some other “password-protected” sites that are neither federated nor usable via a vault. Interestingly, whether they realise it or not, they’ll never know whether I have re-used their password on someone else’s service. At least not until that service gets compromised…
Comments, as ever, welcome…
