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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH8yC8=G0VnQudMqS5yA4GHQRbv=i0m3vQREkMfBwxtvjFv9qQ@mail.gmail.com>
Date: Tue, 12 Feb 2013 18:11:54 -0500
From: Jeffrey Walton <noloader@...il.com>
To: Travis Biehn <tbiehn@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: #warning -- DICE.COM insecure passwords

On Tue, Feb 12, 2013 at 5:58 PM, Travis Biehn <tbiehn@...il.com> wrote:
> What Tim said. I think warning was writing about the public shame from
> having a massive pw dump not having some neckbeard expose them over using
> crypt on some random industry mailing list (shudders).
>
> Here is a long article on secure password storage. It is extremely exciting:
> http://www.cigital.com/justice-league-blog/2012/06/11/securing-password-digests-or-how-to-protect-lonely-unemployed-radio-listeners/
I got to attend that talk given at OWASP in Northern Virginia
(https://www.owasp.org/index.php/Virginia, JULY 2012).

John Steven and did a great job.

Jeff

> On Tue, Feb 12, 2013 at 5:14 PM, Tim <tim-security@...tinelchicken.org>
> wrote:
>>
>> > That's assuming that they didn't do the risk analysis and decide that
>> > the effort required to fix the problem (which will probably require,
>> > among other things, having every single user change their password)
>> > is worth the effort.  Given that so many places have gotten hacked and
>> > pwned that the user community response is usually "Meh. Another one",
>> > they may rightfully have concluded that risking public shaming is
>> > in fact a good business decision...
>>
>>
>> Here's a bit of pseudocode for you Valdis:
>>
>> for each user:
>>   let user.new_hash = scrypt(user.old_crypt_hash)
>>
>> # now update authentication routine to use user.new_hash with new
>> # nested hashing algorithm
>>
>>
>> So really, there's actually not a good reason to keep a crappy hash
>> database around.  Just add a layer of good salted hashing on top.
>>
>> With that said, the unusual quirk of crypt being limited to 7
>> characters is an additional challenge, but you can start with the
>> above steps (which immediately improves security), and then slowly
>> transition to using scrypt alone or some variant that supports longer
>> passwords.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