0

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?

Richard Slater
  • 103
  • 3
  • 1
    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. – fgrieu Feb 02 '18 at 11:36
  • @fgrieu because they are fast, and thus considered weak? – Richard Slater Feb 02 '18 at 12:46
  • 1
    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? – fgrieu Feb 02 '18 at 12:53
  • 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 – Richie Frame Feb 03 '18 at 02:52
  • @RichieFrame sadly this isn't supported by ForgeRock, the platform we are using. – Richard Slater Feb 03 '18 at 16:31
  • If you have the ability to modify the user input by truncation before it gets to the KDF, why cant you hash it before it gets to the KDF? – Richie Frame Feb 04 '18 at 10:10
  • @RichieFrame maximum password length is configured by ForgeRock itself, not handled by the client application. – Richard Slater Feb 05 '18 at 14:32

2 Answers2

4

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.

tialaramex
  • 372
  • 1
  • 5
0

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.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54