[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2B15E8A6-2FDD-4916-A8B3-9B0AC9F0C6B2@patpro.net>
Date: Sun, 4 Sep 2016 08:32:31 +0200
From: Patrick Proniewski <patpro+password@...pro.net>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process
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.
