3 ms·

ruby -e 'rand(34*10).to_s(34)' I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem i

by apk17 10y ago

ruby -e 'rand(34*10).to_s(34)' I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.

dchest 10y ago
Both your and parent's password generators are not secure: they use non-cryptographic random number generators, which have limited entropy.
- vidarh 10y ago
  That matters very little if you are manually generating an occasional password here and there for personal and an attacker have no reason to know your specific method of generating the password.
  - e12e 10y ago
    True. Otoh I just told the attacker my specific method :-) And I'd prefer a system that was secure enough that doing so wasn't a problem.
- apk17 10y ago
  Ruby takes the seed for rand() from /dev/urandom, according to doc. That's good enough for a single use.
- e12e 10y ago
  On most platforms python3's random use os level random? The suitable one on Window and /dev/random on Linux? [ed: hm, no - not yet. I remembered discussions like this: https://lwn.net/Articles/657269/ https://lwn.net/Articles/657269/ But looks like "secrets"[1] has the strong random.choice provider among others. Probably the (minimal, dirty) change needed (for python 3.6 and later) is: import secrets as r But I can't test that right now. Thanks for calling me out on this, and having me do a quick search to check my assumptions. I do agree that for this particular case, the pseudo-random generator seeded by system time might be enough (or at least better than "random" key presses) - but I don't like spreading bad patterns. And for any code generating many passwords, with the opportunity for an attacker to get a sample - this is likely very bad. [1] https://docs.python.org/dev/library/secrets.html https://docs.python.org/dev/library/secrets.html ]
vidarh 10y ago
Minor typo or issue with HN escaping: rand(34**10) rather than rand(34*10) And you'll probably want a puts in front.

by apk17 10y ago

ruby -e 'rand(34*10).to_s(34)' I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.

dchest 10y ago

Both your and parent's password generators are not secure: they use non-cryptographic random number generators, which have limited entropy.

vidarh 10y ago
That matters very little if you are manually generating an occasional password here and there for personal and an attacker have no reason to know your specific method of generating the password.
- e12e 10y ago
  True. Otoh I just told the attacker my specific method :-) And I'd prefer a system that was secure enough that doing so wasn't a problem.
apk17 10y ago
Ruby takes the seed for rand() from /dev/urandom, according to doc. That's good enough for a single use.
e12e 10y ago
On most platforms python3's random use os level random? The suitable one on Window and /dev/random on Linux? [ed: hm, no - not yet. I remembered discussions like this: https://lwn.net/Articles/657269/ https://lwn.net/Articles/657269/ But looks like "secrets"[1] has the strong random.choice provider among others. Probably the (minimal, dirty) change needed (for python 3.6 and later) is: import secrets as r But I can't test that right now. Thanks for calling me out on this, and having me do a quick search to check my assumptions. I do agree that for this particular case, the pseudo-random generator seeded by system time might be enough (or at least better than "random" key presses) - but I don't like spreading bad patterns. And for any code generating many passwords, with the opportunity for an attacker to get a sample - this is likely very bad. [1] https://docs.python.org/dev/library/secrets.html https://docs.python.org/dev/library/secrets.html ]

vidarh 10y ago

Minor typo or issue with HN escaping: rand(34**10) rather than rand(34*10) And you'll probably want a puts in front.