5 ms·

Problem seems that you cannot set app passwords yourself and they seem laughably insecure. 16 lowercase letters (in groups of 4 separated by space), no numbers

Problem seems that you cannot set app passwords yourself and they seem laughably insecure. 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?

SpaghettiCthulu 3y ago
That should be plenty seeing as Google would lock your account before an attacker were ever able to bruteforce an app password, right?
- _Algernon_ 3y ago
  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.
  - freedomben 3y ago
    This password should not be in any leaked database of hashed passwords, because it is completely randomly generated. You can't even set it.* *unless you take this password after it's generated and start reusing it in other services, but that is pure self sabotage
    - jjnoakes 3y ago
      It would be if Google's app password hash database was leaked.
      - freedomben 3y ago
        Good point, although if that happens, then I think we probably have a much bigger problem
      - throwaway2037 3y ago
        Is there any public knowledge of a Google password hash database leak for any of their apps ... ever?
  - SpaghettiCthulu 3y ago
    Fair point
LeoPanthera 3y ago
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.
- rhplus 3y ago
  KeePass considers letter runs and common words to lower entropy. So “pass word pass word” fits the scheme above but demonstrates lower entropy. 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 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.
vbezhenar 3y ago
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.
- johndough 3y ago
  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.
  - basil-rash 3y ago
    The NSA already has full access to google’s data centers. If they want your password they’ll just sniff it in-flight. https://www.zdnet.com/article/google-the-nsa-and-the-need-for-locking-down-datacenter-traffic/ https://www.zdnet.com/article/google-the-nsa-and-the-need-fo...
    - saalweachter 3y ago
      Since 2013, Google has switched to encrypting in transit across unsecured fiber: https://cloud.google.com/docs/security/encryption-in-transit#physical_boundaries https://cloud.google.com/docs/security/encryption-in-transit...
jabart 3y ago
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.
- Dylan16807 3y ago
  > It's not a password, it's an API Key. 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.
jeroenhd 3y ago
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.
sfink 3y ago
16 is a lot. 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?)
xxpor 3y ago
Part of it is that app passwords are locked once used - you can't move them to a new user agent is my understanding.
e12e 3y ago
> weak password with 65 bits of entropy That's not weak?

SpaghettiCthulu 3y ago

That should be plenty seeing as Google would lock your account before an attacker were ever able to bruteforce an app password, right?

_Algernon_ 3y ago
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.
- freedomben 3y ago
  This password should not be in any leaked database of hashed passwords, because it is completely randomly generated. You can't even set it.* *unless you take this password after it's generated and start reusing it in other services, but that is pure self sabotage
  - jjnoakes 3y ago
    It would be if Google's app password hash database was leaked.
    - freedomben 3y ago
      Good point, although if that happens, then I think we probably have a much bigger problem
    - throwaway2037 3y ago
      Is there any public knowledge of a Google password hash database leak for any of their apps ... ever?
- SpaghettiCthulu 3y ago
  Fair point

LeoPanthera 3y ago

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.

rhplus 3y ago
KeePass considers letter runs and common words to lower entropy. So “pass word pass word” fits the scheme above but demonstrates lower entropy. 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 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.

vbezhenar 3y ago

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.

johndough 3y ago
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.
- basil-rash 3y ago
  The NSA already has full access to google’s data centers. If they want your password they’ll just sniff it in-flight. https://www.zdnet.com/article/google-the-nsa-and-the-need-for-locking-down-datacenter-traffic/ https://www.zdnet.com/article/google-the-nsa-and-the-need-fo...
  - saalweachter 3y ago
    Since 2013, Google has switched to encrypting in transit across unsecured fiber: https://cloud.google.com/docs/security/encryption-in-transit#physical_boundaries https://cloud.google.com/docs/security/encryption-in-transit...

jabart 3y ago

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.

Dylan16807 3y ago
> It's not a password, it's an API Key. 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.

jeroenhd 3y ago

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.

sfink 3y ago

16 is a lot. 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?)

xxpor 3y ago

Part of it is that app passwords are locked once used - you can't move them to a new user agent is my understanding.

e12e 3y ago

> weak password with 65 bits of entropy That's not weak?