16 lowercase letters (in groups of 4 separated by space), no numbers, no special characters.
Keepass evaluates this as a weak password with 65 bits of entropy (if spaces are removed)
How is this an improvement?
The examples in their docs show that a run of characters “aaaa…” only has an estimate of 7 bits:
https://keepass.info/help/kb/pw_quality_est.html
Obviously the estimate is wrong when the password will always have a fixed length and a randomized character set. But KeePass doesn’t know that “pass word pass word” is following set rule. Perhaps parent commenter ran the calculation on an example with a run or common word within it.
You’re right it’s 75 bits for the format used by Google here.
2 ^ 65 / 20 / 365 / 86400 = 58 494 241 735
I don't think Google would allow you to bruteforce account using 58 billions of attempts per second for 20 years.
For example, imagine that OP is reusing passwords across different websites as most people are doing. One server gets hacked and the SHA256 password hashes get leaked, which unfortunately is still common. Currently, the best bitcoin miners can hash in the order of 10^14 hashes per second, which amounts to just 2^65 / 10^14 / 86400 ≈ 4 days of hashing. To be fair, bitcoin miners usually are not suitable for password hashing, but I'd be surprised if the NSA does not have 1000s of similar devices somewhere. Is that a realistic scenario? Probably not. But it is certainly a technical possibility.
A lower case password with 10 characters is not sufficient at all. Anycone could bruteforce that in a day with just one modern GPU.
https://www.zdnet.com/article/google-the-nsa-and-the-need-fo...
1)https://krebsonsecurity.com/tag/emergency-data-request/ 2)https://news.ycombinator.com/item?id=30842757
This list does exist.
https://en.wikipedia.org/wiki/Global_surveillance_whistleblo...
I agree that it depends on attack scenario. My scenario is: I expect website owners to find out about attack in a timely manner and disable all compromised accounts. Of course I won't reuse single password across different websites. Also I feel that most important websites nowadays require SMS or E-mail factor when logging in from another device, so this further decreases requirements for strong password.
And, of course, I don't expect to be targeted by government. They'll just hit my head with wrench until I unlock my iPhone, that would be cheapest attack on me, independent on password length.
People will absolutely bruteforce random passwords. There are entire communities (like hashmob net, not sure if I am allowed to link it directly) devoted to cracking as many hashes of breaches as possible. Dictionary attacks will get you most of the easy passwords, but are quickly exhausted.
> Why do you focus on SHA-256?
I chose this hash because, thanks to Bitcoin, we know how fast specialized hardware to compute that hash can be.
> Is there some kind of statistics that this particular kind of hash is common among hacked websites?
It's not the most common. That would sadly be MD5. But SHA-256 is not rare either.
> They'll just hit my head with wrench until I unlock my iPhone, that would be cheapest attack on me, independent on password length.
I agree, rubber-hose cryptanalysis can be very cost-efficient. https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Fortunately, many governments are opposed to this kind of cryptanalysis, but YMMV.
FWIW that's impossible in this context since:
> you cannot set app passwords yourself
Though more generally, password reuse is indeed a problem regardless of entropy.
That would be foolish, but users do all sorts of foolish things.
This is an inconsequential change to people who use password managers, but it'll help against credential stuffing attacks for the common user.
*unless you take this password after it's generated and start reusing it in other services, but that is pure self sabotage
I don't see the difference.
> A GUID is 16 bytes represented as 36 characters with hypens but we consider those secure.
That's about twice as many bytes. That's an exponential difference in security.
Uppercase + numbers + special characters will only give 1.3 more bits per character. 26 possibilities is 4.7 bits, so each additional lowercase letter adds enough entropy to make up for the alphabet size of 4.7/1.3=3.6 characters.
So roughly speaking, 16 lowercase letters has about the entropy of 12 characters with a larger alphabet. That seems ok to me; 12 characters is pretty decent. Certainly not laughable.
With an alphabet of 64 possible characters, you have 12lg(64)=72 bits for 12 random characters.
With an alphabet of 26 possible characters, you have 16lg(26)=75 bits for 16 random characters.
And the "random" part that allows the lg(possibilities) calculation is enabled by not allowing you to set the passwords yourself.
Of course, 75 bits only gives you about 100 billion users × apps before you start hitting birthdays—er, collisions—so hopefully they're not using the passwords as unique keys anywhere! (But why would they?)
That's not weak?