phc-discussions - RE: [PHC] Re: Suggestion: API should include a verifier function

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: <218AE73F98E99C4C98AF7D5166AA798E0906DA7D@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Wed, 27 Mar 2013 16:55:23 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Re: Suggestion: API should include a verifier function

It still depends on the work factor, the resources of the attacker, and most of all the strength of the user-chosen password.

Even if the administrator’s chosen parameters were extremely conservative, the exposure of the hashes could constitute a data breach which requires disclosure, notification of users, etc.

+1 on the ‘define separate functions for generation and validation’ plan. But it does seem like that could be done mostly independently of the design of the hash function itself.

-          Marsh

From: Watson Ladd [mailto:watsonbladd@...il.com]
Sent: Wednesday, March 27, 2013 6:16 AM
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Suggestion: API should include a verifier function

This isn't necessary: a non-constant time comparison at worst reveals the hash, which doesn't give an attacker
enough information to break a password anyway if we do our jobs right.

Content of type "text/html" skipped