Can I share what password hash function I used in a public report?

Should you make the algorithm public?

Trying to hide implementation details (such as which hashing algorithm you use) to preserve security is the very definition of security through obscurity. There is broad consensus that obscurity should not be your only line of defense.

If you need to keep your hash algorithm a secret, you are doing it wrong and need to pick a better hashing algorithm. When you use a good algorithm, there is no reason not to tell the world about it since they won't be able to crack your hashes anyway.

Also note that in your case the salt will give you away. If someone gets hold of your database, they will be able to read what algorithm was used from that. So obscurity does not make brute forcing harder here. Advertising a weak scheme, however, might encourage attackers. A strong one could have the opposite effect. The point Mike Goodwin makes in his answer should also be taken into account.

Is crypt() secure?

The relevant question to ask is therefore if crypt() is secure enough. Let's have a look at the PHP manual:

password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.

Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

The function uses different algorithms depending on how you format the salt. Some of the algorithms are very weak, and the strong ones might not be available on all systems. So depending on the algorithm used, there are a number of problems here:

• For some algorithms crypt() only applies one round of hashing. That is too fast, and will enable a brute force attack.
• Under some circumstances crypt() will use MD5, which is known to be weak.
• Only using the first eight characters completely nullifies the benefits of long passwords.

I therefore suggest that you switch to password_hash(). It lets you use bcrypt - a tried and tested algorithm. Then you can proudly tell the world about your hashing scheme.

@Anders is correct that security through obscurity is no security at all.

Having said that, publishing implementation details gives information to attackers that they could use if vulnerabilities are discovered in your implementation in the future or it the attacker has zero-day vulnerabilities.

Think of it this way - many penetration tests begin with a reconnaissance phase that discovers protocols, technologies and versions in use. This info is then used to attempt known exploits if there are any.

If this kind of information is useful to pen testers, then it is also useful for attackers. Why make their lives easier by doing part of their job for them? All other things being equal, they are likely to focus on the systems that make things easier for them ahead of the ones that make them work harder.

On balance, unless there is some clear benefit to you or your employer in publishing the technical details, I would keep them private. Work on a need-to-know basis.

Just to repeat though, to avoid downvotes - I completely agree that security through obscurity is no security at all ;-p

Not only can you, you absolutely should.

Kerckhoff's principle dictates that the only valid thing for the security of your system to rest upon is the secret key, and that any secure system should be designed with the notion that "the enemy knows the system" assumed to be true up-front.

Therefore, by Kerckhoff's principle, sharing the details of the system can't make it any less secure, because you must assume up-front that the enemy already knows the system, because the bad guys are willing to hack and commit espionage to get access to the workings of it. What sharing can do, however, is help make your system more secure by sharing it with the good guys, experts who would be able to analyze and review it. If there are vulnerabilities, good guys and bad guys will both find them, but the bad guys won't share them with you so you can fix them.

Therefore, if you want your system to be secure, you can't afford not to share how it works.