Interesting thread!
Quote:
Originally Posted by Alphalutra1
Code:
< /dev/urandom strings -n1 | tr -dc _A-Z-a-z-0-9 | dd count=1 bs=16 2>/dev/null;echo
I know it works on Linux and OpenBSD; just change the bs in the dd command to change the password length;
Comments appreciated since I am far from adept at the command line.
|
At first I thought that having the
dd command at the end with
bs=16 would make it stop reading from
/dev/urandom when it had found 16 (allowed) characters. That would be a nice feature, but then thinking about it more I became less sure that would happen. I thought the first command in the pipeline,
strings, might very well read large blocks from
/dev/urandom and start feeding it down the pipe, only to have the thing terminate after a small number of bytes had been processed. But how to check this?
After a couple of failed attempts, I think I found something that works. Change the pipeline to this:
Code:
< /dev/urandom tee file.tmp | strings -n1 | tr -dc _A-Z-a-z-0-9 | dd count=1 bs=16 2>/dev/null;echo
(Make sure
file.tmp does not already exist!) The
tee command is like a
cat that also copies everything going through it to the given file. So by checking the size of
file.tmp you can see how many bytes were read from
/dev/urandom (or at least get a lower bound). (I'm assuming
tee reads similarly to how
strings would.) Here are the file sizes I observed:
Linux: 49152
OpenBSD: 196608
If this is showing what it seems, that's a lot of data to be reading from
/dev/urandom just to get 16 password char's. If entropy is a valuable resource, this could deplete it.
Also a comment and question about Carpetsmoker's suggestion:
Quote:
Originally Posted by Carpetsmoker
Code:
head -c100 /dev/urandom | strings -n1 | tr -d '[:space:]' | head -c15
|
The
head -c100 limits the reading of
/dev/urandom, which is good, although it still seems a bit long. If you had bad (u)random luck (
) you might never get the 15 characters you're after. There's a trade-off here as to how much to read, but if this was used in a script it would be good to check that the result was as desired and if not try again.
Another thing that occurred to me. As I understand it UTF-8 characters can be encoded in 1, 2, 3, ... several bytes. Intuitively it seems to me that this means there will be a strongly non-uniform distribution of UTF-8 characters coming out of
/dev/urandom. Consider a two-byte sample from
/dev/urandom. A given 1-byte UTF-8 character would be found in this sample with probability 2/256 =1/128 (approximately, ignoring a repeat), since it can be in either byte. But a given 2-byte UTF-8 character will be found only with probability (1/256)^2. Similarly one can consider longer UTF-8 chars.
So a question: When you use this method in a UTF-8 environment, do you find that the 2-byte characters (and longer) are indeed seen extremely rarely in the password?
I am thinking if one could effectively turn the
/dev/urandom output into some kind of pointer into a table of password characters, it might help with some of these problems.