I use the Rfc2898DeriveBytes for creating an AES key for protecting the user's data.
For the salt value I would like to use the user's id, which is a guid.

My understanding is, that the only drawback of using the user’s id would be, that it will get easier to crack keys which were previously built for this specific user, in case the attacker is in the posession of the database. But since the attacker has already cracked the current key, there is no need for cracking elder keys, therefore I don't see this as an issue.

Is it a problem to use the user’s id as a salt for the key derivation?

Guid type
As an additional information, the guid is a Windows Sequential Guid. Therefore it is not really random but quite unique.

  • is the user's GUID-id publicly known? May 19, 2018 at 11:35
  • Not directly, but it is not kept as a secret. Web-applications use it as record-and user-identifier and therefore it is used in server-requests-and responses.
    – HCL
    May 19, 2018 at 12:23
  • Then you shouldn't be using GUID-id as a salt..If the salt is known it still can be bruteforced with a program like "John the Ripper" assuming the secrect key isn't that large. May 19, 2018 at 12:36
  • 2
    a salt doesn't protect anyone, just everyone. basically, it keeps an attacker from using password guesses on the whole list instead of a single user, multiplying attack time for the group by N users. The time for cracking each individual user is relatively unchanged by adding a salt, and that's why it need not be secret. If the guid itself is valuable, you can simply hash it before storing it to used as a salt: it's "hard" to brute-force a guid, so you don't need further derivation expense.
    – dandavis
    May 19, 2018 at 20:53

1 Answer 1


Given that you say the GUID is sequentially assigned and sent in network traffic, no, it is not suitable for use as a salt. While it will still prevent the typical scenarios of "attacker wants to crack all your passwords, so they build a rainbow table that can be used to look up any hashed password" and "two users used the same password, and you can tell because their hashes match", it's still weaker than it should be.

In particular, it does not prevent the scenario of "attacker wants to crack a specific password, so they build a rainbow table using that user's (known) salt". Yes, the attacker still needs to get access to the user's password hash, which implies they'd have access to the salt anyhow, but normally that then begins a race between the site admin noticing the breach and the attacker managing to brute-force the slow hash (you did use an expensive hash function, right?). If the salt is known in advance, the attacker can perform the slow process of brute forcing the hashes (by building a rainbow table), and then instantly determine the password once the user's hash becomes known.


You must log in to answer this question.

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