0

If I'm not wrong, by default PHP's password_hash with PASSWORD_ARGON2I outputs a 43-character alphanumeric hash among other things. While this means that simple passwords that are shorter than 43 characters, or those that use only alphanumeric (or fewer) chars would be sufficiently encrypted, I would like to know if this effectively results in passwords after a certian length being truncated. Also, how does it affect passwords of sufficient length that use special characters?

Why would it not be more secure to use a longer hash?

Dwarf Vader
  • 117
  • 2
  • 7
    I think you just need to understand how hashing works. – schroeder Mar 25 '18 at 20:01
  • I wouldn't deny that. I suppose truncating is completely unrelated. But don't I run into a chance of collisions (however small) if someone used a 40-character password with special chars? – Dwarf Vader Mar 25 '18 at 20:12
  • How are you defining "collisions"? – schroeder Mar 25 '18 at 20:15
  • 1
    43 characters of Base64 is 256 bits. The chances of collision in that space for any two random inputs is approximately 1 in 57,896,044,618,658,097,711,785,492,504,344,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 – Polynomial Mar 25 '18 at 20:23
  • How hard would it be to test it? – symcbean Mar 25 '18 at 22:10
  • `password_hash` automatically adds a random salt so even if 2 of the same passwords were supplied the hash would be different. And I mean, I understand now that the string isn't truncated in any sense, that was stupid. I was just saying that a password of around 40 characters isn't unbelievable - whether you are using phrases for passwords, or a password manager, altough not too common - and it opens a possibility of collisions? I am wondering why this specific length was picked as a standard. – Dwarf Vader Mar 25 '18 at 22:20
  • 1
    @Polynomial That is 2^255. Wouldn't collision resistance be 2^128 instead? – forest Mar 31 '18 at 05:56
  • 2
    @forest Yes, sorry, I had not considered the effects of the birthday problem. – Polynomial Apr 25 '18 at 15:29

1 Answers1

2

Argon2 is a key derivation function, or KDF. It is designed to be computationally-expensive and require a large amount of working memory in order to make brute force attacks more difficult. Internally, Argon2 uses a fast cryptographically-secure hash function called Blake2b.

A hash function takes an input of arbitrary length (the message) and maps it to an output of fixed length (the digest). When any single bit in the message changes, 50% of bits in the digest are expected to change. This effectively means that any change to the input results in a completely different output. Because the digest is a fixed size, the pigeonhole principle dictates that there will be some distinct messages which inevitably result in the same output digest. A cryptographically-secure hash function ensures that there is no mathematical way to predict what inputs will result in identical outputs. Any technique that makes finding such identical outputs easy is a collision attack.

A collision attack is any attack against a hash function f where a pair of inputs m ≠ m' is found and f(m) = f(m'). A 43-character base64-encoded output is 256 bits of data. Due to the birthday paradox, the collision resistance of an n-bit digest (a digest with a keyspace of 2n) is 2n / 2. This means the collision resistance of a 256-bit digest will be 2256 / 2 = 2128. A more mathematical explanation of hash function collisions and the birthday paradox is provided over at Crypto.SE.

In an information-theoretic sense, it would be more secure to use a larger output digest in that the output space would be larger. In practice, 128-bit collision resistance is more than enough.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
forest
  • 65,613
  • 20
  • 208
  • 262