2008-08-01 04:47:53 +08:00
|
|
|
from datetime import date
|
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-15 04:54:30 +08:00
|
|
|
|
2008-08-01 04:47:53 +08:00
|
|
|
from django.conf import settings
|
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-15 04:54:30 +08:00
|
|
|
from django.utils.hashcompat import sha_constructor
|
2008-08-01 04:47:53 +08:00
|
|
|
from django.utils.http import int_to_base36, base36_to_int
|
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-15 04:54:30 +08:00
|
|
|
from django.utils.crypto import constant_time_compare, salted_hmac
|
2008-08-01 04:47:53 +08:00
|
|
|
|
|
|
|
class PasswordResetTokenGenerator(object):
|
|
|
|
"""
|
2009-02-22 14:08:37 +08:00
|
|
|
Strategy object used to generate and check tokens for the password
|
2008-08-01 04:47:53 +08:00
|
|
|
reset mechanism.
|
|
|
|
"""
|
|
|
|
def make_token(self, user):
|
|
|
|
"""
|
|
|
|
Returns a token that can be used once to do a password reset
|
|
|
|
for the given user.
|
|
|
|
"""
|
|
|
|
return self._make_token_with_timestamp(user, self._num_days(self._today()))
|
|
|
|
|
|
|
|
def check_token(self, user, token):
|
|
|
|
"""
|
|
|
|
Check that a password reset token is correct for a given user.
|
|
|
|
"""
|
2009-02-22 14:08:37 +08:00
|
|
|
# Parse the token
|
2008-08-01 04:47:53 +08:00
|
|
|
try:
|
|
|
|
ts_b36, hash = token.split("-")
|
|
|
|
except ValueError:
|
|
|
|
return False
|
|
|
|
|
|
|
|
try:
|
|
|
|
ts = base36_to_int(ts_b36)
|
|
|
|
except ValueError:
|
|
|
|
return False
|
|
|
|
|
|
|
|
# Check that the timestamp/uid has not been tampered with
|
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-15 04:54:30 +08:00
|
|
|
if not constant_time_compare(self._make_token_with_timestamp(user, ts), token):
|
|
|
|
# Fallback to Django 1.2 method for compatibility.
|
|
|
|
# PendingDeprecationWarning <- here to remind us to remove this in
|
|
|
|
# Django 1.5
|
|
|
|
if not constant_time_compare(self._make_token_with_timestamp_old(user, ts), token):
|
|
|
|
return False
|
2008-08-01 04:47:53 +08:00
|
|
|
|
|
|
|
# Check the timestamp is within limit
|
|
|
|
if (self._num_days(self._today()) - ts) > settings.PASSWORD_RESET_TIMEOUT_DAYS:
|
|
|
|
return False
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
def _make_token_with_timestamp(self, user, timestamp):
|
|
|
|
# timestamp is number of days since 2001-1-1. Converted to
|
|
|
|
# base 36, this gives us a 3 digit string until about 2121
|
|
|
|
ts_b36 = int_to_base36(timestamp)
|
|
|
|
|
|
|
|
# By hashing on the internal state of the user and using state
|
|
|
|
# that is sure to change (the password salt will change as soon as
|
|
|
|
# the password is set, at least for current Django auth, and
|
|
|
|
# last_login will also change), we produce a hash that will be
|
|
|
|
# invalid as soon as it is used.
|
|
|
|
# We limit the hash to 20 chars to keep URL short
|
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-15 04:54:30 +08:00
|
|
|
key_salt = "django.contrib.auth.tokens.PasswordResetTokenGenerator"
|
|
|
|
value = unicode(user.id) + \
|
|
|
|
user.password + user.last_login.strftime('%Y-%m-%d %H:%M:%S') + \
|
|
|
|
unicode(timestamp)
|
|
|
|
hash = salted_hmac(key_salt, value).hexdigest()[::2]
|
|
|
|
return "%s-%s" % (ts_b36, hash)
|
|
|
|
|
|
|
|
def _make_token_with_timestamp_old(self, user, timestamp):
|
|
|
|
# The Django 1.2 method
|
|
|
|
ts_b36 = int_to_base36(timestamp)
|
2008-08-02 13:56:57 +08:00
|
|
|
hash = sha_constructor(settings.SECRET_KEY + unicode(user.id) +
|
2009-04-02 05:25:24 +08:00
|
|
|
user.password + user.last_login.strftime('%Y-%m-%d %H:%M:%S') +
|
2008-08-02 13:56:57 +08:00
|
|
|
unicode(timestamp)).hexdigest()[::2]
|
2008-08-01 04:47:53 +08:00
|
|
|
return "%s-%s" % (ts_b36, hash)
|
|
|
|
|
|
|
|
def _num_days(self, dt):
|
2008-08-02 13:56:57 +08:00
|
|
|
return (dt - date(2001,1,1)).days
|
2008-08-01 04:47:53 +08:00
|
|
|
|
|
|
|
def _today(self):
|
|
|
|
# Used for mocking in tests
|
2008-08-02 13:56:57 +08:00
|
|
|
return date.today()
|
2008-08-01 04:47:53 +08:00
|
|
|
|
|
|
|
default_token_generator = PasswordResetTokenGenerator()
|