[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 5 Sep 2016 12:46:00 -0500
From: "Denny O'Breham" <obreham@...il.com>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process
Thank you Yoha for keeping up with the discussion, it is appreciated. By
the way, I understand your remark about my comment suggesting that picking
5 words from a 9806-word dictionary could become insecure one day (I can't
imagine the day my 64-hex password could be consider insecure as well). I
was just trying to make a point.
Thank you Patrick Proniewski for your input, I discovered the FIDO Alliance
and that was appreciated. J'ai visité votre site aussi, très intéressant.
As for Per Thorsheim, although we did not exchange much, I saw some of the
YouTube videos you posted from Passwordcon 2013 in Las Vegas, that was
great info and it was also appreciated.
Thank you all.
On Mon, Sep 5, 2016 at 11:43 AM, Yoha <yoha@...on.org> wrote:
>
>
> «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", but it is plenty good for
> login to "store.momandpop.com", "datingsite.com" or even "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.
