Is our entire password strategy flawed?

2014-06-19 by . 8 comments

Post to Twitter

paj28 posed a question that really fits better here as a blog post:

Security Stack Exchange gets a lot of questions about password strength, password best practices, attacks on passwords, and there’s quite a lot for both users and sites to do, to stay in line with “best practice”.

Web sites need a password strength policy, account lockout policy, and secure password storage with a slow, salted hash. Some of these requirements have usability impacts, denial of service risks, and other drawbacks. And it’s generally not possible for users to tell whether a site actually does all this (hence plaintextoffenders.com).

Users are supposed to pick a strong password that is unique to every site, change it regularly, and never write it down. And carefully verify the identity of the site every time you enter your password. I don’t think anyone actually follows this, but it is the supposed “best practice”.

In enterprise environments there’s usually a pretty comprehensive single sign-on system, which helps massively, as users only need one good work password. And with just one authentication to protect, using multi-factor is more practical. But on the web we do not have single sign-on; every attempt from Passport, through SAML, OpenID and OAuth has failed to gain a critical mass.

But there is a technology that presents to users just like single sign-on, and that is a password manager with browser integration. Most of these can be told to generate a unique, strong password for every site, and rotate it periodically. This keeps you safe even in the event that a particular web site is not following best practice. And the browser integration ties a password to a particular domain, making phishing all but impossible To be fair, there are risks with password managers “putting all your eggs in one basket” and they are particularly vulnerable to malware, which is the greatest threat at present.

But if we look at the technology available to us, it’s pretty clear that the current advice is barking up the wrong tree. We should be telling users to use a password manager, not remember loads of complex passwords. And sites could simply store an unsalted fast hash of the password, forget password strength rules and account lockouts.


A problem we have though is that banks tell customers never to write down passwords, and some explicitly include ‘storage on PC’ in this. Banking websites tend to disallow pasting into password fields, which also doesn’t help.

So what’s the solution? Do we go down the ‘all my eggs are in a nice secure basket’ route and use password managers?

I, like all the techies I know, use a password manager for everything. Of the 126 passwords I have in mine, I probably use 8 frequently. Another 20 monthly-ish. Some of the rest of them have been used only once or twice – and despite having a good memory for letters and numbers, I’m not going to be able to remember them so this password manager is essential for me.

I want to be able to easily open my password manager, copy the password and paste it directly into the password field.

I definitely don’t want this password manager to be part of the browser, however, as in the event of browser compromise I don’t wish all my passwords to be vacuumed up, so while functional interaction like copy and paste is essential, I’d like separation of executables.

What do you think – please comment below.

8 Comments

Subscribe to comments with RSS.

  • jww says:

    Could you define “password strength policy”? Does it include complexity and rotation requirements? If so, complexity and rotation requirements do not work. Complexity does not work because the bad guys know what to try from all the past data breaches (they are wise to ‘Password1’ and friends), and passwords like ‘Password1’ meet NIST complexity requirements. You get diminishing returns on password rotation, so passwords effectively get weaker over time. You would do better with a password black list based on word lists and past breaches to rule out what the bad guys will try. Multi-million entry password lists can be encoded into Bloom Filter under 50KB or so. Its not even a large footprint.

    • roryalsop says:

      This comment isn’t really relevant. We already know current complexity rules breed weaker passwords (as discussed on xkcd etc)

    • Chris Murray says:

      Surely your proposal of a password black list will also have diminishing returns. It won’t force users to use stronger passwords, it’ll force them to find ways around the black list.

      Further, with new breaches happening all the time, the black list will continue to grow, presumably for ever until all possible passwords are no longer valid.

  • jww says:

    “A problem we have though is that banks tell customers never to write down passwords” – yeah, banks are a real shining light. Are they the same banks using HTML5/CSS/Javascript with the web security model? Or the picture as the second authentication factor?

    The threat is unauthorized network access and facilitated by weak, memorable passwords. Writing down my password and then losing my wallet or desk drawer is down at the bottom of the list. Hell, even password reuse is a greater threat.

  • SILENT says:

    I believe we need an ISO standard interface established between Password Managers and Websites. You would have one strong password for the password manager (from whatever company(ies) that create the app(s)). The password manager will automatically change/update passwords based on whatever new security protocols available.

  • Orr says:

    There’s a technology that also presents to user like single sign-on, but technically is a hardware device combined with a password manager.

    This combination frees a user from the need to pick strong passwords. It is also safer than just having password manager, because a hardware device plays a second factor. At the same time if the device is lost – no problem, it can be revoked and the credential data is safe.

    Hardware devices come in deveral different types. Some just store master password, some are basic OTP tokens, others store your credentials encrypted in the cloud, so you can never really lose them. I think the latter is the best option provided that credentials are encrypted and handled wisely.

    There’s one more important point which is often forgotten: not only users should care about login security. Websites’ task is even harder. And you’re right – user can never know for sure that the website is reliable. The suffering can be mitigated if websites make more use of 3rd party secure login or OpenID technologies. Most work about storing credentials could be done by a reliable authentication provider.

    There is a technology called WWPass that combines safe password handling, hardware device and added security on the sebsite side. I guess this is a technology to keep an eye on, it is potentially game-changing.

  • password manager

    To me this is a big no no, you’re relying on only one password, the one you’re using to unlock your password manager. If this password would come to leak then all your passwords would be compromised.

    A good solution would be to: * use a password manager (that does all the work for you) for websites you don’t really care. * use passwords you memorise for websites you care about (You could hash the name of the website in your head to make a password with what one of the Blum proposed (http://www.scilogs.com/hlf/mental-cryptography-and-good-passwords/)) * use multi-factor auth (I like the yubikey) for critical websites.

  • I can’t seem to edit my answer. I wanted to add two things, when I talk about a password manager I’m talking about something like 1Password. I also wanted to add that I don’t do what I just said because I’m lazy.