0
$\begingroup$

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

  1. salting is prevention against the usage of rainbow tables. (and only that)
  2. 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)
  3. 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?

|improve this question
$\endgroup$
  • 1
    $\begingroup$ Salting prevents many multi-target attacks, not just rainbow tables. $\endgroup$ – CodesInChaos Dec 5 '14 at 12:18
  • $\begingroup$ @CodesInChaos according to what you present about multi-target attacks yourself in this answer here crypto.stackexchange.com/a/3688/12545 ,you conclude with "This means users of your system should have stronger passwords than users of normal systems.". my csPRNG generated 128bit seems to qualify perfectly for a strong password. Maybe you can let me know more about multi-target attack in an answer even, thank you! $\endgroup$ – humanityANDpeace Dec 5 '14 at 13:29
1
$\begingroup$

Passwords should use a password hashing function. Password hashing functions are different from basic cryptographic hashes, though they use cryptographic hashes as part of their construction. Password hashing functions must use salt. (Password hashing functions can also tune their time and/or memory usage, cryptographic hashes generally can't.)

So for your case, you probably don't strictly need a password hashing function. More importantly you probably want to not store the nonce in the database at all.

|improve this answer
$\endgroup$
  • $\begingroup$ Thank you for the insight. What leaves me a little puzzled is the idea about not to store teh nonce. I agree that there is no need to store the nonce forever. Yet I need to store it temporarily else I could not use it and I assume that it would not hurt to store it hashed as this is sufficient for verification. $\endgroup$ – humanityANDpeace Dec 5 '14 at 16:24
  • $\begingroup$ Stating that the salting is a necessity for the case that what is being hashed is a password, do you then leave the assumed room (and focus of my question) that there might be else cases where the salting is not strictly necessary/ to be seen as an improvement? $\endgroup$ – humanityANDpeace Dec 5 '14 at 16:26
  • $\begingroup$ I didn't say not to store the nonce, just not to write it into the database. Since it's a small temporary value you can likely just keep it in memory, since the e-mail verification should time-out after a few hours to a day anyway. As for cases when you don't need to salt at all when using a hash, providing a hash of a file to ensure it transferred correctly is the most common case. Git uses hashes for version control, if the contents change the hash changes, so different versions can be uniquely identified. There are lots of uses for hash functions that aren't authentication. $\endgroup$ – SAI Peregrinus Dec 6 '14 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.