0

I am currently generating a salted SHA 256 passwords in the below format

$hash = "{SHA256}".base64_encode(hash('sha256', $password . $salt) . $salt) .

Using the below libraries of Java classes to generate.

java.security.MessageDigest
java.security.SecureRandom

I am not sure if the random salt generated via SecureRandom class is secure enough.

  • I wanted to know how different LDAP implementations (OpenLDAP,OpenDJ) are generating the random salt for different password storage scheme like SHA-1, SHA256 etc?

  • Can those salt generation algorithms used by different LDAP implementations be utilised by us in our scripts (using js) to generate same. I am using js scripts (Rhino js engine) to generate salted sha256 password.

  • Are there any other random generators which are secure enough and can be used in our application?

Sir Muffington
  • 1,611
  • 2
  • 13
  • 25
Karan Nayyar
  • 125
  • 1
  • 4
  • You do not mention the size of the salt. As long as you're using a salt that is both cryptographically secure and sufficiently large (say, 128 bits or 16 bytes, like scrypt or bcrypt do), this should be sufficient. – Royce Williams Feb 04 '22 at 20:36

2 Answers2

1

The salt does not need to be secure random. It just have to be unique. Even if the salt is as simple as an incrementing integer, it will suffice.

Salt is just to make sure users with the same password don't have the same hash, so an attacker have to bruteforce every single password, even if every user have the same password. So the SHA1 hash of terrible salt+password would be:

1password: 8ad742ee5d26c1b43701e598e1ed767b4352377a
2password: 0c757723c6b5bd1f130082fc869f50660ed6edf4

In this example, even if the passwords are trivial and the salt is just one byte, an attacker have no way to know. He would have to bruteforce everythin anyway.

To see how OpenLDAP is generating the salt, you could look at the source code. This is left as an exercise to the reader.

ThoriumBR
  • 53,925
  • 13
  • 135
  • 152
  • Salts are random and large enough to guarantee global uniqueness - not just within a specific target, but across many multiple potential targets, in order to make precomputation infeasible. If everyone just started their salt sequences with 1 or 100 or 1000000, the values will be biased - and both precomputation and direct attack could trivially take advantage of that bias. That's why hashing algorithms like bcrypt, scrypt, PBKDF2, etc. use random, rather than sequential, salts. Put another way: as an attacker, I encourage everyone to use sequential salts ;) – Royce Williams Feb 04 '22 at 20:32
0

According to the Oracle docs, java.security.SecureRandom does appear to generate enough high-quality randomness to be fine for salt generation, as long as it's seeded well:

A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.

How large is the salt? As long as you're using a salt that's both random (enough to be unpredictable) and also sufficiently large (say, 128 bits or 16 bytes, like scrypt or bcrypt do - enough to be globally unique "enough"), this should be sufficient.

More generally, it looks like you're having to "roll your own" implementation of this hash? If you can find a standard library for your language/platform that natively handles SSHA256 hashes - including handling the salt generation - your solution is more likely to be robustly resistant to other kinds of problems.

Royce Williams
  • 9,573
  • 1
  • 33
  • 57
  • Why has the salt to be random enough to be unpredictable? – Michael Uray May 05 '23 at 07:01
  • @MichaelUray Because if it can be predicted, it can be precomputed. See https://security.stackexchange.com/a/41618/6203 . For most implementations, randomness and size are the easiest way to avoid precomputation. – Royce Williams May 05 '23 at 15:00
  • Thanks for the link. I understand now that an attacker could pre-calculate rainbow tables before he has the actual access to a database which contains the hashes + salts. This is probably not a big benefit for an attacker, but fair enough, that known I also would create it rather randomly as by an useranme/e-mail combination just to make it harder for an attacker. – Michael Uray May 19 '23 at 17:03