16 letters is ~75 bits of entopy (if they are randomly selected), not 65. The usual recommendation is 80, but it's not as bad as you say. I don't know how Keepass is doing its math, but 65 is wrong.
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.
65 bits is incredible amount of entropy. Why do you think that's not enough? I'm using 10 characters passwords of lowercase letters almost everywhere and I think that's absolutely enough.
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.
Whether 65 bits is sufficient depends on your attack scenario. I agree that Google won't allow you to try that many passwords, but for other scenarios, 65 bits might not be enough.
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.
When data leak occurs, nobody's going to brute force random passwords. They'll use dictionary attacks. Using SHA-256 is strange. Some websites store clear text passwords. Some websites store bcrypt hashes. Why do you focus on SHA-256? Is there some kind of statistics that this particular kind of hash is common among hacked websites?
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.
> When data leak occurs, nobody's going to brute force random passwords.
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.
They don't get the benefit of the doubt. I've lost count of how many times these agencies have been caught illegally spying only to apologize and keep doing it in secret. There's probably even a Wikipedia page of all the whistleblowers.
Even if they don’t have free reign over every bit of data (unlikely), there are certainly automated systems that will give them free access to any account they wish upon delivery of a rubber stamped “warrant”, signed by an anonymous “judge” in a secret court.
They're more secure than "Welcome2024!", which is what you can expect most people to use. 16 letters is more than secure enough, you can't brute force that. They're guaranteed to be unique passwords that aren't used on other services, so credential stuffing is no longer a threat.
This is an inconsequential change to people who use password managers, but it'll help against credential stuffing attacks for the common user.
Assuming the attacker doesn't have a leaked database of hashed passwords and therefore can't run the brute force on a local database. I want my account to be secure even if there is a leak which has been the standard for authentication for more than a decade.
It's not a password, it's an API Key. A GUID is 16 bytes represented as 36 characters with hypens but we consider those secure. Even Stripe's private keys are kinda short but their restricted keys are not.
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?)
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?