Date: Sun, 17 Feb 2013 20:46:32 +0100
From: Patrick Mylund Nielsen <patrick@...rickmylund.com>
To: Jeffrey Goldberg <jeffrey@...dmark.org>
Cc: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Asymmetry [Was: Any "large verifiers" on the panel?]

>From a practical perspective, I'm highly skeptical that most users would
actually store such a secret differently/out of reach of an attacker. If
you've compromised the server, you almost certainly have access to any
secrets. Online attacks are problematic, but offline attacks are far worse.
If a scheme can't offer a decent amount of protection for the digests of
low-entropy passwords when they (and any secrets) are compromised, then it
is not very good, IMHO. That's not to say that having the ability to
leverage a HSM (if available) to make it even harder wouldn't be great
feature, of course. I just think that will be rare.

One notable exception to this that I can think of is if you e.g. have some
(possibly global) secret which is loaded from e.g. disk instead of the
database--then attackers who are only able to leverage a SQL injection
vulnerability would not be able to do much with the salt+digests from the
database.


On Sun, Feb 17, 2013 at 8:26 PM, Jeffrey Goldberg <jeffrey@...dmark.org>wrote:

> 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
>
>
>
>
>
>
>
>
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists