Mfcttrf

I recently noticed a .NET software using PBKDF to derive an encryption key from a password string. This password string was dynamically generated using System.Random. Now, I know that System.Random is not really cryptographically random and should not be used for security purposes. Moreover, there are several flaws in .NET's implementation of System.Random.

But my question is this:

• What is the practical impact of using System.Random to create a password string and deriving a key from it. Is it really possible for us to reproduce the key at a later time? Are there feasible attacks that will allow me to deduce the random string generated in this context with high probability? Or is it the kind of vulnerability that can only be exploited in specific "lab" conditions or scenarios?

What cryptographers will tell you is that if the password has high enough min-entropy, then your system will not be breakable in certain particular ways if you use certain cryptography.

What cryptographers will not do is lift a finger to break your pet project, because it's a lot of work to find a ‘feasible’ attack, and negligible reward—unless they actually get a specific reward from your system because they are the adversary trying to exploit your users, in which case they aren't going to share their findings with you.

Cryptographers only bother attacking real systems in the wild when they are particularly high-value, like TLS, and particularly many users might be at particularly high risk because of shoddy choices like RC4 that the engineers drag their feet about changing, despite the fact that RC4 was broken within 48 hours of its publication[1] and cryptanalysts kept finding worse[2] and worse[3] problems in it. That's why cryptanalysts bothered studying the specific use of RC4 in WPA and TLS[4][5][6], for example. The same thing happened with bespoke kooky constructions in SSH, TLS, and PGP[7].

Don't be the engineer responsible for making a shoddy cryptographic decision that will inspire cryptanalysts to poke holes in your system years down the road. Follow cryptographers' advice the first time around, to save the cryptanalysts' effort and to let them focus on cryptosystems that will be broadly used like NIST PQC, to improve security for everyone.

That said, if the (secret) seed really is a 32-bit integer as the documentation suggests, the search space for the seed is so small you can exhaustively try all seeds and completely break everything about the system by finding the seed on the phone in your pocket while you're busy playing Candy Crush Saga and reading Instagram without even draining the battery once. This is so laughably insecure it is even worse than the Netscape SSL RNG bug that made news in 1996, and if you also know what time of day it was when the luser called System.Random, you can break it even faster.

The official documentation for System.Random explicitly says it should not be used for generating passwords. It’s predictable, and seeded only from the system clock. This means System.Random has at most 20 bits of entropy to anyone who has a clock accurate to within a second.

Indeed, try creating two new instances in quick succession on different threads; they will produce the same output! I have encountered exactly this issue in an audit of real-world password reset code in a SaaS application. The same passwords were being sent to multiple users in the real world. You could predict those passwords easily if you guessed/knew that System.Random with base64 encoding was being used to generate reset passwords.