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.
|
|
|
|
"""
|
2012-06-08 00:08:47 +08:00
|
|
|
from __future__ import unicode_literals
|
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-03-28 10:11:19 +08:00
|
|
|
import hmac
|
2011-12-23 11:46:06 +08:00
|
|
|
import struct
|
|
|
|
import hashlib
|
|
|
|
import binascii
|
2012-02-24 06:51:14 +08:00
|
|
|
import time
|
2012-02-24 05:39:12 +08:00
|
|
|
|
2012-02-24 06:51:14 +08:00
|
|
|
# Use the system PRNG if possible
|
2012-02-24 05:39:12 +08:00
|
|
|
import random
|
|
|
|
try:
|
|
|
|
random = random.SystemRandom()
|
2012-02-24 06:51:14 +08:00
|
|
|
using_sysrandom = True
|
2012-02-24 05:39:12 +08:00
|
|
|
except NotImplementedError:
|
2012-02-24 06:51:14 +08:00
|
|
|
import warnings
|
|
|
|
warnings.warn('A secure pseudo-random number generator is not available '
|
|
|
|
'on your system. Falling back to Mersenne Twister.')
|
|
|
|
using_sysrandom = False
|
2012-02-24 05:39:12 +08:00
|
|
|
|
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.conf import settings
|
2012-08-29 02:59:56 +08:00
|
|
|
from django.utils.encoding import force_bytes
|
2012-08-21 04:45:13 +08:00
|
|
|
from django.utils import six
|
2012-07-21 00:53:11 +08:00
|
|
|
from django.utils.six.moves import xrange
|
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
|
|
|
|
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
|
|
|
def salted_hmac(key_salt, value, secret=None):
|
|
|
|
"""
|
|
|
|
Returns the HMAC-SHA1 of 'value', using a key generated from key_salt and a
|
|
|
|
secret (which defaults to settings.SECRET_KEY).
|
|
|
|
|
|
|
|
A different key_salt should be passed in for every application of HMAC.
|
|
|
|
"""
|
|
|
|
if secret is None:
|
|
|
|
secret = settings.SECRET_KEY
|
|
|
|
|
|
|
|
# We need to generate a derived key from our base key. We can do this by
|
|
|
|
# passing the key_salt and our base key through a pseudo-random function and
|
|
|
|
# SHA1 works nicely.
|
2012-06-08 00:08:47 +08:00
|
|
|
key = hashlib.sha1((key_salt + secret).encode('utf-8')).digest()
|
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 len(key_salt + secret) > sha_constructor().block_size, the above
|
|
|
|
# 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.
|
2012-08-29 02:59:56 +08:00
|
|
|
return hmac.new(key, msg=force_bytes(value), digestmod=hashlib.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
|
|
|
|
2011-12-23 11:46:06 +08:00
|
|
|
|
2012-02-11 12:18:15 +08:00
|
|
|
def get_random_string(length=12,
|
|
|
|
allowed_chars='abcdefghijklmnopqrstuvwxyz'
|
|
|
|
'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'):
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2012-02-24 06:51:14 +08:00
|
|
|
Returns a securely generated random string.
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
The default length of 12 with the a-z, A-Z, 0-9 character set returns
|
2012-02-24 05:39:12 +08:00
|
|
|
a 71-bit value. log_2((26+26+10)^12) =~ 71 bits
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2012-02-24 06:51:14 +08:00
|
|
|
if not using_sysrandom:
|
|
|
|
# This is ugly, and a hack, but it makes things better than
|
|
|
|
# the alternative of predictability. This re-seeds the PRNG
|
|
|
|
# using a value that is hard for an attacker to predict, every
|
|
|
|
# time a random string is required. This may change the
|
|
|
|
# properties of the chosen random sequence slightly, but this
|
|
|
|
# is better than absolute predictability.
|
|
|
|
random.seed(
|
|
|
|
hashlib.sha256(
|
2013-02-27 11:26:15 +08:00
|
|
|
("%s%s%s" % (
|
2012-02-24 06:51:14 +08:00
|
|
|
random.getstate(),
|
|
|
|
time.time(),
|
2013-02-27 11:26:15 +08:00
|
|
|
settings.SECRET_KEY)).encode('utf-8')
|
2013-10-18 17:02:43 +08:00
|
|
|
).digest())
|
2013-08-30 07:20:00 +08:00
|
|
|
return ''.join(random.choice(allowed_chars) for i in range(length))
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
def constant_time_compare(val1, val2):
|
|
|
|
"""
|
2012-08-21 14:44:16 +08:00
|
|
|
Returns True if the two strings are equal, False otherwise.
|
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
|
|
|
|
|
|
|
The time taken is independent of the number of characters that match.
|
2013-03-18 05:14:14 +08:00
|
|
|
|
|
|
|
For the sake of simplicity, this function executes in constant time only
|
|
|
|
when the two strings have the same length. It short-circuits when they
|
|
|
|
have different lengths. Since Django only uses it to compare hashes of
|
|
|
|
known expected length, this is acceptable.
|
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 len(val1) != len(val2):
|
|
|
|
return False
|
|
|
|
result = 0
|
2012-08-21 14:44:16 +08:00
|
|
|
if six.PY3 and isinstance(val1, bytes) and isinstance(val2, bytes):
|
2012-08-21 04:45:13 +08:00
|
|
|
for x, y in zip(val1, val2):
|
|
|
|
result |= x ^ y
|
|
|
|
else:
|
|
|
|
for x, y in zip(val1, val2):
|
|
|
|
result |= ord(x) ^ ord(y)
|
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
|
|
|
return result == 0
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
|
2012-02-02 12:44:17 +08:00
|
|
|
def _bin_to_long(x):
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
|
|
|
Convert a binary string into a long integer
|
|
|
|
|
|
|
|
This is a clever optimization for fast xor vector math
|
|
|
|
"""
|
2012-08-05 22:12:10 +08:00
|
|
|
return int(binascii.hexlify(x), 16)
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
|
2012-02-02 12:44:17 +08:00
|
|
|
def _long_to_bin(x, hex_format_string):
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2012-02-02 12:44:17 +08:00
|
|
|
Convert a long integer into a binary string.
|
|
|
|
hex_format_string is like "%020x" for padding 10 characters.
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
2012-06-08 00:08:47 +08:00
|
|
|
return binascii.unhexlify((hex_format_string % x).encode('ascii'))
|
2011-12-23 11:46:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
def pbkdf2(password, salt, iterations, dklen=0, digest=None):
|
|
|
|
"""
|
|
|
|
Implements PBKDF2 as defined in RFC 2898, section 5.2
|
|
|
|
|
|
|
|
HMAC+SHA256 is used as the default pseudo random function.
|
|
|
|
|
2013-09-20 00:39:43 +08:00
|
|
|
As of 2011, 10,000 iterations was the recommended default which
|
|
|
|
took 100ms on a 2.2Ghz Core 2 Duo. This is probably the bare
|
|
|
|
minimum for security given 1000 iterations was recommended in
|
|
|
|
2001. This code is very well optimized for CPython and is only
|
|
|
|
four times slower than openssl's implementation. Look in
|
|
|
|
django.contrib.auth.hashers for the present default.
|
2011-12-23 11:46:06 +08:00
|
|
|
"""
|
|
|
|
assert iterations > 0
|
|
|
|
if not digest:
|
|
|
|
digest = hashlib.sha256
|
2012-08-29 02:59:56 +08:00
|
|
|
password = force_bytes(password)
|
|
|
|
salt = force_bytes(salt)
|
2011-12-23 11:46:06 +08:00
|
|
|
hlen = digest().digest_size
|
|
|
|
if not dklen:
|
|
|
|
dklen = hlen
|
|
|
|
if dklen > (2 ** 32 - 1) * hlen:
|
|
|
|
raise OverflowError('dklen too big')
|
|
|
|
l = -(-dklen // hlen)
|
|
|
|
r = dklen - (l - 1) * hlen
|
|
|
|
|
2012-02-02 12:44:17 +08:00
|
|
|
hex_format_string = "%%0%ix" % (hlen * 2)
|
|
|
|
|
2013-09-18 07:14:38 +08:00
|
|
|
inner, outer = digest(), digest()
|
|
|
|
if len(password) > inner.block_size:
|
2013-09-18 04:59:56 +08:00
|
|
|
password = digest(password).digest()
|
2013-09-18 07:14:38 +08:00
|
|
|
password += b'\x00' * (inner.block_size - len(password))
|
|
|
|
inner.update(password.translate(hmac.trans_36))
|
|
|
|
outer.update(password.translate(hmac.trans_5C))
|
2013-09-18 04:59:56 +08:00
|
|
|
|
2011-12-23 11:46:06 +08:00
|
|
|
def F(i):
|
2013-11-05 01:45:27 +08:00
|
|
|
u = salt + struct.pack(b'>I', i)
|
|
|
|
result = 0
|
|
|
|
for j in xrange(int(iterations)):
|
|
|
|
dig1, dig2 = inner.copy(), outer.copy()
|
|
|
|
dig1.update(u)
|
|
|
|
dig2.update(dig1.digest())
|
|
|
|
u = dig2.digest()
|
|
|
|
result ^= _bin_to_long(u)
|
|
|
|
return _long_to_bin(result, hex_format_string)
|
|
|
|
|
|
|
|
T = [F(x) for x in range(1, l)]
|
|
|
|
return b''.join(T) + F(l)[:r]
|