[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.w14w4qnuyldrnw@laptop-air>
Date: Tue, 20 Aug 2013 14:39:52 -0700
From: "Jeremy Spilman" <jeremy@...link.co>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Terminology goals
I agree it's useful for us to have some general knowledge of the hashing
function / work factor that was in place. I think the best place for this
is inside a published privacy policy, and it would be great if this became
expected / established practice. Companies avoid this by claiming they
want to keep it secret, which we know is always useless, and often harmful.
For communicating a breach to end users, I think any mention of hashing
misses or even obfuscates the key point. The major thrust of any breach
notification should be that the user's password is "lost" and that they
should never use that password, on any site, ever again.
Once an attacker has all the data required to run an offline attack,
successful password cracking will always be a function of password
complexity and hashing complexity. In a highly simplified view of 'weak'
and 'strong' passwords, and 'weak' and 'strong' hashing functions, you
would need both strong passwords with strong hashing to defend against a
short-term offline attack.
To put it another way, no amount of hashing complexity can protect a weak
password from an offline attack. And most passwords are weak.
The biggest problem I see with the current crop of breach notifications is
the "This means that the password files are unreadable" part. This is not
actually true, and using scrypt or bcrypt or even PHC-Finalist-X doesn't
make it true. Companies are hiding behind hashing, when they should be
admitting that "Most password data breaches result in the vast majority of
users' passwords being exposed."
Content of type "text/html" skipped
Powered by blists - more mailing lists