[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADRhWrDBx7S2qrfovFPs9s3n4+KxT56tboejGZusriH6DfU6jw@mail.gmail.com>
Date: Sun, 4 Sep 2016 15:22:17 -0500
From: "Denny O'Breham" <obreham@...il.com>
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?
Especially if you don't let them choose their own - preferred - password.
One could have a similar password based on a japanese dictionary and it
would be just as good, but you would refuse it because the words aren't in
your word list? We're going back to the «too many standards» problem you
have depicted.
Personally, I don't like these passwords as I have problems remembering
them. I know a person (who hates computers) with a pin number which is
based on a birthday and still have to write it down. You'll never find a
secure way to write a password that everybody accept.
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.
But let's say picking 5 words from a 9806-word dictionary is no longer a
secure method. 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."
On Sun, Sep 4, 2016 at 1:39 PM, Yoha <yoha@...on.org> wrote:
>
> «see [1] and [2] for existing implementations»
>
> As for [1], here's an example. I went there and it gave me «wcicxWqjQ4Px»
> as a writable password. As a user, I could be comfortable with remembering
> that ... as long it is the only one I need to remember. If I need to
> remember 20 passwords like that, forget it. If I need to change them every
> 6 months, that's even worst. If I have the same one for all my websites
> and one stores it in an insecure way (How will I know?), then I need a new
> one and need to change it on every websites; What a pain.
>
> Absolutely, it is only better relatively to the common behavior of having
> a single weak passwords for all websites. The “slowly push”ing them to
> better practices is about getting them to use stronger and more memorable
> passwords (I am thinking of the rightmost column). It might help them use
> different passwords for different websites, even if they resist using a
> password manager.
>
>
> AS for [2], it builds a password based on specific rules. You are
> basically giving the rules directly to the attackers such that they can
> build their dictionaries. I wouldn't trust these passwords to be secure,
> as soon as these tools become popular.
>
> I think a website should only propose a few password of a single
> generation method (preferably, the "xkcd" one). However, this is purely a
> UX matter: the point of password security is that the attackers do know the
> rules along which the passwords are generated; the security relies on a
> large uniform probabilistic distribution.
>
> For instance, the rightmost generator from the first link [1] is based on
> a public dictionary of 9806 English words. Picking 5 words uniformly at
> random to make a password gives you an entropy of 66 bits, which is
> uncrackable by an attacker. NIST recommends a minimum of 32 bits.
>
> [1] https://passwordcreator.org/
> [2] https://nakedsecurity.sophos.com/2016/08/18/nists-new-
> password-rules-what-you-need-to-know/
>
>
> « this is where I compare it to a password manager»
>
> Reading your comments, I kind of see my login process as «forcing» a
> password manager to the users. No need to wait for them to be educated
> about password safe practices or learn a new type of program. It is
> related to my website only as opposed to some 3rd party managing all of the
> user's credentials; So no standard needed. So even if my website is
> compromised, only my user's «unknown» passwords are compromised. The damage
> is a simple reset by each of my user, while keeping their usual password.
> With a 3rd party password manager, if the program is compromised (or maybe
> a policy modification changes my «free» account to one with fees, so I need
> a new password manager), I need to do the painful process of resetting all
> of my credentials around the web. Plus, if someone learns the master
> password, that can be catastrophic for the user with a password manager.
> With my login process, assuming he has the same password for every website
> and it is compromised, you still need the code to access any of the website.
>
> So, if I understand you correctly, this key would go to the localStorage.
> This would indeed make the scheme implementable without needing
> coordination with other actors. However, I see two issues:
>
> * the user cannot use a different computer / user / browser / profile,
> synchronization would actually be possible, but somewhat clunky
> * your security of credentials is very dependent on the security of
> Javascript distribution (web server / CDN / TLS connection) and execution
> (web browser)
>
> My main gripe is actually with the first point. This approach partially
> breaks the abstraction users have gotten used to. In consequence, it would
> probably reduce adoption significantly.
>
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.
