View Single Post
Old 15th February 2014
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

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.
Reply With Quote