Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Sep 2016 20:39:44 +0200
From: Yoha <>
Subject: Re: Authentication process

> «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.


> « 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.