You are here
- Home
- Regulatory Developments
- Blogs
- How Many Passwords?
Group administrators:
Recent members:
How Many Passwords?
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...
Comments
I like the idea of single-sign-on, and I would definitely support using it, but I worry about making all systems accessible via one weak password, so we also need to do more to get users using strong passwords.
For convenience, I support using SSO for most student systems (virtual learning environment, email, intranet) but not for more sensitive systems such as student records.
I found the reference to 'login via social networks' interesting. You could argue that this is offering a single-sign-on option, but, like you, I'm not at all comfortable using it. Which begs the question, why am I prepared to put more trust in the security provided by my public sector employer than I am in that provided by a multi-billion dollar private sector corporation? I suspect that this is less about security and more about integrity.
Absolutely - if you have to remember fewer passwords then spend a bit of the time and memory space you save by making them (even) better ones. But if your users are using the same weak password everywhere then using SSO doesn't make it weaker, and it does give you greater ability to disable it.
And even with a strong password there are definitely some applications where you want more. I do wonder, though, whether a technically "strong password" (essentially, something proof against rainbow tables) is actually pretty close to the limit of any individual's capability, so "more" may actually mean two-factor of some kind? There are some thoughts on that in a previous post.
For me the issue with social network login isn't whether the authentication system is better or worse, it's what else they do might do with the knowledge that I logged in to *that* system, then *that* one... With my employer I'm more confident that it won't be re-used for surprising things. I'm not sure whether that's what you meant by "integrity"... ;-)
Johannes B. Ullrich of the Internet Storm Center recently came up with a brilliant, but very simple, way to protect against the compromise of password safes....
"For important sites that don't allow for two factor authentication, consider a "two-part password": One part will be kept in your password safe, while the second part you type in. The password safe part is unique to the site while the additional second part can be the same for different sites or at least easy to remember. This will give you some protection against a compromised password safe.
Something I've used for less sensitive logins (blogs, photo sharing etc.) is PwdHash. This hashes the password you type with the site portion of the URL to create a unique password. Thus you can therefore remember a single password for use on multiple sites, but when you log in each site receives a different password from the browser.
It does have some problems - if the site portion of the URL where you change your password is not the same as the site where you login, you can't get in, as the password hashes are different. However, I've only found a couple of sites where this is a problem.
There are plugins for Firefox and Chrome. If you're not using your own device (or a device with the plugin installed), you have to visit a webpage to hash your password for you. However, the Javascript page can be downloaded to your own PC/laptop and used there, so your unhashed password never leaves your local machine. The Javascript code is pretty short and to my untrained eye doesn't look to be doing anything untoward with the unhashed password.
Just in case anyone is trying to re-implement that, I think there needs to be a little more to it. If the only things in the hash are the password and the login site name, then I wouldn't have thought including the login site name changes the number of guesses you need to brute-force decrypt a hash value stolen from website B, because you already know the login site name so you can include that in your guesses! If the pwdhash hash function is slower to calculate than the website's own one then each guess will take longer, though, so that may be where it wins. And once you get the cleartext password for one site, I'd have thought you could just add another site name to that, caculate the hash value forward (maybe using pwdhash itself!), and you're in?
That's a slightly different attack to the one that seems to be described on the website, so I hope they've updated the software to take account of it. And I'm definitely not a cryptographer, so may well have missed something.
I'm in full agreement that if the hackers who'd stolen my hashed password knew I'd used PwdHash, it wouldn't be any more secure. However, for hackers unaware of this, if obtained unhashed, or if they managed to brute-force the original, it would only work for the one site. Only if they realised I'd used PwdHash would that render it no more secure. Clearly if PwdHash became very popular this might become an issue.
It's also worth noting that the PwdHash algorithm produces longer passwords than the unhashed passwords that are used to create them. If I hash password123 and www.google.com I get 'oDWsVkXNO1GpD' as the hash. You'd be less likely to succeed in brute-forcing this string from its hash stolen from the web host (again unless you realised that PwdHash had been used).
As mentioned in my post, I don't use this for particularly sensitive sites. My view is that it gives you modest additional protection against a password (either hashed or in plain text) stolen from a web host being succesfully used elsewhere.
The obvious weakness to this method is that if we were to implement it / recommend it to users then we would be advertising to the world that our users used this tool. In other words it's really only 'better' if it's one of a large number of alternative approaches taken by a large number of users.
I would prefer to educate users and have them choose their own ways of generating (and remembering) strong passwords. It's often unpopular with management, but I favour giving users gentle reminders about how good / bad their passwords are as encouragement to them to do better.
Mind you, I also favour proper risk assessment and forbidding even senior managers from taking certain information off-site or accessing certain systems from off-site. That's not popular with management either.