1. 18
  1.  

  2. 8

    While the article is correct on several major points (ultimately passwords should die; every article on “how to choose a password” should start with password managers), but I think it’s completely wrong when it suggests that dictionary-attack resistance is more important than password entropy (provided, of course, that it’s talking about entropy lower-bounds; entropy upper bounds, as computed by password strength checkers, are only somewhat useful). A high-entropy password is necessarily, by the very definition of entropy, dictionary-attack resistant.

    1. 8

      Don’t use passwords, put all your eggs in one basket. I’ll be honest I use a password manager myself, but I’m not certain it’s the best strategy. If there’s a single flaw in how that password manager is written that you’re not up to date on you could be up a creek without a paddle. Especially for lay users who will inevitably gravitate towards passwords as a service, and well this is even MORE risky.

      1. 8

        Yeah. I think we are in the situation of just choosing the least awful solution (and bolting 2 factor everywhere we can).

        1. 1

          Assuming you don’t create a new e-mail address for each service you sign up for, your eggs already are in one basket.

        2. 1

          […] the single most useful criterion on which to classify the strength of a candidate password, is the frequency with which it has appeared in the past.

          In my first job (~12 years ago) I was surprised that they did just that. Of course, it was an easy check to do because they stored the passwords in clear text. (sob!) The quote above set me thinking, however: how do you ensure that a password is unique if you cannot store it, even in hashed form? Best practice means including a random salt, so there’s no way to check that two passwords are the same using the produced hashes. And this is a Good Thing because it protects against rainbow table attacks!

          One way would be to use a Bloom filter. However, since you did not retain the source data you’ll have to think very hard about the properties of your bloom filter up front. Alternatively (or, as a mitigation for that) you could store a hash of the passwords somewhere not linked to the user choosing it using the same (secret) salt for every password. You could either use this to rebuild your Bloom filter if you have to resize it (yay! many users now!) or you could index them directly and skip the Bloom filter.

          Now you have a new problem: If someone gets hold of your bloom filter or password uniqueness check index, they have a very fast way to check if a password is (or has been) used on your site. They only have to break a few, I imagine, before they can deduce the common salt. Then it becomes just a case of figuring out which user it belongs to. Not all sites have as many users as Facebook, so this I imagine is quite feasible for even small computers nowadays.

          Back to the drawing board…

          1. 2

            Best practice is to use a slow key derivation function like bcrypt/scrypt/PBKDF2.

            Now you’ve got two problems: how do you securely perform a uniqueness check is bad enough, but how you do it when what you’re storing (the hashed form) should take at least a second to calculate every time.

            1. 2

              Heh, yes. Forgot about the “slow” part :-)

          2. 1

            Are there any password managers out there that work on desktop (Mac and Windows, minimally) and android mobile platforms that actually have some kind of two-factor authentication? Ideally on my phone use my fingerprint and otherwise send a text message or something.

            I’d rather use a single management solution and pay attention to its specific rigor than need to second-guess every website and app’s security practices continuously.

            Edit: LastPass does these things, I’m going to give it a try.

            1. 1

              Wasn’t lastpass acquired by logmein or something?