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?

  • 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 '16 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 – GameDeveloper Apr 28 '16 at 16:59
  • Then Steffen has your answer – schroeder Apr 28 '16 at 17:01
  • I'll give the usual 24h interval before accepting to see more answers, possibly by someone who already investigated the issue. – GameDeveloper Apr 28 '16 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 '16 at 15:59
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.

  • 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 – GameDeveloper 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
  • 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 '16 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.