Why you STILL can’t trust password strength meters

Why you STILL can’t trust password strength meters

13
325


Why you STILL can’t trust password strength meters


13 COMMENTS

  1. We all know about short and common passwords but how important is the way they are stored? At this point should salted and hashed be the standard? and is that secure enough. Also, most people don’t know how websites stores their passwords. And finally, no matter how good the password is and how well it’s stored, clever phishing, keylogger malware, or social engineering can still get the password.

    ]]>

  2. Storage is immaterial for online attacks and critical for resistance to offline attacks. As a user you should choose passwords to resist offline attack and hope the website’s got your back with correct storage. See https://nakedsecurity.sophos.com/2014/10/24/do-we-really-need-strong-passwords/ for more on this.
    Salting and hashing passwords isn’t secure enough by itself but it’s part of the solution – see https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/ for more on this.
    2FA can make phishing, keylogging and social engineering much harder.

    ]]>

  3. Anymore, something like the bCrypt standard is the best way to go, especially with it’s configurable stretching. If computing power get to the point where your stored passwords aren’t as safe, you can easily increase the number of stretching rounds. Set your site so that passwords get re-hashed on a successful login and the new hashes get propagated.
    Even at that, though, it’s not a bad idea to take a final step and store your password database separate from your application database. Different database, different server. Preferably accessed via a web service also not hosted on your application server, in case you’re using a platform that forces you to store your connection string in a text file on the server (Looking at you there, Microsoft), that config file is elsewhere. That way if/when your application database gets compromised, your passwords aren’t available.
    Bottom line is that there’s no way of truly securing a website- the HTTP protocol is working against you. HTTP was build to be open an unrestricted communication and every measure taken to change that is an imperfect bolt-on. The trick isn’t to make your website unbreakable. You can’t. The trick is to make your site more hassle than it’s worth.

    ]]>

  4. Mark, Did you mean to spell Mediocre correctly in column 3, line 4 of the table, or to reproduce a typographic error there?

    ]]>

  5. I see “mediocre” spelled correctly in the table, but misspelled in the text below it, just above the section heading “Recommendations”.

    ]]>

  6. and if someone makes a password strength meter just to harvest passwords for their library,,,, I’ll just trust my creativity… 5er!0us1y (no I don’t use anything that simple)

    ]]>

  7. I don’t understand your use of the term “ringer” with respect to the zxcvbn strength meter; I’ve always understood a ringer to be a bogus entity, which zxcvbn certainly is not. And I’m further confused by your contention that you have proven the fallibility of password strength meters, when you show that zxcvbn, unlike the others, rejected all of your poorly chosen passwords. You even go on to include it in your recommendations!
    Eh, what’s up, doc?

    ]]>

  8. zxcvbn is a ‘ringer’, a bogus entry as you say, because it did not meet the entry requirements for the test – it did not come up in the top 5 results when I Googled ‘jQuery strength meter’. Also I knew it would pass.
    The scenario in which people commonly encounter password strength meters, and in which I contend you can’t trust them is as follows:
    You visit a website for the first time and create an account. The account sign-up page asks for a password and has an embedded password strength meter. You try out a few passwords until you find one that’s ‘strong’. Can you trust that assertion?
    There is a slim chance that the site is using a well designed and rigorously tested password strength meter like zxcvbn but you won’t know if it is and there is a very good chance it’s not.
    The web is awash with password strength meters, and tutorials on how to code password strength meters, that use entropy calculations (and policies that force you to use capitals, special characters etc that actually *reduce* the number of guesses an attacker has to make.)
    If you’re a user, these are the strength meters you’ll encounter and if you’re a developer these are the strength meters that are easiest for you to find and integrate.
    The existence of zxcvbn doesn’t make password strength meters trustworthy any more than the existence of vegetarian lions makes it safe to put your head in a randomly chosen lion’s mouth.

    ]]>

  9. I understood “ringer” to mean a substitute that no one would suspect, but that was deliberately chosen to be better than the rest of the field. Like when you’re playing cricket in the Eighth League, comfortable but competitive in a fair matchup with other duffers like yourself, and one Saturday morning you find yourself opening the batting against a bowler who’s metres quicker that everyone else, and unrelentingly accurate, and can hit the seam every time, and your head whenever he wants. Later, after the match, when you’re counting your bruises and looking at the fixture list to see who you’re playing next week, you suddenly realise that the opposition’s Second League team suspiciously had the week off. That’s a ringer.

    ]]>

  10. “The only good way to measure the strength of a password is to try and crack it – a serious and seriously time consuming business that requires specialist software and expensive hardware.” I’m not sure this is true. What makes password cracking so difficult is all of the hashing, but a password strength meter would have access to the plaintext password. So it should be a lot easier to, say, look for a dictionary word in the password and consider it weaker; same with common substitutions (e>3, a>@, etc.).

    ]]>

  11. Not having to crack hashes makes guessing passwords easier but there are other environmental factors that make it a challenge in this case.
    Efficient cracking of password hashes is hard but it’s done with specialist software that knows how to massively parallelise calculations across multiple GPUs, running on dedicated hardware and in an environment where waiting for minutes might be considered fast.
    You don’t have to crack hashes in a password strength meter but your software will be written in javascript, has to run in mobile phone browser without blocking every other process and anything other than an instantaneous response would be considered slow.
    That said, what you seem to be describing is something else – looking for giveaways within the password, such as the use of dictionary words, rather than actual cracking. Your approach is a good description of what zxcvbn does.

    ]]>

LEAVE A REPLY

Inline
Inline