5 ms·

Any known password is no longer a particularly strong one.

throwawaymath 8y ago
That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?
- simcop2387 8y ago
  If it's published as a list of known passwords, yes. That's roughly 1.50463276905253e-21 percent of the potential passwords for that character space (assuming 64 possible characters). If it's know that those are passwords then they're much much easier to test against than the 1329227995784915872903807060280344576 possibilities.
  - throwawaymath 8y ago
    First of all, in an online brute forcing scenario attackers will never get through the entire 20 trillion. Even if they knew for certain that the target victim's password satisfied the precise constraints of the passwords published in that list, they'd need around 2 years (with reasonable assumptions of millisecond latency) of constant, 24/7 attempts to run through them all. This is assuming there is no rate limiting. In an offline brute forcing scenario, either the passwords have been hashed with a strong key derivation function and a randomized salt or they haven't. If they have, it doesn't matter if the password is in that list. If they haven't, you're most likely screwed either way, because attackers can get up to 1 trillion password attempts per second in real world cracking setups now.
    - geofft 8y ago
      No, you're not screwed either way, because there are trillions of trillions of trillions of possible 20-character passwords. So even if they can get one trillion attempts per second, it will still take an attacker trillions of trillions of seconds to brute-force all possible 20-character passwords, which is longer than the lifetime of the universe.
      - throwawaymath 8y ago
        Now keep in mind that 1) it is possible to choose a strong password with fewer than 20 characters, and 2) most people will not choose a password that long. Extrapolating further, this "policy" would disallow people from choosing passwords below a certain length, because it's theoretically plausible someone has published the set of all possible strings fewer than n characters long.
        deleted 8y ago
        [deleted]
        geofft 8y ago
        > Extrapolating further, this "policy" would disallow people from choosing passwords below a certain length, because it's theoretically plausible someone has published the set of all possible strings fewer than n characters long. Yes, that seems like a good password policy. A list of possible alphanumeric strings that is actually reasonable to physically publish (i.e., not 20 trillion) is a list of extremely short alphanumeric strings. 5 alphanumeric characters is 380 million possible strings. 6 is about 2 billion. You should absolutely ban passwords that are 6 characters or shorter! In fact, I would go so far as to say that the questions of "Is this password too short because someone could brute-force all the possibilities, even if we're using a good password hash and a previously-unknown salt" and "Can someone physically enumerate all passwords of this size and put them on Pastebin or otherwise get them in the HIBP database" are equivalent.
        throwawaymath 8y ago
        Salts do not need to be previously unknown. This goes back to what I was saying - they're either securely protected with a key derivation function, or they're not.
        Dylan16807 8y ago
        Right. That was just to give the most generous possible circumstances to a password when arguing that it's still too weak.
- geofft 8y ago
  Yes, that is the correct conclusion. There are about 0.7 trillion trillion trillion alphanumeric passwords 20 characters long (62^20). Banning 20 trillion of them is a drop in the oceans, and nobody using a password generator is statistically likely to generate them within the expected lifetime of the universe, let alone of any given website. So, if you see one of those passwords, it is overwhelmingly likely that someone took a shortcut and used your list.
  - throwawaymath 8y ago
    No, it's not the correct conclusion. Virtually no passwords are safe under an offline brute force attempt if they haven't been protected by a robust key derivation function and a randomized salt. If the password has been protected like that, you not only need to try all 20 trillion of those hypothetical passwords; you also need to try them with the correct salt. And this is aside from the fact that you won't even rip through those 20 trillion in an online brute force attempt. Eventually you are only constrained by computational resources. If the passwords are cryptographically secured, it's fine if any one of them is published on the internet if you cannot associate it with any given user. If they're not cryptographically secured, this won't meaningfully reduce your already poor security anyway.
    - geofft 8y ago
      But what is the harm in blocking all 20 trillion such passwords? Do you expect to have any false positives?
      - throwawaymath 8y ago
        The harm is the principle of it. You should not design a system that greps through e.g. every single breach dump for arbitrary passwords every single time someone tries to sign up for your service. That's maddeningly inefficient.
        geofft 8y ago
        Why is it inefficient? Is the HIBP API too slow? How slow is too slow? My principle is that you should not let people sign up with breached passwords at all - don't make judgment calls about which breaches matter, and whether you think it's the same user or not, or the password is strong enough or not. Just ban the passwords. (Remember that no actual data breach contains 20 trillion passwords.)
- rmtech 8y ago
  > publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again? No because they each still have a very low probability. You have to be Bayesian about this: a list of one trillion passwords that have no further distinguishing information about each one of them cannot be assigned a probability of > 1/(1 trillion) In a data breach, a given password appears next to a particular username or email, which means it has a very high probability of being the password for that account.
