Date: Sun, 14 Sep 2014 16:15:56 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] About shortcuts and escrow

On Sun, Sep 14, 2014 at 05:12:43AM -0500, Steve Thomas wrote:
> I'm confused I thought escrow and fast path were different.

I might have been unclear, so I will try again.

>From a _functional_ point of view, fast path and escrow are different.
Fast path is about obtaining the hash output from the password in a
short time. Escrow is about recovering the password from the hash
output. If you were to implement both as functions, the two functions
would not take the same parameters, so they are not, from that point of
view, the same thing.


>From a _security_ point of view, the difference becomes blurred. The
core assumption of password hashing is that dictionary attacks work: if
given f(password) for a hash-like function f() which is fast to compute,
then attackers will be able to try lots of potential passwords and, most
of the time, hit the right one at some point. If a password hashing
function offers a shortcut (that I call "fast path" in the case of
Makwa), then the power to use that shortcut IS the power to run a fast
dictionary attack, which, from a security point of view, equates to
password recovery.

Thus, when a password hashing function offers a shortcut, then the
values needed to activate that shortcut MUST be handled like a very
sensitive private key, since, in the hands of an attacker, they are
almost as good as an escrow recovery key. In that sense, i.e. from the
point of view of the attacker, shortcut and escrow are very similar.


Up to that point, nothing here is specific to Makwa. However, since
Makwa offers a shortcut, I told myself that I could go to the end of
that logic: if there is a shortcut, and, in the hands of the attacker,
that shortcut would be (almost) as devastating as an escrow recovery
key, then I might just as well formalize the mechanism as an actual
escrow, call it as such, and provide it as an optional feature for the
few scenarios where it is actually helpful to the defender.


> That's the problem if you tell people it's secure and that you can
> have a high cost to attackers while having a low cost to you. People
> will keep p and q to do fast path. Basically you can't say "you can
> keep p and q" to users and tell critics "well just clear p and q and
> your issues go away [along with some features]".

That's the reason I am calling it "escrow". This is a nasty word. In the
mind of many readers, it conjures up notions of evilness, like
governments spying on citizens (depending on the reader, this may
encompass all past, present and future governments; for others, only
"bad" governments are evil). Faced with the E-word, a substantial
proportion of security researchers have an instinctive repulsion reflex,
like an imam stumbling upon a pigsty.

Yet I am still using that bad word, despite its poor potential for
public relations, because I feel that my users (people who would
consider using Makwa, e.g. for their servers) must be presented with the
raw, if bleak, truth in that matter: a shortcut has significant
consequences for security, and the "shortcut secret" must be handled
with all the care that would be needed for an escrow private key. I am
calling it a private key and I associate it with the escrow feature
precisely to achieve that psychological effect.

You cannot reproach me both my describing the "escrow" feature, and not
doing it. In fact you are yourself the living example of what I mean: as
you told in a previous email: "I guess the escrow should have tipped me
off". That's intentional. The "escrow" word is there to tip you off that
there is some private key to handle as a private key.


A point which I might not have made clear enough, though, is that
post-hashing is NOT a way to separate "shortcut" from "escrow". From a
functional point of view (see the beginning of this email), the
post-hashing indeed prevents any escrow feature from operating smoothly
(if you want to recover a password, you have to run a dictionary
attack). From a security point of view, post-hashing is only a minor
bump on the attacker's road: since the shortcut allows for an efficient
dictionary attack, it would be wrong to believe that enforcing
post-hashing would really enhance security.

In fact, by defining Makwa to always use post-hashing (as you suggest),
not only would I artificially block some optional functionalities, but I
would also send to my users the wrong message about the fundamental
"private key" status of the shortcut. If I did that, then, in that case,
you would be justified in calling me irresponsible.




Now let's see the practical side of things. Imagine the very common
situation of a Web server that authenticates incoming clients. The
server uses SSL, and clients are Web browser who just send the password
"as is" in an HTTP request. It is obvious that the SSL private key is a
very valuable secret, since learning it would allow an attacker to
decrypt past and future connections and thus obtain passwords (if the
SSL server enforces DHE cipher suites, the attacker may "only"
impersonate the server, which in many practical situations is almost as
good: indeed, a low-power attacker is using a fake WiFi access point in
a public place to lure users into sending him their precious bytes; for
such an attacker, an active MitM is not harder than passive
eavesdropping).

A typical SSL-powered Web server will thus put the private key in some
place where the SSL library can access it, but still kept "private" as
much as possible. In a Microsoft implementation (with IIS), the private
key would be entrusted to the cryptographic layers of the OS, i.e.
CryptoAPI (or CNG) -- ultimately, stored somewhere on the hard disk
(still in Windows, the relevant keyword is "DPAPI"), but not in the SQL
database and thus not directly impacted by SQL injection attacks.

All other things being equal, storing the private key for a password
hashing shortcut in the same emplacement as the SSL private key would be
a good idea. If an attacker learns these keys, the power he gets is not
identical for both keys (with the SSL key he can run a fake server and
learn passwords as they are used; with the shortcut key he can attack
efficiently all stored passwords) but is still quite similar (in both
cases, the attacker endangers passwords quite directly -- actually a bit
more so with the SSL private key, since he can leverage it right away
without needing access to the hashed passwords).

So in the case where "people keep p and q to do fast path", in a
properly integrated evironment, then chances are that it will turn out
all fine: the p and q values will be kept in a store whose exposure
would already have similar or even worse consequences.


	--Thomas Pornin

PS: "I got scared by the long message". Sorry, I tend to be verbose when
I write (if you read the Makwa specification then you already know
that). It is because of the words; I like them.

Powered by blists - more mailing lists