LastPass' password meter is broken | Hacker News Reader

LastPass' password meter is broken

hexatomium.github.io

17 pointssvenfaw9 comments

If the previous "security vulnerability" reported to LastPass was like this one, it's understandable why they didn't really respond to it - the author doesn't really seem to understand the term.

You don't keep mashing the "generate password" button until you get a "strong one", that completely misunderstands the point of the password strength meter. Its only purpose is to give naive users positive feedback for creating stronger passwords; it has nothing to do with randomly generated passwords.

> dict size: 18 length: 10

I'm assuming "dict size" is the count of possible characters (see how it's 10 for the previous example). For the second example a dict size of 18 presumes the attacker is generating passwords with only those 18 characters that are used. It's true that the first example would be about 1.4 orders of magnitude slower to crack than the second. In the only digits case a cracker would try only digits because passwords with only digits are somewhat common (not usually that long though) and quick to check to fairly large length. But in the second example why would someone brute-forcing a password only try those exact characters?

Now I want to check my passwords list to see how many fit this profile of only having those 18 characters. Then see what character sets are most common overall (I already have a script to calculate the most common masks are (using the oclhashcat definition of a character mask)), but I never thought sets of individual characters would be that useful.

Making sure you have unpredictable upper and lower case letters, numbers and symbols with a not unreasonable length of 14 would force an 8 GTX 1080 rig (about $5200 US for just the video cards) to take 386 thousand years to crack on average assuming MD5 for the hash function.

That argument baffled me as well. Using the 'dictionary size' defined by the distinct set of characters as an input for the entropy calculation seems absurd, unless the attacker has a way to know the dictionary, for instance because they know a login can be made using a numeric keypad alone.

Also, with that definition, a password 'abcde' would have much higher "entropy" than 'aabab', meaning that this measure penalizes actual randomness, where repetition and char-reuse are very likely.

Why should something like this prevent you from using lastpass. And who is really trying to use short or numeric passwords anyway. I just have lastpass set to A-Za-z0-9+Specials @ 27 characters and leave it that way unless a site won't accept it.

The password meter "strength" feature is just silly UI in general.

I think this is the function from the LastPass source code that's calculating the password strength:

    var p = function(b, f) {
        var a = 0;
        if ("" === f && "" === b)
            return 0;
        var c = b.toLowerCase()
          , d = f.toLowerCase();
        if (c === d || d && -1 !== c.indexOf(d) || d && -1 !== d.indexOf(c))
            return 1;
        a += b.length;
        if (0 < b.length && 7 >= b.length)
            return 1;
        8 <= b.length && 15 >= b.length ? a += 12 : 16 <= b.length && (a += 18);
        b.match(/[a-z]/) && (a += 1);
        b.match(/[A-Z]/) && (a += 5);
        b.match(/\d/) && (a += 5);
        b.match(/.*\d.*\d.*\d/) && (a += 5);
        b.match(/[!,@,#,$,%,^,&,*,?,_,~]/) && (a += 5);
        b.match(/.*[!,@,#,$,%,^,&,*,?,_,~].*[!,@,#,$,%,^,&,*,?,_,~]/) && (a += 5);
        b.match(/(?=.*[a-z])(?=.*[A-Z])/) && (a += 2);
        b.match(/(?=.*\d)(?=.*[a-z])(?=.*[A-Z])/) && (a += 2);
        b.match(/(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!,@,#,$,%,^,&,*,?,_,~])/) && (a += 2);
        for (var c = {}, e = d = 0, n = b.length; e < n; ++e) {
            var l = b.charAt(e);
            void 0 === c[l] && (c[l] = 1,
            ++d)
        }
        if (1 === d)
            return 2;
        a *= 2;
        0 > a ? a = 0 : 100 < a && (a = 100);
        return a
    }

I think "b" is the password and I'm guessing that "f" is the username.

In these kinds of conversations, I always find this xkcd to be very relevant: https://xkcd.com/936

This comic is just that, a comic. It doesn't take in to account any modern computational considerations. Ignoring the fact that people are still picking these words from their limited vocabulary and likely basing it on their own experiences...

Almost any computer can guess astronomically more than 1k/s.

A simple multi-GPU system can easily break a 1B/s.

Hash algos have a cost and they're different; from MD5 to SHA1 to bcrypt. Hash rates vary wildly.

And then, of course, there are the people who take it a little too literally and actually use "correcthorsebatterystaple" as their password ;)

http://qz.com/501073/the-top-100-passwords-on-ashley-madison...

> Ignoring the fact that people are still picking these words from their limited vocabulary and likely basing it on their own experiences...

If people are doing so, then they've missed the point of the comic (which is basically just demonstrating the merits of a "diceware" password generation scheme). One should be generating these passwords actually-randomly (e.g. by rolling dice and picking words corresponding to the dice roll, or (less ideal but more practical) by using a program which picks the four random words for you). The whole point is to make a password that a human can remember without relying on the human to actually come up with said password on one's own.

> Almost any computer can guess astronomically more than 1k/s.

Sure, if they have direct access to the hashes (assuming the passwords are even being hashed...). The comic's threat model instead assumes that the brute force attempts are through "ordinary" means (like using an actual login screen), at which point 1k/s is pretty high even without factoring in things like account lockouts. This is actually made pretty clear in the comic itself (at least so I thought).

Even with direct access to the hashes, though, the resulting passwords are sufficiently-long that they'd still take a rather long time to brute-force even with high-end computers (at least compared to the sorts of 6-to-14-character passwords most people use). This rather long time is made even longer if the attacker doesn't actually know that the victim is using a CHBS-style password.

That's the key thing here: they're long without being difficult to memorize, and length is generally accepted to be the most important consideration (aside from ensuring the password is unique across applications and not in a dictionary of commonly-used passwords) when resisting a brute-force attack.

Reply on news.ycombinator.com