Hi Joseph:

In message <alpine.DEB.2.20.1808022303100.30418@digraph.polyomino.org.uk>,
Joseph Myers writes:
>On Thu, 2 Aug 2018, John P. Rouillard wrote:
>> Question, does the salt needs to be generated using os.urandom at all?
>> Everything else in that module seems to use just random. Is the
>> randomness of the salt that critical?
>
>Optimally for salts, no two passwords hashed with the same algorithm 
>(ever, anywhere) would use the same salt, so there is no benefit to an 
>attacker precomputing hashes / rainbow tables.  Typically that should mean 
>salts of at least 64 bits.  The security model here is protecting against 
>attackers who somehow acquire a large number of password hashes and 
>[...]
>seeded from the system random number generator.  What's not safe is using 
>pseudorandom number generation having not reseeded that generator for a 
>long time (because if too many random numbers have been generated from the 
>same generator, an attacker may be able to determine its state, and thus 
>predict the random numbers used for other users).

Correct. That's why I was trying to figure out some way to mix
existing state into the salt to make the reseed state depend on
something other than just the time.

>Rather than trying to decide that particular places do not need secure 
>randomness, it's certainly safer always to use the system random number 
>generator.

Agreed. I considered dropping the pseudorandom generator entirely, but
I couldn't rule out that there were platforms which run python that do
not have a working os.random. Roundup can be used in a mode that does
not require security (e.g. as a GTD tool with a single user on a stick
computer, (yeah I thought it sounded interesting)).

>> >The places where we reseed the random number generator seem to be a 
>> >bit, well, random. We should probably only reseed after forking, i.e. 
>> >in ForkingServer (roundup_server.py).
>> 
>> There are at least 5 deployment mechanisms for roundup (see "Configure
>> a Web Interface" in doc/installation.txt . Only one of which is the
>
>That's actually a list of six, despite saying five above the list.

Two of them are different ways of invoking the cgi mode so...

Also one other thing occurred to me, some of the code paths may be
used by roundup-admin and thus need to be seeded (assuming you don't
do away with the pseudo random generator) in those code paths as well.

Also since a user can write scripts that import roundup, the roundup
routines that need random data should make sure that the pseudo random
generator is properly randomized when required. It shouldn't require
the user to properly initialize the random generators.