[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Sep 2016 10:07:47 +0200
From: Yoha <yoha@...on.org>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process
Hello,
I am also somewhat confused by the scheme. I think a diagram might be
clearer to expose what information is stored where, and what information
is sent to whom.
However, I think I can still see a disadvantage: since this requires the
user to store a secret on their computer, it limits its flexibility. For
instance, if an user wants to connect from a different device, they have
to transfer these secrets.
In the end, I feel that this is essentially an implementation of a
password manager [1]. On the matter, the consensus seems to be that they
are definitely a step in the right direction, and that users should be
encouraged in using them. Regarding the issue with portability, the use
of online password manager would probably still be preferable other that
of an unique password, and might gently push non-technical users towards
more secure usage patterns.
Ignore "e" aggressive comments; that is mostly noise. If you are
interested in understanding what password entropy really is, I submitted
a brief summary a few days ago [2]. If someone knows of a more detailed
/ intuitive document presenting the concept, I am also interested in
knowing about it.
[1] https://en.wikipedia.org/wiki/Password_manager
[2] http://www.openwall.com/lists/passwords/2016/08/25/1 (you may skip
the first part, until the first occurrence of "---")
Le 04/09/2016 à 08:32, Patrick Proniewski a écrit :
> Hi,
>
> On 03 sept. 2016, at 23:01, Denny O'Breham wrote:
>
>> I'm no expert by any mean on web security, but I keep myself informed. In order to protect the user's passwords from such methods described by Rick Redman, I created this login process. I never seen anything like it and it is really simple, two indications that it is not good. Yet, I cannot find any flaws, maybe because of a lack of knowledge from my part.
>>
>> It does require for the user to use a unique URI to login, but it seems to be a very small constraint compared to the cumbersome password complexity and rotation required by most websites today.
>
> Looks interesting, but there is something I don't understand:
>
> You store server-side the 256-bit random password, hashed.
> The user has 2 secrets: her decryption key, and the code (encrypted version of the 256-bit random password)
> And you add that this same code can be decrypted by a second key, 256-bit and random, that is kept server-side.
>
> What is that second decryption key for?
>
> The login process should be, according to your description:
>
> user provides her decryption key for the code, and the code -> the server uses the provided key to decrypt the provided code -> the server hashes the result and compare the hash with the store hashed code.
>
> In practical terms, it gives the same security as a really cheap 2FA: user has something she knows (decryption key) and something she owns (impossible to remember & encrypted 256-bit random key), but this "second factor" is static. As soon as someone steals her bookmarks or browser history (cloud sync hack? nasty browser extension? XSS?...) you are back to the situation where the user has only a poor password.
>
> This setup is also subject to MIM attack, or any other attack where https traffic is intercepted and decrypted, and to attack client side. Just because the "second factor" is static.
>
> I really think your idea adds a security layer on top of regular web login, but it probably comes few years too late: one should probably focus on real MFA (ie. with non-static second factor). The FIDO alliance seems to move in an interesting direction, even though it's "web only".
>
>
> pat
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.
