tl;dr this is not a duplicate of "what is a salt/why use salt?" question. Instead it is specificly asking when salt may not be necessary for hashing securly? (i.e. when the data being hashed is already as high-entropic as that chances for duplicates is very very low)
Reasoning underlying the question To my currently best understanding, it is that
- salting is prevention against the usage of rainbow tables. (and only that)
- rainbow tables are stored up precomputed original-data,hash-value pairs for a set of more or less frequently occuring original-data (i.e. the 100,1000...10^x most often used passwords)
- rainbow tables are increasingly useless, the more and more random/entropic the original-data is. (The sum of all passwords used today may be very well smaller than 2^64 and hence less entropic than a truly random 64bit value)
My question is, that given that my assumption 3. above holds, then I would expect that salting (given 1. holds) becomes an decreasingly necessary endeavour.
Can this be confirmed or contradicted, please?
This is not only an academic question, but I have stumpled upon it in real life™ and maybe this serves as a way to bring this question also to a practical and henceforth more understandable / answerable level.
The case is that looking back at some work I have started prior to become crypt.stackexchange.com user I see with shock that I have stored data in a database in a plaintext fashion, that is used for authetification. In the very case it is a nonce created for an email verification (which is sadly anyway an unsafe channel, yet not in my power to prevent and not the issue here).
The nonce is unique and created from
/dev/urandom. With hashing I would prevent that somebody having access to the database can access the nonce. If it was a password I would use a salting when storing it (because as mentioned I prevent rainbow-tables).
I think a rainbow-table for my 128bit value seems to defy its purpose as and I really wonder if I need to salt the unique nonces?