Arthur de Jong

Open Source / Free Software developer

summaryrefslogtreecommitdiffstats
path: root/django/utils/crypto.py
Commit message (Collapse)AuthorAgeFilesLines
* Sorted imports with isort; refs #23860.Tim Graham2015-02-061-8/+8
|
* Fixed #23812 -- Changed django.utils.six.moves.xrange ↵Michael Hall2014-12-131-2/+2
| | | | imports to range
* Bump the default iterations for PBKDF2.Alex Gaynor2014-07-121-6/+8
| | | | The rate at which we've increased this has not been keeping up with hardware (and software) improvements, and we're now considerably behind where we should be. The delta between our performance and an optimized implementation's performance prevents us from improving that further, but hopefully once Python 2.7.8 and 3.4+ get into more hands we can more aggressively increase this number.
* Note that the stdlib's version of pbkdf2_hmac will also ↵Alex Gaynor2014-05-311-1/+1
| | | | be used in the upcoming Python 2.7.8 release
* Fixed constant_time_compare on Python 2.7.7Florian Apolloner2014-05-281-1/+2
| | | | | | | | Python 2.7.7 includes compare_digest in the hmac module, but it requires both arguments to have the same type. This is usually not a problem on Python 3 since everything is text, but we have mixed unicode and str on Python 2 -- hence make sure everything is bytes before feeding it into compare_digest.
* Use the stdlib's compare_digest for constant time ↵Alex Gaynor2014-04-221-19/+23
| | | | comparisons when available
* Typo fixAlex Gaynor2014-04-171-2/+2
|
* Use the stdlib's PBKDF2 implementation when available.Alex Gaynor2014-04-171-48/+65
| | | | | | | | This is a bit faster than ours, which is good, because it lets you increase the iteration counts. This will be used on Python 3.4+, and, pending the acceptance of PEP466, on newer Python 2.7s.
* Fixed #19980: Signer broken for binary keys (with ↵MattBlack852014-02-161-1/+4
| | | | | | | | non-ASCII chars). With this pull request, request #878 should considered closed. Thanks to nvie for the patch.
* Flake8 fixesAlex Gaynor2013-11-051-2/+0
|
* Simplify (and very very slightly speed up) the pbkdf2 ↵Alex Gaynor2013-11-041-12/+12
| | | | implementation
* Fixed #21253 -- PBKDF2 with cached HMAC keyFlorian Apolloner2013-10-211-20/+9
| | | | | | This gives a 2x speed increase compared to the existing implementation. Thanks to Steve Thomas for the initial patch and Tim Graham for finishing it.
* Fixed #21287 -- Fixed E123 pep8 warningsAlasdair Nicol2013-10-181-1/+1
|
* Fixed #21138 -- Increased the performance of our PBKDF2 ↵Florian Apolloner2013-09-241-3/+7
| | | | | | | implementation. Thanks go to Michael Gebetsroither for pointing out this issue and help on the patch.
* Increase default PBKDF2 iterationsPaul McMillan2013-09-191-5/+6
| | | | | | Increases the default PBKDF2 iterations, since computers have gotten faster since 2011. In the future, we plan to increment by 10% per major version.
* Fixed #20989 -- Removed useless explicit list ↵Simon Charette2013-08-301-1/+1
| | | | comprehensions.
* Switched to using some constants the hmac module exposes.Alex Gaynor2013-06-021-6/+2
|
* Clarified that constant_time_compare doesn't protect ↵Aymeric Augustin2013-03-181-0/+5
| | | | string lengths.
* [py3] Always fed hashlib with bytes.Łukasz Langa2013-02-271-2/+2
|
* Replaced many smart_bytes by force_bytesClaude Paroz2012-08-291-4/+4
| | | | | | 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.
* Reverted type check added in 62954ba04c.Aymeric Augustin2012-08-211-4/+2
| | | | Refs #17040.
* [py3] Fixed #17040 -- ported ↵Aymeric Augustin2012-08-201-3/+10
| | | | | | django.utils.crypto.constant_time_compare. This is a private API; adding a type check is acceptable.
* [py3] Ported django.utils.crypto.Aymeric Augustin2012-08-071-5/+6
|
* [py3] Ported django.utils.encoding.Aymeric Augustin2012-08-071-4/+4
| | | | | | | | | | | * 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.
* Used a Python 3-compatible syntax for building a ↵Claude Paroz2012-07-221-2/+2
| | | | translation table
* [py3] Added Python 3 compatibility for xrange.Aymeric Augustin2012-07-221-0/+1
|
* [py3] Removed longs.Aymeric Augustin2012-07-221-1/+1
|
* Fixed #18269 -- Applied unicode_literals for Python 3 ↵Claude Paroz2012-06-071-2/+4
| | | | | | | compatibility. Thanks Vinay Sajip for the support of his django3 branch and Jannis Leidel for the review.
* Delayed encoding of password and salt in password checking.Claude Paroz2012-06-061-0/+3
| | | | | Applied the rule that string encoding should happen as late as possible. This is also a preparation for Python 3 compatibility.
* Imported reduce from functools for forward compatibility.Claude Paroz2012-05-201-0/+1
| | | | In Python 3, reduce has to be imported from functools.
* Marked bytestrings with b prefix. Refs #18269Claude Paroz2012-05-191-4/+4
| | | | | This is a preparation for unicode literals general usage in Django (Python 3 compatibility).
* Improved get_random_string().Paul McMillan2012-02-231-2/+22
| | | | | | | | | 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
* Cleanup to use get_random_string consistently.Paul McMillan2012-02-231-6/+8
| | | | | | | | 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
* Fixes #16827. Adds a length check to CSRF tokens before ↵Paul McMillan2012-02-111-3/+4
| | | | | | 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
* Fixed #17481. pbkdf2 hashes no longer ommit leading zeros. Paul McMillan2012-02-021-15/+15
| | | | | | | | | | 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
* Renovated password hashing. Many thanks to Justine ↵Paul McMillan2011-12-231-1/+95
| | | | | | Tunney for help with the initial patch. git-svn-id: http://code.djangoproject.com/svn/django/trunk@17253 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Removed a bunch more Python 2.4 workarounds now that we ↵Adrian Holovaty2011-03-281-8/+4
| | | | | | 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
* Fixed Python 2.4 incompatibility introduced in [14218]Luke Plant2010-10-151-2/+2
| | | | | | | | | 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
* Fixed #14445 - Use HMAC and constant-time comparison ↵Luke Plant2010-10-141-0/+45
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