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.


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

  • 1
    are you asking about the randomness of urandom or the suitability of urandom for generating salts? Or are you asking how random a salt must be to remain secure?
    – schroeder
    Apr 28, 2016 at 16:55
  • I'm asking for suitability of urandom for generating salts when running the system on a virtual machine (like many modern hosting services) wich is likely to be runned from a system image Apr 28, 2016 at 16:59
  • Then Steffen has your answer
    – schroeder
    Apr 28, 2016 at 17:01
  • I'll give the usual 24h interval before accepting to see more answers, possibly by someone who already investigated the issue. Apr 28, 2016 at 17:13
  • 1
    Not that this is an authoritative source, but read over the following if you want some information about urandom and its security: 2uo.de/myths-about-urandom
    – Spencer D
    Aug 4, 2016 at 15:59

1 Answer 1


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.

  • theoretically, system time in epoch could be a suitable salt?
    – schroeder
    Apr 28, 2016 at 17:02
  • In theory nope. Predicatble salts are to be avoided wich made me asking the question Apr 28, 2016 at 17:14
  • @DarioOO why are predictable salts to be avoided? And how is time predictable?
    – schroeder
    Apr 28, 2016 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. Apr 28, 2016 at 18:07
  • 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 4, 2016 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .