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 https://crypto.stackexchange.com/questions/18963/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][1]) 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)...

  [1]: https://crypto.stackexchange.com/a/18990/79037
  [2]: https://en.wikipedia.org/wiki/Key_stretching