0

I've read the new password_hash() function from PHP uses /dev/urandom to generate a secure salt, however this assumes some noise from device drivers. Is possible that /dev/urandom is not so random when in example deploying a website on a Virtual machine? (in example the same image of a operative system snapshot is runned and in reality what we get is just a "hash" of system time?) I am assuming that simulating the operative system is going to be deterministic (or more deterministic than) unlikely a system running on bare metal.

EDIT:

Is /dev/urandom random enough to allow unpredictable salts to be generated on a Virtual Machine?

CoffeDeveloper
  • 516
  • 4
  • 13

1 Answers1

4

The salt in a password just needs to be random enough so that its more or less evenly distributed. The salt is just used to make attacks with precomputed password hashes or rainbow tables infeasible by increasing the needed memory. Thus there is no need for a cryptographically secure random generator. This means that the implementation is secure enough in your case.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • theoretically, system time in epoch could be a suitable salt? – schroeder Apr 28 '16 at 17:02
  • In theory nope. Predicatble salts are to be avoided wich made me asking the question – CoffeDeveloper Apr 28 '16 at 17:14
  • @DarioOO why are predictable salts to be avoided? And how is time predictable? – schroeder Apr 28 '16 at 17:48
  • 1
    Predictable is not a problem. But the system time has not really a wide range of values (within the specific time frame the code is in use). But a simple pseudo random generator with the time as seed should be sufficient. – Steffen Ullrich Apr 28 '16 at 18:07
  • the php wiki specifically says to avoid weak salts, so wich one of the opinions and why? – CoffeDeveloper Apr 29 '16 at 07:59
  • @DarioOO: without having any kind of exact reference (there is more than one page in the PHP wiki!) it is impossible to find out what they really mean (i.e. missing context). This means I'm unable to answer your question in the comment properly. – Steffen Ullrich Apr 29 '16 at 08:27
  • http://php.net/manual/en/function.password-hash.php here search for "Caution It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one. " – CoffeDeveloper Apr 29 '16 at 09:16
  • @DarioOO: there is no conflict with my answer. My answer describes what is needed for a secure salt. /dev/urandom can be used but a pseudo number generation is sufficient too. But you should not use a fixed salt or a salt generator with an obvious bias or a salt generator with only few possible salts because then you don't get the effect you want from the salt. And that's why it is probably better to use a secure default provided by PHP instead of inventing your own and this is exactly what the statements in the PHP wiki means. – Steffen Ullrich Apr 29 '16 at 10:43
  • ok then Good salt need P, but then do dev/urandom have P? – CoffeDeveloper Apr 29 '16 at 14:07
  • @DarioOO: what kind of P you are talking about? Please add context. – Steffen Ullrich Apr 29 '16 at 14:15
  • Let us continue this discussion in chat. – CoffeDeveloper Apr 29 '16 at 16:50
  • 1
    @DarioOO and any future readers, it is worth noting that by "obvious bias" this means a SEVERE bias. For the purposes of a salt, we just want to choose something that hopefully won't repeat between multiple users, thus forcing the attacker to have to try every option for each user with a different salt. If some repetition occurs, this is necessarily horrible, but that would allow an attacker to attempt to crack passwords of multiple users at once. So in practice, a very slight bias (e.g., modulo bias) could be considered permissible for a salt, but very severe biases should be avoided. – Spencer D Aug 04 '16 at 16:15