- tialaramex 8y ago
  Yes, it's just safer. We do this _all the time_ in the Web PKI. Remember the "Debian weak keys"? What's weak about those particular keys? Nothing. Nothing whatsoever. Those keys aren't special in any way. Except, Debian shipped releases that always picked one of these key pairs. So anyone with a mind to can go find the list of private keys that corresponds to these particular public keys and thus we don't let you use those public keys any more. (You can go try this if you don't believe me, submit a CSR to your preferred public CA asking for a certificate for one of the Debian Weak Keys, it will be rejected and there may or may not be an explanation attached saying your keys are crap and to get new ones) Whole swathes of keys are blacklisted. ROCA is another example, somebody took one mathematical short-cut too many in their optimised design for RSA key generation, and so the resulting keys all have this very obvious structure that's exploitable (not easily, but enough that a sovereign entity could definitely break them). So we just blacklisted all those keys. If you pick truly random keys you'll never notice this in a lifetime because of statistics, it's just some code on the issuer's systems that you never need to care about.

That doesn't make sense. If I publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again?

simcop2387 8y ago
If it's published as a list of known passwords, yes. That's roughly 1.50463276905253e-21 percent of the potential passwords for that character space (assuming 64 possible characters). If it's know that those are passwords then they're much much easier to test against than the 1329227995784915872903807060280344576 possibilities.
- throwawaymath 8y ago
  First of all, in an online brute forcing scenario attackers will never get through the entire 20 trillion. Even if they knew for certain that the target victim's password satisfied the precise constraints of the passwords published in that list, they'd need around 2 years (with reasonable assumptions of millisecond latency) of constant, 24/7 attempts to run through them all. This is assuming there is no rate limiting. In an offline brute forcing scenario, either the passwords have been hashed with a strong key derivation function and a randomized salt or they haven't. If they have, it doesn't matter if the password is in that list. If they haven't, you're most likely screwed either way, because attackers can get up to 1 trillion password attempts per second in real world cracking setups now.
  - geofft 8y ago
    No, you're not screwed either way, because there are trillions of trillions of trillions of possible 20-character passwords. So even if they can get one trillion attempts per second, it will still take an attacker trillions of trillions of seconds to brute-force all possible 20-character passwords, which is longer than the lifetime of the universe.
    - throwawaymath 8y ago
      Now keep in mind that 1) it is possible to choose a strong password with fewer than 20 characters, and 2) most people will not choose a password that long. Extrapolating further, this "policy" would disallow people from choosing passwords below a certain length, because it's theoretically plausible someone has published the set of all possible strings fewer than n characters long.
      - deleted 8y ago
        [deleted]
      - geofft 8y ago
        > Extrapolating further, this "policy" would disallow people from choosing passwords below a certain length, because it's theoretically plausible someone has published the set of all possible strings fewer than n characters long. Yes, that seems like a good password policy. A list of possible alphanumeric strings that is actually reasonable to physically publish (i.e., not 20 trillion) is a list of extremely short alphanumeric strings. 5 alphanumeric characters is 380 million possible strings. 6 is about 2 billion. You should absolutely ban passwords that are 6 characters or shorter! In fact, I would go so far as to say that the questions of "Is this password too short because someone could brute-force all the possibilities, even if we're using a good password hash and a previously-unknown salt" and "Can someone physically enumerate all passwords of this size and put them on Pastebin or otherwise get them in the HIBP database" are equivalent.
        throwawaymath 8y ago
        Salts do not need to be previously unknown. This goes back to what I was saying - they're either securely protected with a key derivation function, or they're not.
        Dylan16807 8y ago
        Right. That was just to give the most generous possible circumstances to a password when arguing that it's still too weak.
geofft 8y ago
Yes, that is the correct conclusion. There are about 0.7 trillion trillion trillion alphanumeric passwords 20 characters long (62^20). Banning 20 trillion of them is a drop in the oceans, and nobody using a password generator is statistically likely to generate them within the expected lifetime of the universe, let alone of any given website. So, if you see one of those passwords, it is overwhelmingly likely that someone took a shortcut and used your list.
- throwawaymath 8y ago
  No, it's not the correct conclusion. Virtually no passwords are safe under an offline brute force attempt if they haven't been protected by a robust key derivation function and a randomized salt. If the password has been protected like that, you not only need to try all 20 trillion of those hypothetical passwords; you also need to try them with the correct salt. And this is aside from the fact that you won't even rip through those 20 trillion in an online brute force attempt. Eventually you are only constrained by computational resources. If the passwords are cryptographically secured, it's fine if any one of them is published on the internet if you cannot associate it with any given user. If they're not cryptographically secured, this won't meaningfully reduce your already poor security anyway.
  - geofft 8y ago
    But what is the harm in blocking all 20 trillion such passwords? Do you expect to have any false positives?
    - throwawaymath 8y ago
      The harm is the principle of it. You should not design a system that greps through e.g. every single breach dump for arbitrary passwords every single time someone tries to sign up for your service. That's maddeningly inefficient.
      - geofft 8y ago
        Why is it inefficient? Is the HIBP API too slow? How slow is too slow? My principle is that you should not let people sign up with breached passwords at all - don't make judgment calls about which breaches matter, and whether you think it's the same user or not, or the password is strong enough or not. Just ban the passwords. (Remember that no actual data breach contains 20 trillion passwords.)
rmtech 8y ago
> publish a list of 20 trillion alphanumeric passwords, each of which is 20 characters long, your thesis is that no one should ever use any of those passwords again? No because they each still have a very low probability. You have to be Bayesian about this: a list of one trillion passwords that have no further distinguishing information about each one of them cannot be assigned a probability of > 1/(1 trillion) In a data breach, a given password appears next to a particular username or email, which means it has a very high probability of being the password for that account.
tialaramex 8y ago
Yes, it's just safer. We do this _all the time_ in the Web PKI. Remember the "Debian weak keys"? What's weak about those particular keys? Nothing. Nothing whatsoever. Those keys aren't special in any way. Except, Debian shipped releases that always picked one of these key pairs. So anyone with a mind to can go find the list of private keys that corresponds to these particular public keys and thus we don't let you use those public keys any more. (You can go try this if you don't believe me, submit a CSR to your preferred public CA asking for a certificate for one of the Debian Weak Keys, it will be rejected and there may or may not be an explanation attached saying your keys are crap and to get new ones) Whole swathes of keys are blacklisted. ROCA is another example, somebody took one mathematical short-cut too many in their optimised design for RSA key generation, and so the resulting keys all have this very obvious structure that's exploitable (not easily, but enough that a sovereign entity could definitely break them). So we just blacklisted all those keys. If you pick truly random keys you'll never notice this in a lifetime because of statistics, it's just some code on the issuer's systems that you never need to care about.