[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <415ac4c0-b567-2784-c410-ca9c6e2a9753@sinon.org>
Date: Sun, 4 Sep 2016 19:15:32 +0200
From: Yoha <yoha@...on.org>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process
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?
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.
