0

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.

2

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.

1
  • Thanks for the answer! If I understand correctly, SHA512 is dangerous because of it's speed, not because of any security hole. My salts are stored in a separate "database" thus the speed would only be a concern in the case of both a breach of the passwords and the salts. I am a little concerned about performance. (If my app gets thousands of users logging in, and has to hash the passwords with an expensive algorithm users will experience significant lag. I know that is a separate topic, so I will do my research. Thanks again!
    – JohnpaulÞ
    Jun 11 at 15:50

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.