Commit Graph

26 Commits

Author SHA1 Message Date
Florian Apolloner 68540fe4df Fixed #21138 -- Increased the performance of our PBKDF2 implementation.
Thanks go to Michael Gebetsroither for pointing out this issue and help on
the patch.
2013-09-24 21:06:26 +02:00
Paul McMillan a075e2ad0d Increase default PBKDF2 iterations
Increases the default PBKDF2 iterations, since computers have gotten
faster since 2011. In the future, we plan to increment by 10% per
major version.
2013-09-19 18:02:25 +01:00
Simon Charette 11cd7388f7 Fixed #20989 -- Removed useless explicit list comprehensions. 2013-08-30 10:57:51 -04:00
Alex Gaynor 09d0568697 Switched to using some constants the hmac module exposes. 2013-06-02 10:31:38 -07:00
Aymeric Augustin 7cf0f04230 Clarified that constant_time_compare doesn't protect string lengths. 2013-03-18 09:45:44 +01:00
Łukasz Langa 40b9f4fb8b [py3] Always fed hashlib with bytes. 2013-02-27 10:02:07 +01:00
Claude Paroz ebc773ada3 Replaced many smart_bytes by force_bytes
In all those occurrences, we didn't care about preserving the
lazy status of the strings, but we really wanted to obtain a
real bytestring.
2012-08-29 11:20:32 +02:00
Aymeric Augustin e89bc39935 Reverted type check added in 62954ba04c.
Refs #17040.
2012-08-21 09:00:55 +02:00
Aymeric Augustin 62954ba04c [py3] Fixed #17040 -- ported django.utils.crypto.constant_time_compare.
This is a private API; adding a type check is acceptable.
2012-08-20 22:50:49 +02:00
Aymeric Augustin 127b461b11 [py3] Ported django.utils.crypto. 2012-08-07 12:00:23 +02:00
Aymeric Augustin c5ef65bcf3 [py3] Ported django.utils.encoding.
* Renamed smart_unicode to smart_text (but kept the old name under
  Python 2 for backwards compatibility).
* Renamed smart_str to smart_bytes.
* Re-introduced smart_str as an alias for smart_text under Python 3
  and smart_bytes under Python 2 (which is backwards compatible).
  Thus smart_str always returns a str objects.
* Used the new smart_str in a few places where both Python 2 and 3
  want a str.
2012-08-07 12:00:22 +02:00
Claude Paroz 690cabe203 Used a Python 3-compatible syntax for building a translation table 2012-07-22 18:05:53 +02:00
Aymeric Augustin a84d79f572 [py3] Added Python 3 compatibility for xrange. 2012-07-22 09:29:56 +02:00
Aymeric Augustin 56dbe924a6 [py3] Removed longs. 2012-07-22 09:29:53 +02:00
Claude Paroz 4a103086d5 Fixed #18269 -- Applied unicode_literals for Python 3 compatibility.
Thanks Vinay Sajip for the support of his django3 branch and
Jannis Leidel for the review.
2012-06-07 18:08:47 +02:00
Claude Paroz eb286aa22f Delayed encoding of password and salt in password checking.
Applied the rule that string encoding should happen as late as
possible. This is also a preparation for Python 3 compatibility.
2012-06-06 10:53:16 +02:00
Claude Paroz 35e6585568 Imported reduce from functools for forward compatibility.
In Python 3, reduce has to be imported from functools.
2012-05-20 00:25:46 +02:00
Claude Paroz 38408f8007 Marked bytestrings with b prefix. Refs #18269
This is a preparation for unicode literals general usage in
Django (Python 3 compatibility).
2012-05-19 17:43:34 +02:00
Paul McMillan 1525874238 Improved get_random_string().
Improved the behavior of get_random_string to re-seed itself each time it is called
if the system does not have a secure random number generator. This will change the
properties of the random string produced, but will be unpredictable to an attacker.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@17581 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2012-02-23 22:51:14 +00:00
Paul McMillan 239e41f7c5 Cleanup to use get_random_string consistently.
Removes several ad hoc implementations of get_random_string()
and removes an innapropriate use of settings.SECRET_KEY.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@17580 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2012-02-23 21:39:12 +00:00
Paul McMillan a77679dfaa Fixes #16827. Adds a length check to CSRF tokens before applying the santizing regex. Thanks to jedie for the report and zsiciarz for the initial patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17500 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2012-02-11 04:18:15 +00:00
Paul McMillan 1030d66a14 Fixed #17481. pbkdf2 hashes no longer ommit leading zeros.
Some existing user passwords may need to be reset or converted 
after this change. See the 1.4-beta release notes for more details.

Thanks bhuztez for the report and initial patch, claudep for the test.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@17418 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2012-02-02 04:44:17 +00:00
Paul McMillan dce820ff70 Renovated password hashing. Many thanks to Justine Tunney for help with the initial patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17253 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-12-23 03:46:06 +00:00
Adrian Holovaty 13864703bc Removed a bunch more Python 2.4 workarounds now that we don't support that version. Refs #15702 -- thanks to jonash for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15927 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-03-28 02:11:19 +00:00
Luke Plant d81b3aa739 Fixed Python 2.4 incompatibility introduced in [14218]
sha_constructor was incorrectly used instead of sha_hmac (which only made a
difference under 2.4).

Thanks to Steffan Kaminski for report and patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14233 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 11:11:08 +00:00
Luke Plant 45c7f427ce Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.

In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.

All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.

There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-14 20:54:30 +00:00