Password strenght

[steph643]

As discussed in #24, it seems you can claim additional security over traditional passwords only if the unique password is very strong. If the unique password is weak, my understanding is that your solution is weaker than traditional passwords (or maybe I'm wrong ?).

A solution: add strong conditions to the unique password. That would hit usability and adoption.

An other solution: add reasonable conditions to the unique password and ask user for one or several pieces of personal data ? (pet's name, etc.)

[homakov]

my understanding is that your solution is weaker than traditional passwords (or maybe I'm wrong ?).

First of all traditional passwords are 1) reused 2) sent in plaintext. You can't make worse than that, it's already rock bottom and md5(password+domain) is 10x improvement over of what we have now security-wise.

Strength of the scheme is combination of how simple is password + how hard is derivation. We can't control the former so we set the latter as high as we could.

We can't control the former with offered option 1 - hits usability, exactly. Same with option 2 - question based parts are easier to forget and easier to enumerate.

Something unobtrusive like dropbox's zxcvbn could be helpful, but technically it would just shift top 1M to other passwords, not get rid of it.

[steph643]

I'm not familiar with KDF, so I cannot follow you far on this.

But here are some quick thoughts from a marketing communication standpoint:

• Average users don't think they need additional security. The problem they have with traditional passwords is usability.
• So your main selling point to them should be "easier to use", not "more secured".
• People will have difficulties believing your product is both "more secured" and "easier to use". It's like saying "my product is cheaper and of higher quality".
• I think you need to address two audiences:
  1. To the general public [EDIT: and admins/webmasters/developers], you should say that your product is like traditional passwords, only easier. In small font, you can add that "the product is as safe as traditional passwords, as acknowledged by security experts".
  2. To the security community, you only need to prove that your product, in real situation, is no weaker than traditional passwords. Such proof cannot be based on your own expertise. In a couch shop, do you trust the salesman as a couch expert? As much as possible, your proof should be based on academic sources and/or known independent experts.

P.S.: you talked about plaintext, but don't ssh solves that?

[andrewda]

@steph643 Good points!

Average users don't think they need additional security. The problem they have with traditional passwords is usability.

A million 👍's right there. I know plenty of people who are all too eager to use the same password on every website they visit, and don't blink an eye when a website emails them their password if they've forgotten it.

P.S.: you talked about plaintext, but don't ssh solves that?

I'm assuming you mean SSL/TLS 😄 And yea, in theory that would solve part of the problem, but small websites and businesses don't always have enough to afford one, and many don't have the technical experience required to use LetsEncrypt. A login system using only SecureLogin can be written in about 30 lines (see the Node.js demo).

[steph643]

Yes, I meant ssl, not ssh. I think many people think it's becoming a de facto standard and would advise any web site to adopt it. There is no need to fight against this trend, so you shouldn't use the "plaintext" argument :-)

[homakov]

I think you need to address two audiences:

I think we don't need to communicate to average users at this stage. It's harder. Unlike pw managers, we need admins and developers to integrate it, and only then to give users some info why this option is better than others (ie easier as you said). Site owners first, user experience second. But in general you are right, admins want usability, security and conversion, users want just usability.

P.S.: you talked about plaintext, but don't ssh solves that?

It is sent encrypted on transport level but the server can see it in plaintext. Actually reuse&plaintext are in essence about one problem: that one server may use given credential against another service and there's absolutely no practice to stop that beyond advising users to "use a unique and strong password".

There must be a middleware application between user and services that takes one password on input and produce per-service credentials on output, that cannot be reused against others. That's what we try to do.

[steph643]

admins want usability, security and conversion, users want just usability.

I would advise you consider admins/webmasters/developers just like end users:

• Most of them do not want more security. They gladly accept weak security, as long as everyone else has the same.
• Most of them are not able (nor willing) to understand the strength/weakness of your security protocol.

So, really, from a communication standpoint, they are like end users (I've edited my earlier post to reflect that). They need to hear: "this system is as safe as traditional passwords, as proven by those independent studies. But is'ts really easier to use, so everyone will adopt it soon."