15

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.

user2698818
  • 151
  • 3
  • 7
    Personally I wouldn't worry too much about the communication: write a technical description of what you do, burried somwhere deep in the FAQ where the technical-minded will find it. Anyone else doesn't really care anyway. More importantly: make sure that you do the right thing (that's hard if you're new, but at least you're trying!). Don't build your own hashing, use something like [bcrypt](https://en.wikipedia.org/wiki/Bcrypt). – Joachim Sauer Aug 20 '13 at 07:25
  • 4
    Well, the right thing is to federate the login and not bother users with yet another username and password. – Jan Hudec Aug 20 '13 at 07:42
  • 1
    OpenID is good, but username/passwork is ok too. I don't think your problem is to persuade users that your site is secure. Since you are inexperienced, it's like promising something you don't have. Just apply common standards - you won't stop professional hackers come, but no one can blame you either. – Hoàng Long Aug 20 '13 at 08:10
  • 1
    SHA-512 with random per-user salt is ok, but with no additional effort, you can use `bcrypt` which [seems more secure](http://dustwell.com/how-to-handle-passwords-bcrypt.html). More importantly, with security, you should always check with an [expert](http://security.stackexchange.com) (I am not one). – coredump Aug 20 '13 at 08:41
  • 3
    @coredump Indeed. Using SHA-512 for password hashing is just not good. It's not "ok". – Thomas Aug 20 '13 at 12:55
  • I think you might get better answers on [ux.stackexchange.com](http://ux.stackexchange.com/) – jfrej Aug 20 '13 at 13:31
  • For stack exchange users have a bullet on the login/account creation page that says passwords are hashed with pbkdf2/bcrypt/scrypt. For the other 99.9% of the internet buy a "certified secure" logo from a snake oil vendor like Verisign or McAfee. – Dan Is Fiddling By Firelight Aug 20 '13 at 15:20
  • 3
    I would probably be worth asking any follow up questions on [security.se] to make sure you get the very best, up to date advice . (That doesn't mean you're getting bad advice here, just that we're not necessarily security professionals). – ChrisF Aug 21 '13 at 07:35
  • The only secure password is the one you don't handle yourself. Which is the benefit of OpenID, you don't store the password, you allow somebody else to take that risk. Make sure you implement the hashing the correct way. You are using the word encryption in the same context of hashing. Passwords should never be encrypted, encryption can be decrypted, properly implemented hashing cannot be reversed to determine the source string. – Ramhound Aug 21 '13 at 11:41
  • Seems to me that if you write something along the line of "my passwords are ultra-secure" you might as well put up a sign saying "hackers come try your skills here pls"... – user643192 Aug 26 '13 at 23:39

6 Answers6

22

  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.

Community
  • 1
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • Thanks for the input you guys. The problem is I am a student designing a service for my uni. I don't want users to think that their passwords are not secure because some kid in school designed it. I have looked at a bunch of different methods including bcrypt and I just haven't decided which one to use. I figure it will be secure enough now and if lots of people start using it I can add to it if needed. I'm just working on getting it out there for now. Thanks again. – user2698818 Aug 20 '13 at 07:35
  • 3
    @user2698818 What you should do is design the security, then post a question describing it in detail and asking 'is this secure (enough)'. Good security can be completely public. – Jan Doggen Aug 20 '13 at 07:40
  • @user2698818: ok. Edited my answer. – Arseni Mourzenko Aug 20 '13 at 07:43
  • 6
    @JanDoggen: well, what he *should* be doing is use an *existing* security system that *someone else* designed and asked "is it secure enough". Preferably one where that question has stood for quite some while and has had the attention of several experts in the fields ;-) – Joachim Sauer Aug 20 '13 at 08:20
12

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.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • 1
    Please tell me what sites you have made so I can avoid them if you treat permissions as not security-critical. – orlp Aug 20 '13 at 09:08
  • @nightcracker: Permissions are definitely security critical _for the site itself_. But if somebody steals them, they won't help them that much. At least they won't help them break any other site (knowing user lists still is _some_ help). – Jan Hudec Aug 20 '13 at 09:35
  • @nightcracker: Knowing which users have big permissions helps the attacker against your site, but if they stole that info from your database, they've already broken in and don't need them anymore. And unlike passwords they won't help the attacker break any other site. – Jan Hudec Aug 20 '13 at 09:37
  • 1
    What if the requirement is to store passwords. Also the question specifically asks about storing them. – Piotr Kula Aug 20 '13 at 10:24
  • 3
    @ppumkin: There are many questions of the kind "how do I use X to do Y" where the best answer is "you use Z". If you don't agree, simply provide better answer ;-). – Jan Hudec Aug 20 '13 at 11:00
  • 3
    @ppumkin To use an analogy: "I'm trying to break a rock with my fist, what gloves should I use?" Check if they're aware of chisels before offering 19th German Cavalry Gauntlets. – deworde Aug 20 '13 at 12:47
  • Hehehe :) Yes that makes sense. If we all strived to eradicate passwords that would make life easier. – Piotr Kula Aug 20 '13 at 12:53
  • 1
    I would avoid being too quick to suggest OpenID. Yes, it's great, but it generally works best if you support multiple OpenID/OAuth providers. There are plenty of tech forums, blogs, Q&As etc where you have to log in via Facebook's OID provider and can't use any other. I'm on a work network that blocks Facebook domains wholesale, and so I cannot work with those sites. If you're going to support OID, and are only going to use one for now, pick a provider that is popular among your target audience, *and* unlikely to be blocked by a sysadmin. Google and Windows Live are good choices. – KeithS Aug 20 '13 at 21:23
  • 1
    @KeithS: There is a big difference between OpenID and OAuth. OpenID associates the user with URL they can prove is under their control and restricting providers there is stupid and there are no good choices except _any_. OAuth than is a method for getting access to other services on behalf of the user and as such it is specific to the service. Service that uses you facebook data requires you login with facebook OpenID and OAuth, because it needs to access it, but than you can't use it if you don't have access to facebook anyway. – Jan Hudec Aug 21 '13 at 06:12
  • @KeithS: I have never mentioned OAuth so far. That is because that is not relevant to authentication. It is only relevant to authorization and you usually don't want to use permissions for another site to govern access to yours. So you only need it when you need access to the user's data at the authentication+authorization provider and than you are obviously tied to it. – Jan Hudec Aug 21 '13 at 06:16
2

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.

stakx
  • 2,138
  • 18
  • 29
  • No, "This is secure" is not a "personal" or subjective statement, it is not like "it is pretty", to *me*. It is actually a semantically **empty** statement, without specifying "in relation to what" or "secure from what attacks" or "at what level in which context". If your entire statement consists of "this is secure", it is out of date before you finish typing it, and it is highly probable that you are not aware of it. I do agree though on the last part, it is all about details. – AviD Aug 21 '13 at 10:59
  • @AviD: Perhaps you read too much into my specific choice of words. Yes, saying that something "is secure" without giving any more details is meaningless. But I rest convinced that it is *also* a personal judgment, because not everyone has exactly the same sense of and demands for "security": What A finds secure enough might feel insecure to B. So saying that something "is secure" suggests that the person who makes the statement "finds it secure". And that is not an argument with the same weight as giving someone the relevant facts, and letting them draw their own conclusion. – stakx Aug 21 '13 at 11:16
  • Right, "in relation to what" I meant for what requirements, security profile, risks, etc. Still not a personal judgement, but perhaps what you meant by "personal" is what I mean by "context". "Secure" *is* a hard science metric, not a soft wishy-washy "feeling". But yeah, like you say, don't tell me it's "secure", tell me what you did to make it so. – AviD Aug 21 '13 at 11:20
  • @AviD: OK. I won't belabor the argument any further, except for saying that security *is* a wishy-washy feeling, too. It's of course more than that, but when the question is about "assuring" users (see question title), then the wishy-washy feeling is what counts in the end. – stakx Aug 21 '13 at 21:15
1

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!!")

AviD
  • 490
  • 4
  • 12
0

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
0

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.

CodeART
  • 3,992
  • 1
  • 20
  • 23