Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For example, on the user registration page, is it safe to tell people "Your password will be stored as a one-way hash using the (whatever) algorithm."

share|improve this question
Unless your user base is made up of the same sort of people who populate, you might as well say "your password is stored as flibbity jibbity sprinkled with unicorn beans." Then again, if I read someone proudly proclaiming the hash algorithm they use WITHOUT mentioning salting, I would becoming immediately nervous. – Digital Chris Jun 20 '14 at 14:57
Your password is now being stored in super secure ROT-13 – user49637 Jun 20 '14 at 15:03
Aside from technical issues, I'd be concerned about potential liabilities. If you proclaim to use a specific technology for security, and then it is found that you did not use it in an instance that resulted in an event, your customers have a specific liability claim. That's why in general, businesses say what they will do, not how they will do it, unless the process is key. – schroeder Jun 20 '14 at 15:05
See Kerckhoff's Principle. – Iszi Jun 20 '14 at 21:28
@user49637: ROT-13 by itself isn't secure. Apply it four times in a row. – Tom Zych Jun 22 '14 at 0:55
up vote 74 down vote accepted

If it is not safe, then your hash function is pure junk, and you should not use it.

In any decent security analysis, it is assumed that the attacker already knows all the software that you are using, because:

  • There are not so many possibilities.
  • A lot can be guessed based on application behaviour and output.
  • An attacker who could get a glimpse at your database might also have a copy of your PHP scripts, and thus knows.
  • Even in cases where the attacker does not know your hash function, it is very difficult to quantify such lack of knowledge: to what extent does the attacker not know ?
  • In particular, the attacker may also register as a user, with a password he chooses, and then observe the resulting hash, allowing him to quickly test any potential hash function.

On the other hand, making the used hash function explicit may give you a reputation of "competent site owner" which would bring confidence to technically-inclined customers.

share|improve this answer
Whether you have a reputation as a "competent site owner", knowing the hash algorithm used helps you choose your own level of security for the site. If someone's using sha1, you probably want something like 80 bits of entropy to be safe. Scrypt with 5000 rounds, maybe less. If someone discloses they're just matching the first 16 characters of an MD5 hash, you know never to disclose anything important to that site. – Paul Jun 22 '14 at 7:22
The Open Web Application Security Project (OWASP) documentation gives a clear message that security through obscurity is never good enough. A really strong security system is one where the attacker can know everything about your system, but still can't break in. – Adam Jun 23 '14 at 9:41

In a purely technical sense, yes, it is safe to tell your users which algorithm you use – as long as the algorithm is any good. This is no secret information, and trying to hide it would be rather silly.

However, if you make a big announcement that you use, say, bcrypt, this may backfire. Your users might be tempted to choose even weaker passwords, assuming that your magical hash algorithm keeps them secure either way. In fact, there have been several questions on this site where people actually believed that using bcrypt makes password strength completely irrelevant. This is of course not the case. So you have to be very careful not to give your users a false sense of security.

Long story short: It's fine to tell anybody who's interested and (hopefully) understands that they still need a good password. But I wouldn't put a big message in the registration form. People may draw the wrong conclusions from it.

share|improve this answer

I'd say that it is safe as long as the hashing algorithm you use is secure. Otherwise, it may give an incentive to go after your database.

As a user, I have to admit that I wouldn't mind more transparency from the sites on which I register, regarding how the credentials are stored. But less technical-oriented users may be taken aback and/or miss your point, so make sure that your target audience cares about this information.

In any case, the strength of your password scheme doesn't rely at all on it being secret: it relies on cryptography being peer-reviewed. Therefore, disclosing what algorithm you use shouldn't matter.

share|improve this answer
One may note, though, that there happens to be no mathematical proof whatsoever that hash function can actually exist, let alone that any concrete hash function is "secure". Cryptography, in general, is NOT "mathematically proven". Cryptography instead relies on the combined brain power of cryptographers, a process which works well (or at all) only in a full disclosure context. Therefore, one may say that the strength of a scheme not only does not rely on the scheme being secret; it positively relies on the scheme being non-secret. – Tom Leek Jun 20 '14 at 14:40
Thanks for pointing this out. I have updated my answer to correct this mistake on my part. – executifs Jun 20 '14 at 15:56

It is safe if your hash / key stretching algorithm(s) are safe, but it is not necessary and probably not a good idea. I would suggest telling users vaguely how your passwords are stored (e.g. "key stretching, which includes several iterations of a one-way function"), but not make mention of the exact algorithm.

Keeping the method of hashing (or even the entire method of authentication) secret is an instance of security through obscurity, which is usually frowned upon. However, most of the time, that frown comes from a misunderstanding, much like people often misinterprete Hoare's quote on premature optimization as "don't optimize".
Security must not depend on obscurity alone, however, obscurity in the right place can certainly add to security.

A cryptographic algorithm must work reliably even if the attacker knows all the details of the algorithm, and it is assumed that he does. For that reason, cryptographic algorithms are usually fully disclosed and nobody will trust a "secret" cryptographic algorithm.

Your security strategy must likewise assume complete disclosure as the worst case scenario, and your system must still work reliably in that case.
But that does not mean that you absolutely need to disclose every detail.

Telling your users vaguely, on a high level, what your password storage strategy is may give a good impression to the user but does not nail you down to something in particular (including possible liability issues as pointed out by schroeder in a comment above). Obscurity may be both a way of deterring and delaying an attacker.

A bit of obscurity on the exact algorithm is both akin to putting a big, prominent door bolt on your front door with a hidden, protected lock slit, and to putting your money into the safe before leaving your hotel room.
A big bolt with a hidden, protected slit is probably not much safer than a cheap lock because you can just bash the door down with a sledgehammer or throw a boulder through the garden door anyway. However, it tells a prospective burglar that you are wary and that other safety measures which he does not know about are likely, and it's probably less trouble to break into another house. There might not even be a bolt under that protected lock, and it will still server its purpose.
A hotel safe usually takes 4 numbers (and occasionally the hotel manager forgot to change the emergency code from 0000, too). Fingerprints trivially allow a thief to open the safe in under 3 minutes, so that's not very safe indeed. However, 3 minutes is an eternity to a hotel room burglar, every additional minute bears a risk being caught -- they rarely stay in a room for longer than 3 minutes alltogether. Which means that the unsafe safe is literally safe compared to having your money and your rolex on the table, simply because the objects are somewhat obscured and held back.

It is much the same with an online attacker. While it is unlikely that you will discover the intrusion as it's happening, the intruder nevertheless has less time available before you do, since he not only needs to download the password database, but also needs to figure out the "secret" hashing algorithm and salts. It may not be a lot of time, but it's something that doesn't cost you anything. Why give it away?

If you tell an attacker that you use MD5 to hash your passwords, then he will immediately know that he can crack your entire user database in under 2 seconds, and you most likely aren't very up-to-date with security alltogether, which means you are a very attractive target. If you tell an attacker that you use a "key stretching system with many iterations", he can figure that it's probably a considerable amount of work to crack even a single password. Plus, it's extra work to figure out what algorithm exactly you use.
If your site is only one on a list of 20 interesting targets to attack, it has just moved to the bottom of the list.

share|improve this answer

If the hash is safe and, more importantly, how it's used in the site/application is safe, then you should be able to open source the entire code running the site/app and you should be no less secure.

So, yes, IF the implementation is safe, disclosure is safe. That's a big IF.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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