As I understand it, the salt is used to ensure that a hash of two of the same strings results in a different hash.
The salt is often stored with the hash, either prepended or as a separate field.
As this just needs to be "different" for every input, would using something like:
To get a number string down to the millisecond - If you can guarantee that you'd not have two requests in the same millisecond. This would be unique per record and provide the means to change the hash.
As an example, if I run a basic hash:
using (HashAlgorithm algorithm = SHA256.Create()) return algorithm.ComputeHash(Encoding.UTF8.GetBytes(inputString));
If my input string is
BabySharkDoDoDoDo - every time this is hashed, I'll get the same result:
So, to make sure each entry to my shark database is unique, I prepend the
DateTime.ToString("yyyyMMddHHmmssffffff") - so my input to the hash becomes
202104132059471235487BabySharkDoDoDoDo and each time I get a unique hash.
So I can check the input is valid, if someone enters the right record and the string
BabySharkDoDoDoDo I need to store the salt, either with the hash or in the separate column.
So, the salt is known to the attacker - always the case right? So making a super strong salt, with crazy random entropy to then go and store it right next to the data it's salted makes me think, is this wasted effort? Or theatre to seem great but really all you need is a unique piece of data to provide the salt?
If I go for it and create a 128 bit salt, from a crypo library, Rijndael or similar - sure it's unique (hopefully), but I then go and prepend it to the saved hash - right? Otherwise, I can never check the hash against a known input.
A timestamp down to the millisecond or tick would also be unique and serve the same purpose?