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]
Date: Wed, 24 Jun 2015 22:27:07 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] RE: Why protect against side channel attacks

OK, two or three characters then. I was thinking about how I choose my own passwords. :-)

But I think my point remains, a 10x improvement for defenders is probably achievable with stronger requirements and/or better server tuning.

-----Original Message-----
From: Marcos Simplicio [mailto:mjunior@...c.usp.br] 
> Just to add to the discussion: NIST does have attempted to measure the number of bits
> a character would have in its SP.800.63-2, Appendix A
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf)
> By their estimates, each character adds ~1 bit of security after we pass the threshold
> of 8 alphanumeric chars, even if we assume that the system validates that the
> password is not in a dictionary and follows good composition rules (see Table A.1).
> These estimates may certainly be too pessimistic (and I tend to believe so), but, by their analysis, 3 bits is a lot :)

I really do think they are being a little too pessimistic, at least for the purposes of our discussion. Especially we remove from consideration the (typical) 50% of user passwords that are so weak that no work factor acceptable in practice is going to save them.

- Marsh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