phc-discussions - RE: [PHC] Different cost settings and optional input

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: <218AE73F98E99C4C98AF7D5166AA798E09036F40@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Sat, 16 Feb 2013 22:51:25 +0000
From: Marsh Ray <maray@...rosoft.com>
To: Jens Christian Hillerup <jens@...lerup.net>, Jens Steube
	<jens.steube@...il.com>
CC: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Different cost settings and optional input

> -----Original Message-----
> From: jenschristian@...il.com [mailto:jenschristian@...il.com] On Behalf
> 
> However, this attack is not that important I'd argue, because if two equal
> passwords *exist* it is likely that that password is in some dictionary anyway,
> or that they originate from the same person.

Without disagreeing with your point, I thought I'd take the opportunity to dig up some anecdotes:

>From http://reusablesec.blogspot.com/2009/12/rockyou-32-million-password-list-top.html :
>
> Per Thorsheim wrote:
> > I would like to see a comparison of Twitters 370 banned passwords
> > against the top 370 or so passwords stolen from rockyou (http://www.techcrunch.com/2009/12/27/twitter-banned-passwords/)
>
> A grand total of 38 of the top 100 passwords did not appear in the Twitter blacklist.

Solar would probably have a better sense of things, but my feeling is that probably of all the passwords that have been chosen by exactly two users independently, most of them are not in a dictionary.

I've tried to convince people of the merits of the following scheme:
Use a fixed salt or otherwise allow the comparison of hashes.
Maintain a dictionary or other database of 'seen' hashes across all users. Incorporate the latest breaches into your dictionary.
If new user B selects a password (or it appears in a new breach) that is the same as existing user A, force B to select another one and immediately *disable* user A until A successfully performs a password reset operation.

No one seems to care much for this proposal though :-)

- Marsh