undefined | Better HN

0 pointsdllthomas6y ago0 comments

I'm curious how practical an RNG attack actually is here (which absolutely isn't meant to serve as criticism of your surfacing the issue!).

In any case, I expect it's much harder than a random "free password gen!" website saving results on the sly (... which is meant to be mild criticism of your framing, but not your recommendation :-p).

0 comments

4 comments · 2 top-level

ThA0x26y ago· 2 in thread

shuf uses randint(), which defaults to /dev/urandom as the nonce source:

https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran...

It's going to be as practical to attack as anything that uses /dev/urandom.

dllthomasOP6y ago

For sufficiently recent versions of shuf. It looks (... at a skim of the history, I could be confused) like older versions use pid, ppid, uid, gid, and time. In that case that's likely to be more practical than brute force if you've generated a password with notionally more than ~40 bits of entropy.

That said, I suspect most people are indeed on a platform with a sufficiently recent version of shuf.

(And a sufficiently old version may lack the random-source option.)

ThA0x26y ago

RHEL 6 will be EOLd this November. That's the last supported version of RHEL that has this issue. Ubuntu 13.04, RHEL 7 and later don't suffer from this issue.

I'd say almost everyone reading these comments is on a platform that does not suffer from this issue.

rmrfstar6y ago

Depends on the situation.

I definitely wouldn't try this on a freshly booted Raspberry Pi, for example.

j / k navigate · click thread line to collapse