| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
upcoming Python 2.7.8 release
|
|
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.
|
|
|
|
|
|
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.
|
|
With this pull request, request #878 should considered closed.
Thanks to nvie for the patch.
|
|
|
|
|
|
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.
|
|
|
|
Thanks go to Michael Gebetsroither for pointing out this issue and help on
the patch.
|
|
Increases the default PBKDF2 iterations, since computers have gotten
faster since 2011. In the future, we plan to increment by 10% per
major version.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Refs #17040.
|
|
This is a private API; adding a type check is acceptable.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
Thanks Vinay Sajip for the support of his django3 branch and
Jannis Leidel for the review.
|
|
Applied the rule that string encoding should happen as late as
possible. This is also a preparation for Python 3 compatibility.
|
|
In Python 3, reduce has to be imported from functools.
|
|
This is a preparation for unicode literals general usage in
Django (Python 3 compatibility).
|
|
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
|
|
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
|
|
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
|
|
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
|
|
initial patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17253 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
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
|
|
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
|
|
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
|
