phc-discussions - Re: [PHC] 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: <CAEw2jfz3CG9VLpV--cyzTAvF854qG-CZ9PX02LeB5-1X2JV=tQ@mail.gmail.com>
Date: Mon, 18 Feb 2013 09:54:01 +0100
From: Patrick Mylund Nielsen <patrick@...rickmylund.com>
To: Daniel Franke <dfoxfranke@...il.com>
Cc: Jeremi Gosney <epixoip@...dshell.nl>, 
	"discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Any "large verifiers" on the panel?

Except this is not what happens today. The vast majority of authentication
systems establish sessions that are kept alive for long periods of time.
and so simply gathering a large amount of credentials in a short period of
time by sniffing the wire (assuming that you can actually get to this
point, which is significantly harder than simply dumping a table from the
database) is actually quite a difficult and lengthy task. Assuming you
don't get detected during this time, it would still take a very long time
for every user to re-authenticate.

What does happen, and what absolutely hurts the most, is when somebody gets
a hold of your entire database of (weak) digests and cracks them on their
own or dumps them in a pastebin, e.g. without the usernames. The PHC
schemes, IMHO, really need to be resistant to this. We _already have_
effective ways to resist online attacks--exponential backoff, bans, even
captchas...

To give an example: Blizzard Entertainment got a huge level of flak from
the tech, and even the crypto, communities for using SRP when their
verifiers were compromised, as people realized that SRP protects against
MITM attacks, not offline attacks:
http://arstechnica.com/security/2012/08/hacked-blizzard-passwords-not-hard-to-crack/

IMHO, it is a more useful exercise to think about leveraging clients, e.g.
for key derivation, than more secrets on the server side. The servers will
be compromised.

On Mon, Feb 18, 2013 at 1:25 AM, Daniel Franke <dfoxfranke@...il.com> wrote:

> Jeremi Gosney <epixoip@...dshell.nl> writes:
>
> > You have to assume that if the passwords are compromised, the
> > encryption key is as well.
>
> I'm with all those who say that we shouldn't be granting this
> assumption. An adversary who has completely compromised a web server
> doesn't have to bother cracking password hashes at all. He can just
> capture unhashed passwords as they arrive over the wire. If we aren't
> completely wasting our time having this competition, then we should
> absolutely be thinking about what constitutes a realistic model of
> common partial-compromise scenarios, and what features we can add to a
> password-hashing scheme in order to make it more secure in that model.
>
> P.S.: A couple people in this thread have been referencing a message
> from Peter Gutmann which doesn't seem to have made it to my inbox. Was
> that message sent to this list?
>

Content of type "text/html" skipped