Timeline for What is the practical impact of using System.Random which is not cryptographically random?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11, 2019 at 21:30 | comment | added | rmalayter |
@stackzebra System.Random seeds using the system time with (at best) microsecond resolution from the system clock. If the attacker has a clock accurate to within a second, then the only "entropy" from the attacker's perspective is the microseconds counter on the server clock where System.Random is being called as a new instance. log2(1000000)≈20 bits.
|
|
| Nov 9, 2019 at 19:09 | comment | added | stackzebra | How did you come to the number of 20 bits of entropy? | |
| Sep 2, 2019 at 3:10 | comment | added | rmalayter | We found this bug due to unexplained stack overflows in the error log. The function used System.Random with base64 to generate reset passwords, and then called itself recursively if that password didn’t contain a number. Obviously this resulted in the exact same password being generated, as a new instance of a System.Random was created with exactly the same seed, because the system clock ticks on the order of 64-100 ms depending on Windows version and hardware. | |
| Aug 31, 2019 at 11:20 | comment | added | MichaelS | @DmitryGrigoryev: I created a simple C# desktop app to test various delays. With a 1ms delay, running 101 different seeds, I'm getting 6-7% of consecutive seeds to be different. With a 10ms delay it's 63-64%. At 16ms it's almost always changed (9999 of 10000). 32ms had 100% changes over 10k runs. Didn't feel like sitting around waiting for intermediate runs. I'm on an i5 6600K, W8.1 using VS2017, in case anyone wants to start tallying use cases. :) | |
| Aug 30, 2019 at 17:36 | comment | added | John Dvorak | @DmitryGrigoryev maybe they're putting generous tolerances to make space for future disimprovements. | |
| Aug 30, 2019 at 10:28 | comment | added | Dmitry Grigoryev | @ToddSewell Once per two seconds at worst. I agree it's impossible to tell with certainty what the typical seed change rate is, but I think it's unlikely that a two-second delay would be required to get a different seed if they used milliseconds. | |
| Aug 30, 2019 at 10:07 | comment | added | KarelPeeters | @DmitryGrigoryev It implies that the seed is changing only once per second at worst! | |
| Aug 30, 2019 at 8:57 | comment | added | Dmitry Grigoryev |
Actually, the documentation tells that two System.Random objects are guaranteed to have different seeds if they are created with a two-second delay from each other, which implies that the seed is changing only once per second at best.
|
|
| Aug 30, 2019 at 2:02 | history | edited | rmalayter | CC BY-SA 4.0 |
added 111 characters in body
|
| Aug 30, 2019 at 1:54 | history | edited | rmalayter | CC BY-SA 4.0 |
added 49 characters in body
|
| Aug 30, 2019 at 1:40 | history | answered | rmalayter | CC BY-SA 4.0 |