How to assure users that website and passwords are secure

Question

On reliable websites I always see claims such as "All data is encrypted" or "All passwords are encrypted using 128bit encryption" and etc. However I have never come across a claim such as "All passwords are hashed."

On my website, I will be storing all user passwords in a database after using SHA-512 (most likely) hashing with a random salt. I want to add a snipet assuring users that their passwords are secure so they will not be deterred from using my website because it requires a password. I want users to feel secure but I do not think everyone knows what hashing is.

MY QUESTION: Is it okay to provide a message saying that "All passwords are encrypted and secure" since I do not think that the average user will know what the difference between hashing and encryption is, and will more likely feel secure just because they see the comfort word "encryption"? Or is there an alternative message I should provide?

On a side note, I am new to encryption and password hashing and I was wondering if this would be safe enough for now as I launch my site. I do not want to tell users it is secure if it is not. Any information would be greatly appreciated. Thanks.

Answer 1

1. Users don't care.

   The only time they care is when somebody withdraws the money from their bank account and it appears that it has a link that a few days before, somebody gained full access to your database.

2. In nearly every case I've seen such messages, they were misleading. The most hilarious one was on a website with "military-grade secure"-style labels on every page. There was an alert telling that HTTP certificate is invalid. There was an SQL Injection on logon form. A few weeks later, the website was hacked, then disappeared forever.

   I stop counting the number of websites which claim that they keep the information secure, while having a "Recover my password" form, which actually sends the original password by e-mail.

   It's like those "W3C valid XHTML" labels. Why are they usually put on websites where even a home page contains at least dozens of errors and code like <DIV COLOR='red'>?

If you still want to reassure the users, you can put something like:

Your passwords are kept secure. Remember that we can't see your password and will never send you an e-mail asking you to provide one.

But frankly, the "Reset my password" form replacing the "I forgot my password; send it to me by e-mail" is much more reassuring than any words.

Hints from the different comments:

• Don't reinvent the wheel: use OpenID. This way, you don't even store the hashes.

  Source: comment by Jan Hudec.

• Since you're a student, open source your project. Since your concern is: "I don't want users to think that their passwords are not secure because some kid in school designed it.", there is nothing more reassuring that being able to check, by reading the source code, that it was written by a skillful developer who cares about security.

  Source: comment by Jan Doggen.

Answer 2

Don't store passwords in the first place! Follow the example of Stack Exchange and let users log in with their identity on another site that provides authentication via OpenID. Implementations are freely available for most common web frameworks.

Or possibly any other protocol. If it is in-house project for some institution (as your comment on the other answer suggests), there almost surely already is a LDAP, Kerberos (Windows Active Directory is based on those two too; apache supports HTTP authentication against them) or some such service for computer login. Just connect to that.

This saves you from storing sensitive information (you'll most probably still have to store permissions, but they are not that critical) and the users from having to remember yet another username and password, so overall win-win.

Answer 3

Saying:

"This is secure."

is a personal judgment you make about certain technological facts or processes, and this judgment is limited by what you yourself know about security at that time. But can you guarantee without a doubt that your encryption, storage method, etc. will hold up to any kind of attack, even ones you don't know about, or don't know about yet?

Meaning: This statement is in danger of being out of date, perhaps even without your being aware of it.

I therefore tend to agree with the above comment by @JoachimSauer: Just describe what you do, how you save user information, and tell users how this is supposed to make your service secure. Then let the users judge for themselves.

Answer 4

It really depends on the context of your specific website.

For example, if this is a consumer website, odds are that most of them will only care about their passwords (maybe), financial/health information (depending), and their private information such as pictures (hahaha, yeah right...).

If this is a business application, then the level of security of the entire site is relevant, not just passwords. Likewise, it depends on who your target users are - highly technical / not so technical, etc.

All this context greatly defines what you should be communicating, and what level of assurance is required.

For example, for non-technical consumers, it is sufficient to have some generic, simple comments, such as:

This site is built using state-of-the-art security techniques. Your password is always encrypted, and we will never ever send your pictures to the NSA.

(And, as others have said, you are better off not even having passwords at all, use some standard like OpenId or OAuth.)

For highly technical businesses, you would want to have a full page of technical and procedural details, such as:

We have implemented a full SDL (secure development lifecycle) throughout our development and deployment process.
...
Our security architecture is ... This gives the benefits of...
We ensure secure coding such as ... by... We perform these and those tests.
Our cryptography includes these algorithms... and ... We are compliant with whichever industry regulation you need, and certified for...
Our security is verified by this independent 3rd party consultant.
...
For more details, and to review our policies or to arrange an independent audit, please discuss with the marketing department.

Of course, you don't want to be giving away too much detailed information, it should be more about the process than the passwords themselves... And of course it should go without saying that the reality should actually comply with whatever you write there, whichever context you are dealing with.

As one of the answers alluded to, most users don't care, wouldn't understand whatever you tell them, and would still sign up anyway, even if you say that you DO send user data to the NSA.
This is not for them.
They would be just as happy not having any passwords, just let me pick my username from the list and log me in automatically.

Obviously this is for the small percentage that care - you should be enabling the smart users to do what's right, to give them the information they need, and grant them the education they might ask for.
If you don't, when that goes wrong, the other 98% will suddenly wake up and get angry.
("Sure, I knew that I don't need a password to see my pictures, but I didnt think that anybody else could also see them!!")

Answer 5

If you want your system to be secure, the strength of the password algorithm is meaningless - most hackers can crack passwords in next to no time, especially if the password chosen is small or is comprised of generic words that the hacker already "cracked and stored" usiong rainbow tables and similar. Read ArsTechnica's article on password cracking for a lot of insight.

What you need to do is assure users that the bad guys cannot get to their hashes in the first place. One security-conscious firm I worked for had a 3 tier web system where the web servers were physically not connected to the database servers. When my boss wanted to put his website on and have direct access to the DB (poorly designed code, 'nuff said) he was told he couldn't have it, and when he pushed... was told there was no wires between them. He had to architect it so it passed all data requests through a middle tier service. And those services were not only secured, but exposed minimal surface to attack, and were locked down. And the DB never exposed any of its tables for reading, only stored procedures that in turn were locked down so only the relevant service had access.

It wasn't as bad to code for as you might think, once you knew the architecture and the separation of each tier, it was quite easy to code for.

Answer 6

You can develop the most secure site on the planet and have really poor user experience. Users will assume that your site is insecure.

You can build the least secure site on the planet and have amazing user experience. Users will assume that your site is secure. At least until it appears on evening news.