lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Sep 2014 15:57:48 -0700
From: Andy Lutomirski <>
To: discussions <>
Subject: Re: [PHC] Re: Re: Re: Re: Second factor (was A review per day - Schvrch)

On Wed, Sep 3, 2014 at 3:45 PM, Alex Elsayed <> wrote:
> Andy Lutomirski wrote:
>> On Wed, Sep 3, 2014 at 3:29 PM, Alex Elsayed
>> <> wrote:
>>> Besides, why store _anything_ on the user's computer? The user types in
>>> N, and then P, and neither has any related data stored anywhere on the
>>> computer; the less you process P the less time it spends resident in
>>> memory as well. Treat it like a hot potato and hand it straight to the
>>> token.
>> Because I want to trust my token as little as possible.
> My point is it doesn't actually trust your token any less.
> Handing your token F(P) instead of P doesn't matter, because F(P) is still
> sufficient for a malicious token to never ask again if it stores it - and a
> malicious token disclosing P rather than F(P) only matters if your password
> hygiene is really terrible (reuse, etc).
> Besides, the token _does_ rely on you relaying the second exchange for it -
> if it tries to do an exchange when you didn't _initiate_ an exchange, that's
> a 'KILL IT WITH FIRE' indicator; that leaves only that it surreptitiously
> stores what you give it and waits for someone to steal it from you.

Let me try to say it more precisely.  I want a fourth security
requirement: even if the token is actively malicious (e.g. records
things it shouldn't, sends maliciously incorrect output, and leaks
things to <insert government agency here>), then the protocol should
still be as secure as either password-authenticated or
encrypted-key-authenticated protocols, depending on whether the user
stores a key file on his/her hard drive.

I think that my protocol achieves this, or at least tries to.  Yours
seems to be completely insecure in this threat model.

Yours might be fixable for this purpose by having the user do a second
PAKE exchange with the server, protected by the output of the first
one.  This requires more round trips than my approach.


Powered by blists - more mailing lists