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: <CAEw2jfyZ9=ATMhNw2vim75ZMKgs0L2koSaNbFrq5qPymGmghxA@mail.gmail.com>
Date: Mon, 18 Feb 2013 09:38:09 +0100
From: Patrick Mylund Nielsen <patrick@...rickmylund.com>
To: Matthew Green <matthewdgreen@...il.com>
Cc: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Asymmetry [Was: Any "large verifiers" on the panel?]

> You can't do this stuff today because HSMs aren't up to it, and because
most browsers don't let you do the kind of crypto you want to do at login
time. I think 5-10 years from now things will have changed a bit.

I certainly hope so. I particularly wonder what the situation will be like
with popular virtualization providers, and whether the HSM interfaces will
be standard enough that you can leverage many different ones without
trouble/user configuration.

"Please keep in mind that SQL injection can be leveraged to do a lot more
than just dump the database. It can also be used to read artibrary files,
and in some cases, obtain a shell running in the context of the database or
webapp."

In the cases where an attacker is able to read files or system memory
(provided the database servers are also application servers) then indeed,
such a secret would be fairly useless. If they gain control of a database
server, you can probably assume that application servers too will be
compromised within long.

This was the best case of a (very) common attack that usually only
compromises the contents of the database, and thus where such a secret
would be highly practical today, that I could think of.

On Mon, Feb 18, 2013 at 3:00 AM, Matthew Green <matthewdgreen@...il.com>wrote:

> 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.
>
>
> I think that HSMs are going to become increasingly common in this area. I
> also think we're going to see an increasing number of clever tricks to keep
> secrets out of the hands of a hacked server. We already have things SRP
> (not that I'm recommending it). I expect to also see simple end-to-end
> encryption of passwords, from browser to an HSM or equivalent system. But
> databases will continue to be the weak link.
>
> You can't do this stuff today because HSMs aren't up to it, and because
> most browsers don't let you do the kind of crypto you want to do at login
> time. I think 5-10 years from now things will have changed a bit.
>
> But I've been wrong before.
>
> Matt
>

Content of type "text/html" skipped