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: <51201575.2080402@thorsheim.net>
Date: Sun, 17 Feb 2013 00:25:41 +0100
From: Per Thorsheim <per@...rsheim.net>
To: discussions@...sword-hashing.net
CC: Marsh Ray <maray@...rosoft.com>
Subject: Re: [PHC] Different cost settings and optional input

Den 16.02.2013 23:51, skrev Marsh Ray:
> 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 

Ooh. I'd like to see an expanded explanation of that idea Marsh, 
specifically the potential consequences to security usabiliity. Am I 
reading it wrong, or could an attacker exploit your suggestion to 
actually search for 'blacklisted' passwords by trying to create an 
account legally? Perhaps better than Twitter incorporating a client-side 
blacklist of static passwords, but still....

--

This reminds me of a quick discussion I had with Colin Percival at 
Passwords^12, related to 1 of the many subjects I touched into in my 
talk: password history.

(I do not know if this is suitable or relevant for discussions here, so 
I'll just throw it in for consideration.)

For Microsoft Windows, you can extract not only a users current password 
hash (LM/NTLM), but also the complete history of password hashes. (Lets 
forget about pass-the-hash attacks for a moment here). That is - afaik - 
the number of hashes remembered in accordance with the password history 
parameter config. IMHO the more pwd hashes for a single user an attacker 
can obtain, the higher the probability an attacker will break one or 
more, and then eventually spot patterns enabling successful cracking of 
even more hashes.

I do prefer having the option available. Especially in case of a major 
compromise I'd like all users to change their passwords. If they are 
allowed to change their password into the same password as before,  
we're dead. But if users can just use the common password +1 trick, 
getting back in really doesn't represent much of a challenge for an 
attacker - he knows your next password.

If I do remember Colin correctly, he mentioned storing just parts of a 
hash value for previous passwords, as part of a password history scheme. 
This would prevent an attacker from cracking previous passwords, while 
leaving a certain risk of enabling users to change their password into 
their current password.

I have no idea on how this could be done, but in case of a major 
compromise and complete pwd reset, I'd like to prevent users from 
setting a new password that is either equal to, or very 'close' to any 
of the passwords they've used before.

Regards,
Per Thorsheim