Vert.x's PRNG as Salt Generator

[javenwang]

This is not an issue but just for people who are using jargon2 with Vert.x

For now SecureRandomSaltGenerator used by jargon2 does not setSeed() periodically which is recommended.

If you are using Vert.x, please notice:

Since Secure Random from java can block during the acquisition of entropy from the system, we provide a simple wrapper around it that can be used without the danger of blocking the event loop.

So thanks for the flexibility of this great library, we can change the salt generator:

val hasher = jargon2Hasher().saltGenerator {
    VertxContextPRNG.current().nextBytes(it)
}

[kosprov]

Thanks for the tip

[kosprov]

I did a little thinking about the necessity of re-seeding the random number generator.

From what I've read so far, re-seeding the PRNG is necessary because after observing a large number of generated values, an attacker will be able to predict future values. This crucial when you generate session ids, tokens etc.

I'll make a few statements which I assert they are true and I would like to get comments and counter arguments:

1. Random values are only used to generate salt for new hashes (obviously)
2. New salts are needed for new passwords, i.e. when users register or change their passwords which is not that often in most real-life applications. Not like hundreds per second which a machine cannot handle, anyway.
3. To observe all salt values and their order, an attacker needs constant access to the database. Like looking at the write-ahead-log or the network. From a database snapshot, an attacker would not know the order by which salts where generated.
4. Most applications have typically many app server nodes. PRNGs are seeded independently on each node. Even if you have constant access to the database, it would be very difficult to figure out which app server node a salt was generated on.
5. Most servers are multi-threaded. When an attacker observes salts written to the database with a very small time difference, he would not know for sure the order since the earlier salt may have been generated after the later one.
6. Even if an attacker manages to predict future salts for some period of time, he can only start pre-calculating rainbow tables. When he looses the ability to predict (e.g. a server restarted), pre-calculated rainbow tables up to that moment are worthless and a great amount of work is wasted.

As long as the attacker cannot control future salt values, which you be catastrophic, everything is fairly safe.

Any thoughts?