Return to Question

In https://crypto.stackexchange.com/a/27828/79037, it's indicated that one can "save space" by using something globally-unique, like an application-wide "pepper", together with something locally-unique (e.g, a user-id field, unique per-user). In other words, by simply "deriving" a salt (from some other fields/values/etc already there), instead of having to explicitly store a completely random full GUID next to each password.

However, in Should you change salt when changing password?, it's also indicated that salts should also change whenever a user resets their password as well.

And in https://security.stackexchange.com/a/41627/25009 it's also suggested that password salts should also be "unpredictable" relative to one another.

But, precisely how much "unpredictability" is enough? For example, I can construct a globally-unique, per-user password salt like pepper || user-id || nonce, where

• pepper is a globally-unique, application-wide constant
• user-id is a locally-unique, per-user constant
• nonce is a simple random 4-byte integer (changed during password resets) stored alongside the password hash in the database

So, the nonce is only "dynamic" part of the salt. It's only 4 bytes long, which is pretty short, so can definitely be used to save space in the database (at least, relative to simply storing a full 128-bit random GUID next to each password hash as the salt).

But, is 4-bytes of "unpredictability" really sufficient for a password salt? Or, would this nonce have to be even longer, like 64-bits? What if it's a highly-targeted website/app? (Obviously, requiring "128-bits of unpredictability" would negate any "space savings" from this approach anyway, but perhaps so much "unpredictability" between salts may be overkill)...

*Edit -- for reference, I'm imagining a scenario where an attacker gets to "discover" the salt (i.e, pepper || user-id || nonce combination) and password hash for any user at any time. But, there is a specific user, or group of users, however, that are highly targeted, who upon getting hacked always change their password (to perhaps some other simple, low-entropy "human" password), and so thus buy themselves "just a little more time". But -- can they really expect enough "time", with only 4-bytes of "unpredictability" between salts? (Granted, of course, these salted hashes are themselves computed with a pretty nice slow KDF)...

In https://crypto.stackexchange.com/a/27828/79037, it's indicated that one can "save space" by using something globally-unique, like an application-wide "pepper", together with something locally-unique (e.g, a user-id field, unique per-user). In other words, by simply "deriving" a salt (from some other fields/values/etc already there), instead of having to explicitly store a completely random full GUID next to each password.

However, in Should you change salt when changing password?, it's also indicated that salts should also change whenever a user resets their password as well.

And in https://security.stackexchange.com/a/41627/25009 it's also suggested that password salts should also be "unpredictable" relative to one another.

But, precisely how much "unpredictability" is enough? For example, I can construct a globally-unique, per-user password salt like pepper || user-id || nonce, where

• pepper is a globally-unique, application-wide constant
• user-id is a locally-unique, per-user constant
• nonce is a simple random 4-byte integer (changed during password resets) stored alongside the password hash in the database

So, the nonce is only "dynamic" part of the salt. It's only 4 bytes long, which is pretty short, so can definitely be used to save space in the database (at least, relative to simply storing a full 128-bit random GUID next to each password hash as the salt).

But, is 4-bytes of "unpredictability" really sufficient for a password salt? Or, would this nonce have to be even longer, like 64-bits? What if it's a highly-targeted website/app? (Obviously, requiring "128-bits of unpredictability" would negate any "space savings" from this approach anyway, but perhaps so much "unpredictability" between salts may be overkill)...

*Edit -- for reference, I'm imagining a scenario where an attacker gets to "discover" the salt (i.e, the pepper || user-id || nonce combination) and password hash for any user at any time. But, there is a specific user, or group of users, however, that are highly targeted, who upon getting hacked merely change their passwords (to perhaps just another simple, low-entropy "human" password!), and thus buy themselves maybe "just a little more time". But -- can they really expect enough "time", with only 4-bytes of "unpredictability" between salts? (Granted, of course, these salted hashes are themselves computed with a pretty nice slow KDF)...

