[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Sep 2016 18:43:07 +0200
From: Yoha <yoha@...on.org>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process
> «This approach partially breaks the abstraction users have gotten used
> to. In consequence, it would probably reduce adoption significantly.»
>
> The question is: Is it more realistic to impose this approach to
> users, or force them to use a password like «calve ice greg linking
> stunt» with a password policy?
That's why there should be a fallback in any case where the user can use
(almost) whatever they want. Those would just be suggestions.
>
> The reality is that if you can identify a request by a token, a simple
> password like "rockyou" becomes acceptable as long as it is not
> recorded all over the web, in every database (hashed or not) with your
> name on it. It might not be good for "cia.gov/classified
> <http://cia.gov/classified>", but it is plenty good for login to
> "store.momandpop.com <http://store.momandpop.com>", "datingsite.com
> <http://datingsite.com>" or even "myemail.com <http://myemail.com>".
>
> Let's even say that somehow a 64-hex password is no longer consider
> secure in the future. I can change my "internal" password policy
> without the user being aware of it (apart from a forced reset with his
> unchanged password). If I don't make the change and my database is
> breached, it doesn't even has an effect on my users' login habits on
> other websites.
>
It's definitely easier to just have a password manager (application or
in website). I was just making an additional suggestion for classical
password creation.
> But let's say picking 5 words from a 9806-word dictionary is no longer
> a secure method.
Just a minor remark, but this is an extremely unlikely scenario (Moore's
law does no apply here, and quantum computing would not change that
much). The only universe where I can see that happening is one where
human civilization expands by several orders of magnitude, making
corporations and institutions grow with them, and strengthening the
asymmetry between an state-level attacker and an individual.
> What do I have to do? Force a password reset on every user. They are
> all pissed off and hate me because they have to learn a new (weirder)
> password, which will be different from their other websites unless
> they change them all (but other websites might not allow the new
> password because they did not update their password policy). If I
> don't do it and my database is breached, then I expose my user's
> passwords. The worst thing is for that scenario to happen, the
> password policy doesn't need to be outdated, just a breach in my
> database and I have to reset all passwords and tell my users to not
> used their previous password anymore, just to be sure. Even if I can
> assume the password are impossible to guess.
>
> After a database breach, the PR and legal dept. will frown at you when
> you'll tell them "There is very little chance the stolen hashed user's
> passwords might be cracked". But they will love you when you'll tell
> them "What user's passwords? We don't have them in our database."
The interactiveness of your protocol does seem to protect users'
passwords in this scenario. You might be interested in public-key
authentication schemes (like in SSH), which would improve the security
when first creating the account. If you want to look into that, you
might want to investigate client-side certificates, that are already
partially implemented in major browser, although current available UIs
are quite clunky.
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
