0
$\begingroup$

Given we are using well-known hashing functions for passwords, i.e. SHA256, SHA512, BCrypt or, PBKDF2. Our Information Assurance SMEs have advised that we truncate the input into these hashing functions:

…to prevent the hashing function splitting it into multiple hashes.

I have not heard of hash functions doing this, in fact, I had assumed that hashing a string down with a hashing function would produce a fixed length string - am I incorrect to make this assumption?

$\endgroup$
  • 1
    $\begingroup$ SHA256 and SHA512 are NOT valid hashing functions for passwords!! Otherwise, your assumption seems correct to me, and I fail to make sense fo the quoted recommendation. $\endgroup$ – fgrieu Feb 2 '18 at 11:36
  • $\begingroup$ @fgrieu because they are fast, and thus considered weak? $\endgroup$ – Richard Slater Feb 2 '18 at 12:46
  • 1
    $\begingroup$ Yes; additionally, normal hashes have no built-in provision for salt or pepper, a must for password hashes. Ah, notoriously, BCrypt has a size limitation, see this; perhaps that's related to the recommendation? $\endgroup$ – fgrieu Feb 2 '18 at 12:53
  • $\begingroup$ Simply hash the input password once, and use the hash as the password input to the KDF. I assume they dont want to have DOS attacks with super long passwords. This works for both PBKDF2 and Bcrypt $\endgroup$ – Richie Frame Feb 3 '18 at 2:52
  • $\begingroup$ @RichieFrame sadly this isn't supported by ForgeRock, the platform we are using. $\endgroup$ – Richard Slater Feb 3 '18 at 16:31
4
$\begingroup$

The infamous "LANMAN hash" used in older Windows versions had a problem where it split passwords into 7 byte chunks and computed a hash for each separately. This, together with lack of salt, and other poor design decisions meant that a password of "keyboard42" and a password of "KeyBoarMint" store the same first value, making it uniquely vulnerable to a time-space tradeoff called "Rainbow tables" in which an adversary pre-calculates lots of data and then needs very little work to reverse an password hash.

Not only are the modern schemes you've mentioned proof against such attacks, even in the 1970s a competently designed password hash was not vulnerable to Rainbow tables. The advice you were given is very poor.

$\endgroup$
0
$\begingroup$

Even if our password hash has a fixed length output. Since passwords tend to have low entropy density. lengthening the password well past the size of the hash can still add valuable entropy.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.