how much security measure information is safe to publicize?

Question

I am working on writing the privacy policy of a web-app I programmed. I want to tell users about the security measures I have in place (e.g. sha512, variable-length unique salts, and more) but am worried that in the case of data-breach such information would provide additional ammunition for a hacker. Obviously on the one hand if I said "We store all your passwords in a separate file at /etc/pleasedontpwnme" you would be helping nothing and compromising your security.

On the other end of the spectrum if you tell the user "Passwords are not sold to third parties." You have given him virtually no information about your practices.

I want to be as transparent as possible. Indeed, if I open source the code, it will all be transparent. At the same time, I am worried that by describing my defenses I have taken a lot of the hackers work away from him and made his life easier. I am also thinking of the Enigma machines, and how the fact that it didn't encode a letter as itself shows that sometimes "security measures" backfire, and if you tell a hacker up front "we do X Y and Z" the hacker could also notice that Z actually compromises security and use that to breach defenses.

Where I am currently leaning is "We do not store your password, rather we store a 'hash' that is derived from your password, but cannot be turned back into your password. All hashes are salted." It seems pretty safe, except that in worst case, hackers would know not to use a dictionary attack. I would prefer to be as transparent as possible. Users like myself might like to know that the passwords are SHA512 and that they have a unique salt for each password.

TL;DR: How much information about security measures is too much to release to the general public?

This is different from How much security information to publicise? as mine is concerned with how much information is "safe", not how much is best from a readers perspective. It also differs from Correct terminology when describing password security to layman for similar reasons. I am not asking about a specific wording for understandability, rather I am asking for a transparency/security balance.

Answer 1

Kerckhoffs's principle states: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

So, theoretically, there is no such thing as "too much" released information, and whatever you decide to present to your users, other than the actual passwords, should be safe. Relying on keeping this information hidden, can be considered security through obscurity, which tends to be viewed in a rather negative light.

However, Kerckhoff's principle falls apart when implementations are concerned; while the algorithms themselves may be cryptographically safe*, the implementation might not be. If an attacker knows which technical stack your application is built on, exposing implementation details might point to probable exploits.

Also, unless your application is marketed exclusively to people knowledgeable in the field, overwhelming users with (relatievely useless) technical details would only risk turning them away. They wouldn't be able to understand or interpret it. Probably, "We adhere to industry best practices" is enough to satisfy most users.

*) As a sidenote, SHA512 is not a cryptographically safe hashing algorithm. Please consider upgrading to Argon2id or bcrypt. For current best practices, this OWASP cheat sheet might be a good source.