Is our entire password strategy flawed?

2014-06-19 by . 5 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.

5 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)

  • 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.

  • Ken says:

    There is a simple hardware solution to the password problem. I have been using this for several years, waiting for a better solution to trump it, or a major flaw to be uncovered. See passwordbooster.com. It is a patented USB device that I keep on my keychain. It impersonates a USB keyboard so no software is needed and it works everywhere instantly (anywhere you can plug in a USB keyboard). I use it everywhere – PC, MAC, Linux, home, office, work, primary computer logins, remote desktops, VPNs, virtual machines. Here is how it works: I have a SEED password of 8 characters that I type in first, then I press a button on the device which sends out 6 left arrow characters (moving the cursor back to near the beginning of the SEED, then it sends out a set of alphanum chars and right arrow chars. The end result is a 15+ character password in the password edit control ready to be sent to the host computer. The SEED just protects the physical loss of the device – you need both the seed and the device to recreate the strong password. I use the raw superpassword for laptop logins, server logins, etc. For web sites I use PwdHash on the client browser with the same SEED and device. This gives each site a domain-specific strong password that cannot be cracked using brute force. Any one stolen hash cannot be cracked with brute force, so loss of one site cannot affect other sites. I have been using this device since 2006 across many jobs (software engineer) and have never forgotten a password. All my passwords are 15+ random characters. If password aging is needed for a corporate password, I reserve one button that I can generate the a new boost every 30 days, but my SEED remains the same. I can recall the last 2 generations of boosts.

    The only downside to the device is having to carry it around everywhere on my key chain, but I have developed a habit. I can clone the device so I have two exact devices and I leave one at home. I use a password manager, but I have now started eliminating the database manager since PwdHash is so available. I like not having to carry a password database around on every computer.

    Sorry for the long post, but I am just now getting back into trying to market it, since no other solution has come along in 9 years. I am a little surprised how well PwdHash works with the device. I know that the hashing algorithm it uses is old, but the password is 15+ characters, so it should still work for now.

    The one problem with PwdHash that I am now working to overcome is the fixed encoding (password alphabet). I am planning to develop a web service that allows folks to provide voluntarily the password policy of problematic sites. I know that my bank has weird rules and there are others. So I plan to implement PwdHash in a way that allows updates from this password policy database so that PwdHash (or its next generation) can make encoding decisions for sites that have special policy rules.

    Anyway my patent is “Password Enhancing Device” look it up on Google if you are interested.

  • Leave a comment

    Log in
    with Stack Exchange
    or