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
|
|
|
"""
|
|
|
|
Django's standard crypto functions and utilities.
|
|
|
|
"""
|
2015-01-28 20:35:27 +08:00
|
|
|
import hashlib
|
2011-03-28 10:11:19 +08:00
|
|
|
import hmac
|
2019-05-16 05:45:17 +08:00
|
|
|
import secrets
|
2020-03-11 16:47:43 +08:00
|
|
|
import warnings
|
2012-02-24 05:39:12 +08:00
|
|
|
|
2015-01-28 20:35:27 +08:00
|
|
|
from django.conf import settings
|
2020-03-11 16:47:43 +08:00
|
|
|
from django.utils.deprecation import RemovedInDjango40Warning
|
2015-01-28 20:35:27 +08:00
|
|
|
from django.utils.encoding import force_bytes
|
|
|
|
|
2011-12-23 11:46:06 +08:00
|
|
|
|
2020-01-08 23:27:26 +08:00
|
|
|
class InvalidAlgorithm(ValueError):
|
|
|
|
"""Algorithm is not supported by hashlib."""
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
def salted_hmac(key_salt, value, secret=None, *, algorithm='sha1'):
|
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
|
|
|
"""
|
2020-01-08 23:27:26 +08:00
|
|
|
Return the HMAC of 'value', using a key generated from key_salt and a
|
|
|
|
secret (which defaults to settings.SECRET_KEY). Default algorithm is SHA1,
|
|
|
|
but any algorithm name supported by hashlib.new() can be passed.
|
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
|
|
|
|
|
|
|
A different key_salt should be passed in for every application of HMAC.
|
|
|
|
"""
|
|
|
|
if secret is None:
|
|
|
|
secret = settings.SECRET_KEY
|
|
|
|
|
2014-02-16 21:47:51 +08:00
|
|
|
key_salt = force_bytes(key_salt)
|
|
|
|
secret = force_bytes(secret)
|
2020-01-08 23:27:26 +08:00
|
|
|
try:
|
|
|
|
hasher = getattr(hashlib, algorithm)
|
|
|
|
except AttributeError as e:
|
|
|
|
raise InvalidAlgorithm(
|
|
|
|
'%r is not an algorithm accepted by the hashlib module.'
|
|
|
|
% algorithm
|
|
|
|
) from e
|
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
|
|
|
# We need to generate a derived key from our base key. We can do this by
|
2020-01-08 23:27:26 +08:00
|
|
|
# passing the key_salt and our base key through a pseudo-random function.
|
|
|
|
key = hasher(key_salt + secret).digest()
|
2020-01-15 18:58:01 +08:00
|
|
|
# If len(key_salt + secret) > block size of the hash algorithm, the above
|
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
|
|
|
# line is redundant and could be replaced by key = key_salt + secret, since
|
|
|
|
# the hmac module does the same thing for keys longer than the block size.
|
|
|
|
# However, we need to ensure that we *always* do this.
|
2020-01-08 23:27:26 +08:00
|
|
|
return hmac.new(key, msg=force_bytes(value), digestmod=hasher)
|
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
|
|
|
|
2011-12-23 11:46:06 +08:00
|
|
|
|
2020-03-11 16:47:43 +08:00
|
|
|
NOT_PROVIDED = object() # RemovedInDjango40Warning.
|
|
|
|
|
|
|
|
|
|
|
|
# RemovedInDjango40Warning: when the deprecation ends, replace with:
|
2020-03-11 21:38:27 +08:00
|
|
|
# def get_random_string(length, allowed_chars='...'):
|
2020-03-11 16:47:43 +08:00
|
|
|
def get_random_string(length=NOT_PROVIDED, allowed_chars=(
|
|
|
|
'abcdefghijklmnopqrstuvwxyz'
|
|
|
|
'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
|
|
|
|
)):
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2017-01-25 04:32:33 +08:00
|
|
|
Return a securely generated random string.
|
2011-12-23 11:46:06 +08:00
|
|
|
|
2020-03-11 16:47:43 +08:00
|
|
|
The bit length of the returned value can be calculated with the formula:
|
|
|
|
log_2(len(allowed_chars)^length)
|
|
|
|
|
|
|
|
For example, with default `allowed_chars` (26+26+10), this gives:
|
|
|
|
* length: 12, bit length =~ 71 bits
|
|
|
|
* length: 22, bit length =~ 131 bits
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2020-03-11 16:47:43 +08:00
|
|
|
if length is NOT_PROVIDED:
|
|
|
|
warnings.warn(
|
|
|
|
'Not providing a length argument is deprecated.',
|
|
|
|
RemovedInDjango40Warning,
|
|
|
|
)
|
|
|
|
length = 12
|
2019-05-16 05:45:17 +08:00
|
|
|
return ''.join(secrets.choice(allowed_chars) for i in range(length))
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
|
2017-01-20 00:55:23 +08:00
|
|
|
def constant_time_compare(val1, val2):
|
|
|
|
"""Return True if the two strings are equal, False otherwise."""
|
2019-05-16 05:45:17 +08:00
|
|
|
return secrets.compare_digest(force_bytes(val1), force_bytes(val2))
|
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
|
|
|
|
2013-03-18 05:14:14 +08:00
|
|
|
|
2017-01-20 00:55:23 +08:00
|
|
|
def pbkdf2(password, salt, iterations, dklen=0, digest=None):
|
|
|
|
"""Return the hash of password using pbkdf2."""
|
|
|
|
if digest is None:
|
|
|
|
digest = hashlib.sha256
|
2018-01-04 07:52:12 +08:00
|
|
|
dklen = dklen or None
|
2017-01-20 00:55:23 +08:00
|
|
|
password = force_bytes(password)
|
|
|
|
salt = force_bytes(salt)
|
|
|
|
return hashlib.pbkdf2_hmac(digest().name, password, salt, iterations, dklen)
|