Hacker News Reader

Comment by apk17 | Hacker News Reader

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.

View on HN

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

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.

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.

Ruby takes the seed for rand() from /dev/urandom, according to doc. That's good enough for a single use.

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/

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 ]

Minor typo or issue with HN escaping:

    rand(34**10)

rather than

    rand(34*10)

And you'll probably want a puts in front.

Reply on news.ycombinator.com