In https://crypto.stackexchange.com/a/27828/79037, it's indicated that one can "save space" by using something globally-unique, like an application-wide "pepper", together with something locally-unique (e.g, a user-id field, unique per-user). In other words, by simply "deriving" a salt (from some other fields/values/etc already there), instead of having to explicitly store a completely random full GUID next to each password.

However, in Should you change salt when changing password?, it's also indicated that salts should also change whenever a user resets their password as well.

And in https://security.stackexchange.com/a/41627/25009 it's also suggested that password salts should also be "unpredictable" relative to one another.

But, precisely how much "unpredictability" is enough? For example, I can construct a globally-unique, per-user password salt like pepper || user-id || nonce, where

• pepper is a globally-unique, application-wide constant
• user-id is a locally-unique, per-user constant
• nonce is a simple random 4-byte integer (changed during password resets) stored alongside the password hash in the database

So, the nonce is only "dynamic" part of the salt. It's only 4 bytes long, which is pretty short, so can definitely be used to save space in the database (at least, relative to simply storing a full 128-bit random GUID next to each password hash as the salt).

But, is 4-bytes of "unpredictability" really sufficient for a password salt? Or, would this nonce have to be even longer, like 64-bits? What if it's a highly-targeted website/app? (Obviously, requiring "128-bits of unpredictability" would negate any "space savings" from this approach anyway, but perhaps so much "unpredictability" between salts may be overkill)...

*Edit -- for reference, I'm imagining a scenario where an attacker gets to "discover" the salt (i.e, pepper || user-id || nonce combination) and password hash for any user at any time. But, there is a specific user, or group of users, however, that are highly targeted, who upon getting hacked always change their password (to perhaps some other simple, low-entropy "human" password), and so thus buy themselves "just a little more time". But -- how much "time" can they really expect, however, with only 4-bytes of "unpredictability" between salts? (Granted, of course, these salted hashes are themselves computed with a pretty nice slow KDF)...

In https://crypto.stackexchange.com/a/27828/79037, it's indicated that one can "save space" by using something globally-unique, like an application-wide "pepper", together with something locally-unique (e.g, a user-id field, unique per-user). In other words, by simply "deriving" a salt (from some other fields/values/etc already there), instead of having to explicitly store a completely random full GUID next to each password.

However, in Should you change salt when changing password?, it's also indicated that salts should also change whenever a user resets their password as well.

And in https://security.stackexchange.com/a/41627/25009 it's also suggested that password salts should also be "unpredictable" relative to one another.

But, precisely how much "unpredictability" is enough? For example, I can construct a globally-unique, per-user password salt like pepper || user-id || nonce, where

• pepper is a globally-unique, application-wide constant
• user-id is a locally-unique, per-user constant
• nonce is a simple random 4-byte integer (changed during password resets) stored alongside the password hash in the database

So, the nonce is only "dynamic" part of the salt. It's only 4 bytes long, which is pretty short, so can definitely be used to save space in the database (at least, relative to simply storing a full 128-bit random GUID next to each password hash as the salt).

But, is 4-bytes of "unpredictability" really sufficient for a password salt? Or, would this nonce have to be even longer, like 64-bits? What if it's a highly-targeted website/app? (Obviously, requiring "128-bits of unpredictability" would negate any "space savings" from this approach anyway, but perhaps so much "unpredictability" between salts may be overkill)...

*Edit -- for reference, I'm imagining a scenario where an attacker gets to "discover" the salt (i.e, pepper || user-id || nonce combination) and password hash for any user at any time. But, there is a specific user, or group of users, however, that are highly targeted, who upon getting hacked always change their password (to perhaps some other simple, low-entropy "human" password), and so thus buy themselves "just a little more time". But -- can they really expect enough "time", with only 4-bytes of "unpredictability" between salts? (Granted, of course, these salted hashes are themselves computed with a pretty nice slow KDF)...