check_password should use constant_time_compare instead of == to check passwords

[Harro]

I just noticed django doesn't use the constant_time_compare function in the check_password function in contrib.auth.models.

I'll add a patch that changes it, would be nice to have this little bit extra security in the 1.3 release.

[Harro]

Patch to use constant_time_compare

[Russell Keith-Magee]

In [15870]:

Fixed #15627 -- Use constant time comparison for password checks. Thanks to hvdklauw for the report and patch.

[Luke Plant]

For the record, this code is not actually vulnerable to a timing-based attack, as neither of the strings compared by the '==' is user supplied, or can be controlled easily by the user.

To actually attack this code using a timing-attacks, you would have to:

1. Know the salt that was stored
2. Generate a password that, when passed through get_hexdigest(algo, salt, raw_password) would produce a given prefix, e.g. 'a', 'aa', 'ab', 'aab' etc. This is Hard - we store password hashes precisely because going from the hash (or part of the hash) to the string that generated it is difficult.
3. In this way, control the RHS of the comparison, and by measuring timings eventually extract the hash (and therefore the password which you generated in step 2).

But anyway.

[Russell Keith-Magee]

@luke - Yeah - I knew it would be extremely hard to turn this into a functional attack, but it cost nothing to make the change, on the off chance that anyone ever found a way to construct a hash-based timing attack, we're pre-emptively protected.

[Jacob]

Milestone 1.3 deleted