Comment by nickjj | Hacker News Reader

Comment by nickjj | Hacker News Reader

In the comments on Reddit someone linked to a podcast where they broke down what this really means in terms of how "secure" your leaked encrypted vault is.

The TL;DR is even with 100k+ iterations of PBKDF2 an attacker can crack a password with 40 bits of entropy in about 71 days if they had access to 200 modern GPUs. For comparison if there were only 1 iteration instead of 100k the same type of password could be cracked in 61 seconds.

50 bits of entropy changes things a bit. Now it takes 1 year instead of 71 days but if you're a high value target they can just ramp up the number of GPUs to reduce the time.

The difference between 40 and 50 bits of entropy for a password look like this:

    40 bits: !climb33
    50 bits: ClimbS1@
    40 bits: any 9 lower case letters
    50 bits: any 11 lower case letters

The takeaway I got is you're probably ok if you have a really good password (150+ bits) with 100k+ iterations but if I were using Lastpass personally (which I'm not) I would absolutely re-roll everything and never use the product again. I personally use a command line tool called `pass` which stores everything locally. This story interests me though because I am mildly involved with someone who is using Lastpass and I suggested they re-roll everything. I'm happy to see someone did the math, it's the exact information I wanted to know.

The podcast show notes are on page 6 which has more numbers and practical examples: https://www.grc.com/sn/SN-905-Notes.pdf

I think this misrepresents password entropy. For example forcing a capital letter mostly results in lusers capitalising the first letter (and losing about 1 bit versus having the choice of case for every character). Requiring "special characters" further decreases the entropy (certainly in theory, and I assume in practice).

I used https://www.omnicalculator.com/other/password-entropy to calculate it by the way. I threw out a few examples but you're right, it does come down to individuals knowing what to do or not. Those aren't meant to be good examples of passwords to use in practice.

For the record, it's pretty easy to do this by hand. The calculator assumes the attacker knows how many of each kind of character there is, which is a weird assumption so I'll not use that. Anyway you can take the base-2 log of the number of possibilities, or more easily add the entropies of each character (if they're not related). If you take e.g. the 64 symbols of Base64 as your allowed space you get: n*log_2(64)= 6n bits of entropy for an n-character password.

Give that most brute forcing is probably going to be done with wordlists and various permutations, I found this site to be interesting for estimating real password strength: https://lowe.github.io/tryzxcvbn/

`pass` is lovely, but don't you need your passwords on your phone when you're out-and-about?

There are apps for mobile devices, some sync with a GitHub repository (which you should make private): https://www.passwordstore.org/#:~:text=password%20(OTP)%20to...

The contents of the GitHub repo are of course encrypted with your own key, which you need to manually sync to your other devices.

The Android app for pass, and the required gpg app, are pretty clunky and not very friendly to work with (and the Windows desktop experience is not great either).

After some time with pass, I switched to a more integrated solution, with KeePassXC on desktops and Keepass2Android on mobile, with sync via OneDrive.

Pass has clients on iOS and Android, but there was some blocker with my GPG key on YubiKey last time I tried.

Ended up on Bitwarden (Vaultwarden in my closet really) instead for web passwords. Admin passwords stayed in pass because I want to be sure I have them. Git is local to the device even if the server burns down.

You can rsync the whole directory of passwords elsewhere and then connect there from your phone using SSH. If you're handy with `pass` you probably have an SSH client on your phone anyway (I use Prompt on iOS). Some people might think you're weird for using SSH from your phone though, fair warning.

> The TL;DR is even with 100k+ iterations of PBKDF2 an attacker can crack a password with 40 bits of entropy in about 71 days if they had access to 200 modern GPUs

...

> 50 bits of entropy changes things a bit. Now it takes 1 year instead of 71 days

I don't understand this. Going from 40 bits to 50 bits increases the size of the search space by a factor of 1024. Why does it only increase the search time by a factor of 5?

That's a good question to ask the podcast host (the source of those numbers).

On the reference page I linked it mentions:

> Having 40 bits of entropy is approximately 1,000 times weaker than 50 bits since bit strength scales exponentially. In other words, random bits are worth a lot because each additional truly random bit, on average, doubles the time required to crack.

71 days vs 365 days is about a 5x multiple. I'm not sure how all of that ties together.

Reply on news.ycombinator.com