12 ms·

Another option is an XKCD-inspired[1] 'correct horse battery staple' passphrase. I understand that using such passphrases in other contexts like encryption is c

Another option is an XKCD-inspired[1] 'correct horse battery staple' passphrase. I understand that using such passphrases in other contexts like encryption is controversial due to their relatively low entropy, but I think customer support is an ideal application for them. 1. https://xkcd.com/936/ https://xkcd.com/936/

ben_w 9y ago
I believe the entropy problem is only that people don’t choose words randomly. I wrote a script to do it for me, with numbers separating words because some websites demand numbers, and assuming the random number generation is suitable, it’s 73 bits of entropy. I have no idea if the random number generation is sufficient: https://github.com/BenWheatley/HighEntropyPassword https://github.com/BenWheatley/HighEntropyPassword
- jaclaz 9y ago
  >I have no idea if the random number generation is sufficient Sure it is, to remain in the same XKCD realm, this works fine: https://xkcd.com/221/ https://xkcd.com/221/ More seriously, since you have your "random" numbers in non-fixed position (due to different length of the "random" strings/words and also the number themselves can be 1, 2 or three characters long), even if the built-in algorithm is not "random" enough mathematically, I don't think that it will actually affect password discoverability.
- r00fus 9y ago
  I just use one of many password managers to generate the passphrase, then enrich with symbol(s) and uppercasing. It all gets stored in the password manager anyway...
- jwilk 9y ago
  I only looked at the Python part, and no, it's not good. Documentation for the random module¹ prominently warns: The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you require a cryptographically secure pseudo-random number generator. ¹ https://docs.python.org/2/library/random.html https://docs.python.org/2/library/random.html
  - tgb 9y ago
    Okay, I don't study this, but I don't think that's what "cryptographically secure pseudo-random number generator" means. Not all things vaguely related to cryptography are required a CSPRNG and these answers are not being used cryptographically at all in many cases (like you just reading it over the phone to the representative). Please correct me if I'm wrong.
    - Dylan16807 9y ago
      A bog-standard RNG might generate passwords depending on what second you ran it, so an attacker can easily make a list of all the passwords generated in a specific month or year. People have lost a lot of bitcoins this way. It might be okay for a security question, but better safe than sorry. Just use a secure generator for everything.
  - icebraining 9y ago
    I'm no cryptographer, but while the warning is valid, I don't think it's crucial here. There are two potential sources of problem, the seed and the PRNG. The seed should be OK, because Python will use urandom as long as it's available in the system. As for the PRNG, a non-secure one shouldn't be used in encryption because it has statistically predictable behavior, but as far as I know that requires access to the ciphertext, which isn't the case here. Still, replacing random with SystemRandom is easy and would fix the problem.
  - ben_w 9y ago
    Thanks! I’ll update it shortly.

ben_w 9y ago

I believe the entropy problem is only that people don’t choose words randomly. I wrote a script to do it for me, with numbers separating words because some websites demand numbers, and assuming the random number generation is suitable, it’s 73 bits of entropy. I have no idea if the random number generation is sufficient: https://github.com/BenWheatley/HighEntropyPassword https://github.com/BenWheatley/HighEntropyPassword

jaclaz 9y ago
>I have no idea if the random number generation is sufficient Sure it is, to remain in the same XKCD realm, this works fine: https://xkcd.com/221/ https://xkcd.com/221/ More seriously, since you have your "random" numbers in non-fixed position (due to different length of the "random" strings/words and also the number themselves can be 1, 2 or three characters long), even if the built-in algorithm is not "random" enough mathematically, I don't think that it will actually affect password discoverability.
r00fus 9y ago
I just use one of many password managers to generate the passphrase, then enrich with symbol(s) and uppercasing. It all gets stored in the password manager anyway...
jwilk 9y ago
I only looked at the Python part, and no, it's not good. Documentation for the random module¹ prominently warns: The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you require a cryptographically secure pseudo-random number generator. ¹ https://docs.python.org/2/library/random.html https://docs.python.org/2/library/random.html
- tgb 9y ago
  Okay, I don't study this, but I don't think that's what "cryptographically secure pseudo-random number generator" means. Not all things vaguely related to cryptography are required a CSPRNG and these answers are not being used cryptographically at all in many cases (like you just reading it over the phone to the representative). Please correct me if I'm wrong.
  - Dylan16807 9y ago
    A bog-standard RNG might generate passwords depending on what second you ran it, so an attacker can easily make a list of all the passwords generated in a specific month or year. People have lost a lot of bitcoins this way. It might be okay for a security question, but better safe than sorry. Just use a secure generator for everything.
- icebraining 9y ago
  I'm no cryptographer, but while the warning is valid, I don't think it's crucial here. There are two potential sources of problem, the seed and the PRNG. The seed should be OK, because Python will use urandom as long as it's available in the system. As for the PRNG, a non-secure one shouldn't be used in encryption because it has statistically predictable behavior, but as far as I know that requires access to the ciphertext, which isn't the case here. Still, replacing random with SystemRandom is easy and would fix the problem.
- ben_w 9y ago
  Thanks! I’ll update it shortly.