phc-discussions - Re: [PHC] Asymmetry [Was: Any "large verifiers" on the panel?]

lists.openwall.net		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]

Message-Id: <98657C44-5C16-42A8-9892-DFF8623491C9@goldmark.org>
Date: Sun, 17 Feb 2013 13:26:27 -0600
From: Jeffrey Goldberg <jeffrey@...dmark.org>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Asymmetry [Was: Any "large verifiers" on the panel?]

On 2013-02-17, at 2:30 AM, Jeremi Gosney <epixoip@...dshell.nl> wrote:

> On 2/16/2013 10:45 PM, Jeffrey Goldberg wrote:

>> shouldn't we expect that the same compromises that would get the
>> password hashes would also getat that secret?
> 
> Correct. You have to assume that if the passwords are compromised, the
> encryption key is as well.

From other responses (cf Marsh Ray) it seems that this really is the
assumption that is in (some) dispute. So here's my thinking on this
now (as opposed to a few hours ago when I posted my response to
Peter Gutmann).

We all know that we are talking about situations in which a server
gets compromised. And in principle, once a system is compromised
it's hard to trust anything about it. But it also seems that a case
can be made for saying that a small secret, which is only every
used for verification, can be protected better than a very large
database that may legitimate uses beyond authentication.

Some notation to make the following easier to talk about (at least
for me).  S is the server. k_S is this secret that S has access to
allowing S to verify passwords quickly instead of slowly. D_S is
the password-hash database.  Let R_k and R_D be the risks of exposure
of k_S and D_S. I'm not sure what units R should be measured in,
but we can leave that aside.

There are arguments that in practice R_k is substantially smaller
than R_D.  k_S is a small secret D_S is a big secret, so k_S can
be kept on an HSM.  D_S will be backed-up in less secure places
than k_S; There will be people and systems in the organization that
need access to D_S who will not need access to k_S.

We already assume that a compromise of S is not complete. After all
if S is completely compromised during a period of time, then client
credentials could simply be sniffed prior to verification.

Furthermore, there is uncertainty about R_D and R_k, and those risks
will change over time. Even if we argue today that R_k is isn't
substantially smaller than R_D, we don't know that that will remain
true tomorrow. New techniques (and attacks) for managing k_S will
emerge.

On the other hand, it is hard to get nice security proofs under
conditions of a compromised server.

Cheers,

-j