Does it make any sense at all to salt a hash which might be available publicly?

It doesn't really make sense to me, but does anyone actually do that?

UPDATE - Some more info:

An acquaintance of mine has a common salted-hash function which he uses throughout his code. So I was wondering if it made any sense at-all, to do so.

Here's the function he used:



Sorry if it wasn't clear. By available publicly I meant, that it is rendered in the HTML of the project (for linking, etc) & can thus be easily read by a third party.

The project is a python based web-app which involves user-created pages which are tracked using their hashes like myproject.com/hash so thus revealing the hash publicly. So my question is, whether in any circumstances would any sane programmer salt such a hash?

Question: Using hashlib.sha256(string+SALT).hexdigest() vs hashlib.sha256(string).hexdigest() , when the hash isn't a secret.

  • rendered in the HTML of the project (for linking, etc) doesn't makes sense to me. HTML for linking? (possibly because what your friend is doing doesn't make sense)... Edit the question and add in it every bit of detail you can think of. In strange situations there might be a very specific reason behind everything, but you'll have to give us the whole picture...
    – Yannis Rizos
    Nov 19, 2011 at 20:22
  • What is the nature of the string you're hashing? Where is the hash stored? Nov 19, 2011 at 22:05
  • @Gilles Its a string like user-id (from open-id) or content-id (Which is generated depending on the user-submitted content)
    – Sathvik
    Nov 20, 2011 at 3:59

2 Answers 2


Yes. It's normally taken for granted that the salt will be available to an attacker. The salt does not need to be kept secret to be useful.

Salting a hash is done primarily to protect against a dictionary attack. A dictionary attack works by hashing common words (e.g., everything in a dictionary, thus the name) and then comparing hashed values to those from the dictionary. If you find a match (and for things like hashed passwords, you usually will) you know what word produced that hashed result.

The salt simply makes this type of attack consume a great deal more time and (especially) storage space. Just for the same of argument, let's say a relatively complete dictionary (including lots of names and such) with hashed results took 3 days to compute and occupied up a gigabyte of storage.

If we add, say, a 16-bit salt, the computation would now take roughly 65536x3=196,608 days = ~538 years. Storing the result would require roughly 64 terabytes instead of one gigabyte. In fairness, most people won't have 65536 users (for example) so the attacker would probably collect the salts and hashes, and only do a dictionary attack on the salts you actually used. This still means one dictionary attack per user (or whatever) rather than one for everybody.

For most purposes, that makes the difference between something almost anybody could do just because they felt like it, and something that only an fairly determined attacker (and probably well-funded) attacker would even contemplate.

  • 3
    Actually, the word dictionary attack refers to trying a list of possible passwords which then will tried (instead of all passwords thinkable), not the table of hash => word you used. This is known as a rainbow table attack (where a rainbow table actually is a specific implementation of a list of hashes), and salting mainly protects against rainbow table attacks. Nov 19, 2011 at 22:13
  • 2
    Sorry @Paŭlo, but no. Although the terms are abused a great deal, something that starts with specific words (and names, etc.) and hashes each one, really is a dictionary attack. A rainbow table is based on building hash chains, which is quite a different proposition. The table you build, the computation to build that table, and the way you use it are all entirely different from a dictionary attack.
    – Jerry Coffin
    Nov 19, 2011 at 22:55
  • @Jeffy: Although salt is useful in preventing dictionary attack and everything you wrote is good info, I don't think that type of attacks is as useful today (i.e. "bob5" password defeats them). Real power of salt is that they make rainbow table attacks much more difficult and that's the type of attack that is becoming very common because they can break any random combination of lower/upper case letters, numbers and commonly used punctuation if your password is N characters or less.
    – DXM
    Nov 19, 2011 at 23:32

The idea of a salt for a hash is that the same message does not result in the same hash for every hash, but that it depends on the salt, too.

(The same idea applies to an initialization vector for encryption functions.)

If I understand the question right, you are hashing the contents of a user-contributed page to create a URL for it. Salting then could have the goal that two users, uploading the same content, still will get different URLs for their pages.

The secrecy of the hash or salt is not really relevant here.

On the other hand, you need to store the salt somewhere, so I don't really see how this is a good idea for a hash function at all - you could just as good simply take a random number alone as the identifier.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .