Comments on: Let's Talk Password Hashing https://pthree.org/2016/06/28/lets-talk-password-hashing/ Linux. GNU. Freedom. Mon, 11 Mar 2019 19:57:14 +0000 hourly 1 https://wordpress.org/?v=5.3-alpha-45756 By: Hans https://pthree.org/2016/06/28/lets-talk-password-hashing/#comment-278617 Sat, 10 Nov 2018 10:38:34 +0000 https://pthree.org/?p=4699#comment-278617 "Never roll your own" - see anything wrong with this?
1: sha2-384 hash the password
2: base64-encode the hash
3: bcrypt the 64-byte base64-encoded sha2-384 hash

why? primarily, it bypasses 2 issues, 1: bcrypt only support passwords up to 72 bytes, this scheme supports any length. 2: many popular bcrypt implementations stop at the first null-byte, which means binary passwords (which may be used by robots/scripts) may inadvertently become very weak, eg if the password is "x33\x00", on most bcrypt implementations, the password simply becomes `3` because hex 33 is ascii 3, and the 00 is treated as end of string.. base64 never emits null bytes, which means your robots/scripts which create their passwords based on /dev/urandom will be safe.

]]>
By: mGalli https://pthree.org/2016/06/28/lets-talk-password-hashing/#comment-273495 Thu, 15 Feb 2018 18:04:15 +0000 https://pthree.org/?p=4699#comment-273495 There is an error on the description of Argon2 algorithms. The Argon2i is more suitable for key derivations AND password hashing.

Page 3, Our Solution section of Argon2: the memory-hard function for password hashing and other applications. Please check the documentation here https://password-hashing.net/argon2-specs.pdf

"Argon2i uses data-independent memory access, which is preferred for password hashing and-based key derivation"

]]>
By: RB https://pthree.org/2016/06/28/lets-talk-password-hashing/#comment-272850 Fri, 01 Dec 2017 08:13:03 +0000 https://pthree.org/?p=4699#comment-272850 I would love to hear the thoughts on using HMAC v/s these hash functions of a cost factor leading to .5 seconds for password verification. Sure there is a risk of HMAC key compromise, but those risks can be mitigated by rotating the HMAC key often. Also as this operations will be totally CPU bound, what is the cost for password hash creation and verification and computation power needed. There are other attack scenarios where an adversary can DOS the systems by sending multiple bad passwords. So many more compensatory controls need be thought through and built if we an organization decides to use high cost factor hash functions.

]]>
By: Aaron Toponce https://pthree.org/2016/06/28/lets-talk-password-hashing/#comment-265709 Wed, 06 Jul 2016 15:01:00 +0000 https://pthree.org/?p=4699#comment-265709 Never roll your own. This is the problem Ashley Madison ran into. Although they deployed bcrypt with an acceptable cost factor of 12, they subverted it through encrypted MD5 tokens, which allowed password crackers to quickly tear through the password hashes. If cost isn't a factor, then increase it. Don't roll your own.

]]>
By: Sandra https://pthree.org/2016/06/28/lets-talk-password-hashing/#comment-265692 Tue, 05 Jul 2016 11:36:12 +0000 https://pthree.org/?p=4699#comment-265692 If cost is not an issue, what are your thoughts about using two hashing functions. First scrypt, and then either another pw hash func or an enc hash func, if the output from a pw hash func cannot be treated as a pw when hashing?

]]>