
LastPass' password meter is broken - svenfaw
http://hexatomium.github.io/2016/09/05/lastpass-password-meter-broken/
======
belovedeagle
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.

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

~~~
cmenge
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.

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

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

------
banterfoil
In these kinds of conversations, I always find this xkcd to be very relevant:
[https://xkcd.com/936](https://xkcd.com/936)

~~~
h4waii
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.

~~~
yellowapple
> 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.

