john-users - New in password hashing: ROM-port-hard functions (ZeroNights 2012 slides)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20121123055141.GA5167@openwall.com>
Date: Fri, 23 Nov 2012 09:51:41 +0400
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com, john-users@...ts.openwall.com
Subject: New in password hashing: ROM-port-hard functions (ZeroNights 2012 slides)

Hi,

As those who follow me (@solardiz) or @Openwall on Twitter already know,
I made a lightning talk at ZeroNights conference in Moscow on Nov 19-20:

http://2012.zeronights.org/fasttrack#peslyak

The topic was new developments in password hashing - in a sense, this
talk was continuation to my PHDays and YaC talks earlier this year.
This time, I focused on use of standard server hardware - gigabytes of
RAM and SSDs.

Here are the slides:

http://www.openwall.com/presentations/ZeroNights2012-New-In-Password-Hashing/

Here are the relevant comment threads on reddit:

http://www.reddit.com/r/netsec/duplicates/13mrle/new_developments_in_password_hashing_romporthard/
http://www.reddit.com/r/crypto/comments/13ms4e/new_developments_in_password_hashing_romporthard/

(some comments on r/netsec, but none on r/crypto at this time).

Here is the abstract:

Like it or not, password authentication remains relevant (including when
used as one of several authentication factors), and password hash
database leaks remain a risk.  To mitigate the risk impact,
computationally expensive (bcrypt, PBKDF2) and more recently also
memory-hard (scrypt) password hashing methods have been introduced.
Unfortunately, at relatively low target running time and with the need
to perform multiple authentication attempts concurrently, scrypt's
memory cost ends up being unreasonably low, up to the point where scrypt
may not be better than the much older bcrypt.  In my talk, I propose and
discuss the pros and cons of an alternative approach, where an
arbitrarily large lookup table may be used along with any target running
time and in parallel by multiple concurrent authentication attempts.
With contemporary server hardware, the lookup table may occupy tens of
gigabytes of RAM (using it as a site-specific ROM), which limits
attackers' use of pre-existing hardware (such as botnet nodes), thereby
buying the defender time.  Further development of the approach is in use
of not only RAM, but also SSDs and potentially even a NAS/SAN based on
SSDs.  This achieves goals similar to those of the "blind hashing"
concept, later dubbed "security through obesity", which was proposed
after the LinkedIn password hash leak this summer.

If you have comments, you may post those to the reddit threads or to the
crypt-dev mailing list (join it first), where I brought this idea up a
month ago:

http://www.openwall.com/lists/crypt-dev/2012/10/14/1

You may subscribe to crypt-dev here:

http://www.openwall.com/lists/#subscribe

As the name suggests, the crypt-dev list is for development of concepts
like this.

If you have questions relating to JtR in context of these future hashes,
you may post such questions to john-users, though.

Feedback is welcome.

Thanks,

Alexander

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.