[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADRhWrDvM5MrTY551-nawKD68mzSaRXDUaBWZ6PVKwNV2Sy8Wg@mail.gmail.com>
Date: Sun, 4 Sep 2016 13:15:18 -0500
From: "Denny O'Breham" <obreham@...il.com>
To: passwords@...ts.openwall.com
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.
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.
« 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.
On Sun, Sep 4, 2016 at 12:15 PM, Yoha <yoha@...on.org> wrote:
> 1. In passing, I also like the idea of proposing good passwords for the
> users. The website could propose a few passwords generated client-side
> (see [1] and [2] for existing implementations), and the user could
> choose among them (that would sacrifice a few bits of entropy, but
> that's okay)
>
> The issue with that is that users are often not ready to memorize new
> passwords. However, even with a fallback, showing good options to the
> users might slowly induce good behaviors by making them use strong
> passwords.
>
> 2. I understand your scheme better. If I am correct, you are storing a
> strong key client side; this is where I compare it to a password
> manager, since it implements similar features:
>
> * require information stored on the client's computer
>
> * require a password typed in by the user
>
> * from this, derive a strong key to send to the server
>
> Of course, streamlining password managers so that the UX does not
> detract the users is important. Making it so that the website
> transparently interact with the password manager would be a great thing.
> The issue is then that of defining new standards [3]
>
> [1] http://passwordcreator.org/
>
> [2] https://xkpasswd.net/s/
>
> [3] https://xkcd.com/927/
>
>
> Le 04/09/2016 à 19:00, Denny O'Breham a écrit :
> > Yoha - I read your 2016/08/25/1 email and we are on the same page.
> >
> > Let me state the problems I'm trying to solve through personal
> > experiences:
> >
> > 1- As a user, I hate choosing passwords. I try to deal with all the
> > rules each site gives me and I end up with passwords I can't remember.
> > I find the process very frustrating. Frustration is not good for UX.
> >
> > Lately, a hobby forum I'm registered to was hacked into (the admin is
> > actually a big company having several forums). The result was a
> > mandatory password change, with a new set of rules ridiculously severe
> > and a 90 day expiration date. Just to show you how much frustration
> > there was, some users were logged in for so long (w/ cookie) that
> > their email weren't even valid anymore and couldn't be reach by the
> > admin. I don't remember the password I have (I would have to sign in
> > with 'Forgot password?') and the password I thought was well crafted
> > could probably be guessed by an expert in the time I take to blink.
> >
> > The answer to this, as someone mentioned, is a password manager. Good
> > idea, although I have difficulties using programs I don't know how
> > they work and how they store my data (even worst when I don't know
> > where they store it). Which one do I trust? Will the program still
> > be available in a few years? Will I be able to change browsers and
> > recuperate/transfer my passwords? Personally, I sometimes use
> > different browsers, having them synchronize is worst than
> > synchronizing machines.
> >
> > 2- As a website owner, I would want to protect my database. But one
> > major deterrent for an attacker is knowing that every single user has
> > used a hard-to-guess, unique, password, which is out of my control.
> > By enforcing a password policy, I frustrate my users and it doesn't
> > change much to the attacker; At best, it will create a new set of
> > rules for future attackers (which they will probably take as a
> challenge).
> >
> > Again, forcing everyone to use a password manager could solve the
> > problem, but it's out of the control of the site admin.
> >
> > So I'm not trying to solve problems such as eavesdropping or
> > man-in-the-middle attacks which are still possible at this time. Even
> > if I wanted, I don't have the cryptographic knowledge for this.
> >
> > It's really about database security and better UX.
> >
> > My solution is the following:
> >
> > When the user creates an account, I choose the password for him, let's
> > say it is "64hex" (It is actually a 64-character hexadecimal number).
> > I do the usual one-way hash and store it in the server's database.
> >
> > Then I create another random password - let's say "64hex2" - and save
> > it in clear in the server's database next to the hashed "64hex" and
> > the username.
> >
> > Then I ask a password from the user. There could be some simple
> > rules, such as minimum length, but let say there is none and that the
> > user choose the password "p" ( "123456" is too difficult to remember
> > :) ) and that this is the password he used on all his favorite websites.
> >
> > Then I combined the user's password with "64hex2" which gives
> > "p64hex2", i.e. a very strong password no matter what. I use this
> > password to encrypt "64hex" and send the result (which I call the
> > 'code') to the user.
> >
> > "64hex" is now securely kept on the user's storage space. To open it,
> > both the user's password and the server's password are needed. From
> > the point of view of the website owner, I responsibly encrypted the
> > code, not relying on a maybe weak user password, i.e. no liabilities.
> >
> > I also create a personal URI, i.e. one that goes to the login page,
> > with the code into the query (If you used the program in github,
> > you'll notice that the query is not stored in your browser history,
> > thanks to a redirect). This way, the user only needs to enter his
> > username & password into the login page, as usual. I also plan on
> > sending a html file with the code, that has an automatic (javascript)
> > redirect to the personal URI. One click on the file and the login
> > page opens in your favorite browser. If the file is in the cloud, you
> > get access from any of your machine easily.
> >
> > Say an attacker has access to the code (or even the personal URI).
> > Then we are at a security level identical to what we are used to right
> > now, i.e. the attacker has to go on the website (to have access to
> > "64hex2") and guess "p" and he's in. Without access to the server, he
> > can't guess "p64hex2". But for this to happen, he needs to have
> > access to the user's storage space (machine or cloud) or intercept the
> > communication (which is still a possibility with traditional login).
> >
> > Say an attacker steals the database. "64hex2" is useless without the
> > user's code and not only hashed "64hex"s are unguessable, but they are
> > useless to the attacker as these passwords are unique to this site only.
> >
> > Say, as a site admin, I'm afraid someone has breached into my database
> > (not even sure it is still a problem now, password-wise) and I want to
> > reset all passwords. So I do and change "64hex" to "64hexA" and
> > "64hex2" to "64hex2A", create a dummy user password "p2" and send the
> > new code to the user. If I don't give "p2" to the user, he won't even
> > be able to log in. But he will be able to reset the password again -
> > leading to "64hexB" and "64hex2B" and a new code - with his password
> > "p". Therefore the user can still keep his password while my database
> > is totally renewed in a matter of minutes, if not seconds.
> >
> > Same thing if the user suspects that his code was stolen. He asks for
> > a new code while keeping his password "p", he replaces his old html
> > file (with the personal URI) with the new one and he can get back to
> > his old habits.
> >
> > What do you think?
>
>
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.
