I thought of an approach to password generation that I haven't heard of anyone else using. It almost seems too good to be true so I wonder what the downsides are. I'm well aware that you shouldn't "roll your own" and that even if a specific flaw isn't found initially, flaws may nonetheless exist.

To generate a password, run csprng /var/log/syslog where csprgn is your favorite CSPRNG. As syslog contains hundreds of lines with lots of hard-to-guess info such as second-precision timestamps and process IDs and environment-specific info such as username, IP addresses, and present hardware and software as well as computer usage, and even given the above, line order is non-deterministic, entropy should be extremely high. The result seems to be effectively a completely random hash string. Another advantage is command line history doesn't reveal the password.

Of course this approach can only be used once in a long while (say once per boot), as otherwise the log may differ only in slight ways. Are there any other downsides of this approach?

3 Answers 3


It's not that hard to guess if you think about it. It's a formatted file, so it comes with predictable fields with mostly predictable content.

Timestamps are easy to guess. PID files have an upper limit. Most servers have services on a large but countable set of services. And error messages are not infinite too. If you search online for a random error message on your syslog, chances are that someone already posted the exact same message, except for the timestamps.

It may look random for you, but you are not sure until you can measure exact how random it really is. You have to test it to see if really your random number generator is really random. And I doubt it would pass the tests.

As mti2935 said, use /dev/urandom (or /dev/random on newer kernels). It is criptographically secure generated, is tested, produces quality random numbers, and don't contain data that an attacker could guess. Your syslog is not random, is not securely generated, and will not pass a random test.

And for generating random passwords, I use dd, base64 and cut:

dd if=/dev/urandom bs=32 count=1 | base64 | cut -b1-16

Or, if you are old-school, you could replace base64 with uuencode and get a good looking password.

  • 1
    Additionally, if you have log rotation configured, the syslog file might only have a single line in it saying that it's been rotated. It could even be empty if you're doing rotation in an unusual way. In those cases the entropy would be extremely low.
    – Gh0stFish
    Aug 18, 2021 at 15:45

One downside of this approach is that the syslog file stays around. An attacker can pull it off disk, make guesses as to which point in time you might have run csprng against it, and reproduce your password. Unless you're going to shred and delete the file after you derive a password using it - and that has operational implications - using syslog is a bad idea.

Better to use /dev/urandom as others have suggested. Once bits are read from that, they're gone and can't be read again.


/dev/urandom is a better source of entropy than syslog. You can produce randomly generated passwords by feeding /dev/urandom into a hash function, like so:

head /dev/urandom | sha256sum

which will produce a random password consisting of 64 hexadecimal characters.

If you want fewer characters, you can use cut, like so:

head /dev/urandom | sha256sum | cut -c1-16

which will truncate the password to 16 characters.

For a wider range of characters, you can use tr. For example:

head /dev/urandom | tr -dc '[:alpha:][:digit:]' | cut -c 1-12

will produce a password consisting of uppercase letters, lowercase letters, and digits, 12 characters long.

As for your question, Does hashing syslog (or similar) make for good passwords?: There is no question that /dev/urandom has much greater entropy than syslog. So, why use syslog when you can just as easily use /dev/urandom?

  • OK, good point. Your approach is better. But you don't directly answer the question.
    – anon
    Aug 17, 2021 at 0:38
  • I edited my answer, see last paragraph.
    – mti2935
    Aug 17, 2021 at 2:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .