diff options
| author | Florian Apolloner <florian@apolloner.eu> | 2016-02-13 21:09:46 +0100 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2016-03-01 11:25:28 -0500 |
| commit | 67b46ba7016da2d259c1ecc7d666d11f5e1cfaab (patch) | |
| tree | 83a054a12f2486e3c4de4749f8c6058c6819387b /docs/topics | |
| parent | c5544d289233f501917e25970c03ed444abbd4f0 (diff) | |
Fixed CVE-2016-2513 -- Fixed user enumeration timing attack during login.
This is a security fix.
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/auth/passwords.txt | 31 |
1 files changed, 31 insertions, 0 deletions
diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt index ecddeddbfa..47d6486dd9 100644 --- a/docs/topics/auth/passwords.txt +++ b/docs/topics/auth/passwords.txt @@ -186,6 +186,14 @@ unmentioned algorithms won't be able to upgrade. Hashed passwords will be updated when increasing (or decreasing) the number of PBKDF2 iterations or bcrypt rounds. +Be aware that if all the passwords in your database aren't encoded in the +default hasher's algorithm, you may be vulnerable to a user enumeration timing +attack due to a difference between the duration of a login request for a user +with a password encoded in a non-default algorithm and the duration of a login +request for a nonexistent user (which runs the default hasher). You may be able +to mitigate this by :ref:`upgrading older password hashes +<wrapping-password-hashers>`. + .. versionchanged:: 1.9 Passwords updates when changing the number of bcrypt rounds was added. @@ -310,6 +318,29 @@ The corresponding algorithm names are: * ``unsalted_md5`` * ``crypt`` +.. _write-your-own-password-hasher: + +Writing your own hasher +----------------------- + +.. versionadded:: 1.9.3 + +If you write your own password hasher that contains a work factor such as a +number of iterations, you should implement a +``harden_runtime(self, password, encoded)`` method to bridge the runtime gap +between the work factor supplied in the ``encoded`` password and the default +work factor of the hasher. This prevents a user enumeration timing attack due +to difference between a login request for a user with a password encoded in an +older number of iterations and a nonexistent user (which runs the default +hasher's default number of iterations). + +Taking PBKDF2 as example, if ``encoded`` contains 20,000 iterations and the +hasher's default ``iterations`` is 30,000, the method should run ``password`` +through another 10,000 iterations of PBKDF2. + +If your hasher doesn't have a work factor, implement the method as a no-op +(``pass``). + Manually managing a user's password =================================== |
