6

Do you think it’s a good idea to disclose your password encryption policies in your privacy policy or terms of service agreement? In other words, would you tell your users - and the world - you don’t store their passwords in plain text, and disclose the exact method you use to store passwords? For example, a privacy policy might have a statement like this;

“We will not store your password as plain text. All passwords are encrypted with the Bcrypt hashing function and individual random password salts. If your password is 123456, your password would be stored in our database in a form similar to; salt:f11ba67d8a hash:$2a$08$jRAovt7x1lgHjMGsZstzUukaE4Nga6jxfneZXPSMc6/Uhlx.rY4ri Therefore, our website - nor anyone else - will know your your password.”

Question #1: Do you think publicly disclosing password hashing is a good policy?

Question #2: Would disclosing password hashing policies disincentivise hackers from attempting to hack your password database?

Also, are there any examples of companies / websites who publicly disclose their password encryption policies on their sites / apps?

The only relevant question I found is Is it safe (or a good idea) to advertise the use of bcrypt?, which asks if encryption is a feature or a selling point.

I'm more interested in "encryption disclosure" as a policy and a deterrent to hackers.

PS: This is not a question about which password hashing scheme or use of salts is best.

EDIT: To be clear, I’m not interested in the pros and cons of “Security Through Obscurity.”

In the past several months and years, we’ve witnessed high profile data breaches and found out that apparently sophisticated companies are storing passwords in plain text or with a very low standard of encryption.

So my question is, is how do we communicate to users and the world we’re storing their passwords with strong encryption?

And like @JonathanGarber mentions in the comment below, should we disclose specific methods, instead of saying useless things like "we meet industry standards" or “military-grade encryption”

Community
  • 1
bmorenate
  • 163
  • 5
  • 5
    Speaking for myself, I prefer seeing details, regardless of whether it may be less obscure or not. Sites with nebulous claims of "high-grade encryption" (or "military-grade encryption", blech) and "we meet industry standards" frustrate me because those claims are largely meaningless. (As a parallel example, Etsy (mostly) discloses exactly what tracking/analytics they use, with explanations of what each does. I prefer this to "we do this to make things better for you".) – Jonathan Garber Feb 25 '14 at 16:57
  • 1
    Yes, more and more I turn to Etsy as a role model and I like their privacy policy. – bmorenate Feb 25 '14 at 17:19
  • It should be sufficient to state which best practice you follow: password are protected by standards specified in in (iso 123) – Dog eat cat world Mar 14 '14 at 09:51

3 Answers3

4

There are good and bad things about revealing your password encryption in a document.

For:

  • When you disclose your encryption algorithm, if you're doing something wrong, someone is more likely to point it out to you.

Against:

  • If one of the people that has access to the documentation wants to attack your system will already know the encryption method you use. (they will still miss implementation details like, the actual salt used though)

Check this great question/answer: At what point does something count as 'security through obscurity'?

Generally speaking, disclosing information is what makes public knowledge evolve, so I think it's a great policy morally speaking.

Community
  • 1
Sandokas
  • 281
  • 1
  • 5
  • Thanks for the link, it was a good read. I don't understand your statement, "Someone that wants to attack your system will already know the encryption method you use." How so? As of right now, my encryption method is not disclosed. The only way to discover it is through the server-side application layer or in the DB. – bmorenate Feb 25 '14 at 15:29
  • 1
    Most attacks are either opportunity attacks or job driven. If the opportunity is there to access your database someone is bound to do it anyway, doesn't matter what encryption algorithm you claim. Does claiming my auto-radio will be a dud stop people from stealing it if I let my car door unlocked? – Sandokas Feb 25 '14 at 15:48
4

I would say that the best option is to disclose high-level technical details of this kind of control, so for example "we store your passwords using a hashing algorigthm (bcrpyt) specifically designed for this purpose. Passwords are never stored or transmitted in an unencrypted format"

This doesn't really provide an attacker with anything they can use to attack you (unless they know of a vulnerability in bcrypt of course), but does avoid snake oil sounding statements like "military grade encryption" which will put some more security-savvy customers off your product.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 1
    Worth noting that several off-the-shelf bcrypt hashing libraries will use a variation of RFC2307 format anyway. Those strings start with an obvious `$2a$` part that identifies the algorithm. As an attacker with a copy of the data: 1) I'd know immediately you'd used bcrypt, so you might as well make it public. 2) I'd probably restrict password searches to common password lists and simple dictionary attacks (provided I don't see `$2a$3$` or some other low repetition) – Neil Slater Feb 25 '14 at 19:20
  • Thank you for your answer. I think your general "high-level" approach is probably the way to go. Even though >99% of my users will not understand the nuances of encryption methods to begin with, this should still provide an outline of how their data is being stored. – bmorenate Feb 26 '14 at 02:22
0

If you want to keep it a secret for security reasons, then, of course, you're doing it wrong.

Primarily, however, unless you have a very specific, very technical audience, they REALLY DON'T CARE. What people want to hear, unfortunately, is that you have "military grade encryption" and "we meet industry standards". For the most part, these are the people who use "password" for their password, stick their passwords on their monitor, and/or re-use one password for everything. THIS DOES NOT MEAN YOU SHOULDN'T DO YOUR PART TO SECURE PASSWORDS, just that telling users your methods isn't what they want.

Even from a security perspective, the problem is almost never in the algorithm, always in the implementation.

Personally, I think a better solution is something like OAuth. It does not apply to all systems, but adding yet another password for your users to remember is not a good way to improve the password situation. Take StackExchange as an example.

AMADANON Inc.
  • 1,481
  • 9
  • 9