Управление паролями в Django

Управление паролями — это то, что обычно не стоит изобретать заново, и Django стремится предоставить безопасный и гибкий набор инструментов для управления паролями пользователей. В этом документе описано, как Django хранит пароли, как можно настроить хэширование хранения и некоторые утилиты для работы с хэшированными паролями.

Как Django хранит пароли

Django предоставляет гибкую систему хранения паролей и использует PBKDF2 по умолчанию.

Атрибут password объекта User представляет собой строку в следующем формате:

<algorithm>$<iterations>$<salt>$<hash>

Это компоненты, используемые для хранения пароля пользователя, разделенные символом «доллар»: алгоритм хэширования, количество итераций алгоритма (фактор работы), случайный соль и полученный хэш пароля. Алгоритм — это один из ряда односторонних алгоритмов хэширования или хранения паролей, которые может использовать Django; см. ниже. Итерации описывают количество раз, когда алгоритм выполняется над хэшем. Соль — это случайное начальное значение, а хэш — результат односторонней функции.

По умолчанию Django использует алгоритм PBKDF2 с хэшем SHA256, механизм растяжения паролей, рекомендуемый NIST. Это должно быть достаточно для большинства пользователей: это довольно безопасно, для взлома требуется огромное количество вычислительного времени.

Однако в зависимости от ваших требований вы можете выбрать другой алгоритм или даже использовать пользовательский алгоритм, чтобы соответствовать вашей конкретной ситуации с безопасностью. Опять же, большинству пользователей это не нужно — если вы не уверены, вам, вероятно, не нужно. Если вы уверены, читайте дальше:

Django выбирает используемый алгоритм, обращаясь к настройке PASSWORD_HASHERS. Это список классов алгоритмов хэширования, которые поддерживает данная установка Django. Первый элемент в этом списке (то есть settings.PASSWORD_HASHERS[0]) будет использоваться для хранения паролей, а все остальные элементы — это допустимые хэшера, которые можно использовать для проверки существующих паролей. Это означает, что если вы хотите использовать другой алгоритм, вам нужно изменить PASSWORD_HASHERS, чтобы первый в списке был ваш предпочтительный алгоритм.

Значение по умолчанию для PASSWORD_HASHERS такое:

PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]

Это означает, что Django будет использовать PBKDF2 для хранения всех паролей, но будет поддерживать проверку паролей, хранящихся с помощью PBKDF2SHA1, argon2 и bcrypt.

В следующих разделах описаны несколько распространённых способов, с помощью которых продвинутые пользователи могут изменить эту настройку.

Использование Argon2 с Django

Argon2 — победитель конкурса 2015 года Password Hashing Competition, организованного сообществом конкурса на выбор алгоритма хэширования следующего поколения. Он разработан так, чтобы быть не легче для вычислений на специализированном оборудовании, чем на обычном процессоре.

Argon2 не является по умолчанию для Django, потому что для него требуется сторонняя библиотека. Однако комиссия конкурса по хэшированию паролей рекомендует немедленно использовать Argon2 вместо других поддерживаемых Django алгоритмов.

Чтобы использовать Argon2 в качестве алгоритма хранения по умолчанию, выполните следующие действия:

1. Установите библиотеку argon2-cffi. Это можно сделать, выполнив python -m pip install django[argon2], что эквивалентно python -m pip install argon2-cffi, (наряду с любыми требованиями к версиям из setup.cfg).

2. Измените PASSWORD_HASHERS, чтобы Argon2PasswordHasher стоял первым. То есть в файле настроек вы бы указали:

   PASSWORD_HASHERS = [
       'django.contrib.auth.hashers.Argon2PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
       'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
   ]
   

   Сохраните и/или добавьте другие элементы в этот список, если вам нужно, чтобы Django обновлял пароли.

Использование bcrypt с Django

Bcrypt — популярный алгоритм хранения паролей, специально разработанный для долгосрочного хранения паролей. По умолчанию Django не использует его, так как для него требуется использование сторонних библиотек, но поскольку многие пользователи могут захотеть его использовать, Django поддерживает bcrypt с минимальными усилиями.

Чтобы использовать Bcrypt в качестве алгоритма хранения по умолчанию, выполните следующие действия:

1. Установите библиотеку bcrypt. Это можно сделать, выполнив python -m pip install django[bcrypt], что эквивалентно python -m pip install bcrypt, (наряду с любыми требованиями к версиям из setup.cfg).

2. Измените PASSWORD_HASHERS, чтобы BCryptSHA256PasswordHasher стоял первым. То есть в файле настроек вы бы указали:

   PASSWORD_HASHERS = [
       'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
       'django.contrib.auth.hashers.Argon2PasswordHasher',
   ]
   

   Сохраните и/или добавьте другие элементы в этот список, если вам нужно, чтобы Django обновлял пароли.

Это всё — теперь ваша установка Django будет использовать Bcrypt в качестве алгоритма хранения по умолчанию.

Увеличение энтропии соли

Большинство хэшей паролей включают соль вместе с хэшем пароля, чтобы защититься от атак с использованием таблиц радуги. Сама соль — это случайное значение, которое увеличивает размер и, следовательно, стоимость таблицы радуги, и в настоящее время устанавливается в 128 бит с помощью значения salt_entropy в BasePasswordHasher. По мере снижения стоимости вычислений и хранения это значение следует повышать. При реализации собственного хэшера паролей вы можете переопределить это значение, чтобы использовать желаемый уровень энтропии для хэшей паролей. salt_entropy измеряется в битах.

Увеличение фактора работы алгоритма пароля

PBKDF2 и bcrypt

Алгоритмы PBKDF2 и bcrypt используют количество итераций или циклов хэширования. Это намеренно замедляет злоумышленников, делая атаки на хэшированные пароли сложнее. Однако по мере увеличения вычислительной мощности количество итераций необходимо увеличивать. Мы выбрали разумное значение по умолчанию (и будем увеличивать его с каждым выпуском Django), но вы можете настроить его вверх или вниз в зависимости от ваших потребностей в безопасности и доступной вычислительной мощности. Для этого вы будете подклассировать соответствующий алгоритм и переопределите параметры iterations. Например, чтобы увеличить количество итераций, используемых алгоритмом PBKDF2 по умолчанию:

1. Создайте подкласс django.contrib.auth.hashers.PBKDF2PasswordHasher:

   from django.contrib.auth.hashers import PBKDF2PasswordHasher
   
   class MyPBKDF2PasswordHasher(PBKDF2PasswordHasher):
       """
       A subclass of PBKDF2PasswordHasher that uses 100 times more iterations.
       """
       iterations = PBKDF2PasswordHasher.iterations * 100
   

   Сохраните это где-нибудь в своем проекте. Например, вы можете поместить это в файл, подобный myproject/hashers.py.

2. Добавьте ваш новый хэшер в качестве первого элемента в PASSWORD_HASHERS:

   PASSWORD_HASHERS = [
       'myproject.hashers.MyPBKDF2PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2PasswordHasher',
       'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
       'django.contrib.auth.hashers.Argon2PasswordHasher',
       'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
   ]
   

Это все — теперь ваша установка Django будет использовать больше итераций при хранении паролей с помощью PBKDF2.

Argon2

У Argon2 есть три атрибута, которые можно настроить:

1. time_cost контролирует количество итераций внутри хэша.
2. memory_cost контролирует размер памяти, который должен быть использован при вычислении хэша.
3. parallelism контролирует, на скольких процессорах можно распараллелить вычисление хэша.

Значения этих атрибутов по умолчанию, вероятно, вам подойдут. Если вы определите, что хэш пароля слишком быстрый или слишком медленный, вы можете его настроить следующим образом:

1. Выберите parallelism в качестве количества потоков, которые вы можете использовать для вычисления хэша.
2. Выберите memory_cost в качестве числа Кбайт памяти, которые вы можете использовать.
3. Отрегулируйте time_cost и измерьте время, необходимое для хэширования пароля. Выберите time_cost, которое займет приемлемое время для вас. Если time_cost, установленное в 1, неприемлемо медленно, уменьшите memory_cost.

Обновление паролей

При входе пользователей, если их пароли хранятся с алгоритмом, отличным от предпочтительного, Django автоматически обновит алгоритм до предпочтительного. Это означает, что старые установки Django станут автоматически более безопасными при входе пользователей, а также означает, что вы можете переключиться на новые (и лучшие) алгоритмы хранения по мере их изобретения.

Однако Django может обновлять только пароли, использующие алгоритмы, упомянутые в PASSWORD_HASHERS, поэтому при переходе на новые системы необходимо следить за тем, чтобы никогда не удалять записи из этого списка. Если вы это сделаете, пользователи, использующие не упомянутые алгоритмы, не смогут обновить свои пароли. Хешированные пароли будут обновляться при увеличении (или уменьшении) количества итераций PBKDF2, раундов bcrypt или атрибутов argon2.

Обратите внимание, что если все пароли в вашей базе данных не закодированы по умолчанию алгоритмом хэширования, вы можете быть уязвимы к атаке на определение времени пользователя из-за разницы между продолжительностью запроса входа в систему для пользователя с паролем, закодированным в нестандартном алгоритме, и продолжительностью запроса входа в систему для несуществующего пользователя (который использует стандартный алгоритм хэширования). Вы можете смягчить это, обновив старые хэши паролей.

Обновление паролей без необходимости входа в систему

Если у вас есть существующая база данных со старым, слабым хэшем, таким как MD5 или SHA1, вы можете захотеть обновить эти хэши самостоятельно, вместо того, чтобы ждать обновления во время входа в систему пользователя (что может никогда не произойти, если пользователь не вернётся на ваш сайт). В этом случае вы можете использовать «обёрнутый» хэшер паролей.

В этом примере мы мигрируем набор хэшей SHA1 для использования PBKDF2(SHA1(пароль)) и добавим соответствующий хэшер паролей для проверки, если пользователь ввёл правильный пароль при входе. Мы предполагаем, что мы используем встроенную User модель и что наш проект имеет приложение accounts. Вы можете изменить шаблон для работы с любым алгоритмом или с настраиваемой моделью пользователя.

Сначала мы добавим настраиваемый хэшер:

from django.contrib.auth.hashers import (
    PBKDF2PasswordHasher, SHA1PasswordHasher,
)


class PBKDF2WrappedSHA1PasswordHasher(PBKDF2PasswordHasher):
    algorithm = 'pbkdf2_wrapped_sha1'

    def encode_sha1_hash(self, sha1_hash, salt, iterations=None):
        return super().encode(sha1_hash, salt, iterations)

    def encode(self, password, salt, iterations=None):
        _, _, sha1_hash = SHA1PasswordHasher().encode(password, salt).split('$', 2)
        return self.encode_sha1_hash(sha1_hash, salt, iterations)

Миграция данных может выглядеть примерно так:

from django.db import migrations

from ..hashers import PBKDF2WrappedSHA1PasswordHasher


def forwards_func(apps, schema_editor):
    User = apps.get_model('auth', 'User')
    users = User.objects.filter(password__startswith='sha1$')
    hasher = PBKDF2WrappedSHA1PasswordHasher()
    for user in users:
        algorithm, salt, sha1_hash = user.password.split('$', 2)
        user.password = hasher.encode_sha1_hash(sha1_hash, salt)
        user.save(update_fields=['password'])


class Migration(migrations.Migration):

    dependencies = [
        ('accounts', '0001_initial'),
        # replace this with the latest migration in contrib.auth
        ('auth', '####_migration_name'),
    ]

    operations = [
        migrations.RunPython(forwards_func),
    ]

Обратите внимание, что эта миграция займёт несколько минут для нескольких тысяч пользователей, в зависимости от скорости вашего оборудования.

Наконец, мы добавим настройку PASSWORD_HASHERS:

PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'accounts.hashers.PBKDF2WrappedSHA1PasswordHasher',
]

Включите в этот список все другие хэширующие алгоритмы, используемые вашим сайтом.

Включённые хэширующие алгоритмы

Полный список хэшеров, включенных в Django:

[
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
    'django.contrib.auth.hashers.BCryptPasswordHasher',
    'django.contrib.auth.hashers.SHA1PasswordHasher',
    'django.contrib.auth.hashers.MD5PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
    'django.contrib.auth.hashers.CryptPasswordHasher',
]

Соответствующие имена алгоритмов:

• pbkdf2_sha256
• pbkdf2_sha1
• argon2
• bcrypt_sha256
• bcrypt
• sha1
• md5
• unsalted_sha1
• unsalted_md5
• crypt

Написание собственного хэшера паролей

Если вы пишете собственный хэшер паролей, содержащий коэффициент сложности, например, количество итераций, вы должны реализовать метод harden_runtime(self, password, encoded) для устранения разрыва во времени выполнения между коэффициентом сложности, заданным в encoded пароле, и коэффициентом сложности по умолчанию хэшера. Это предотвращает атаку на определение времени пользователя из-за разницы между запросом входа в систему для пользователя с паролем, закодированным с помощью старого количества итераций, и несуществующим пользователем (который использует по умолчанию количество итераций стандартного хэшера).

В качестве примера, если encoded содержит 20 000 итераций, а по умолчанию iterations хэшера составляет 30 000, метод должен выполнить password ещё через 10 000 итераций PBKDF2.

Если ваш хэшер не имеет коэффициента сложности, реализуйте метод как операцию без действия (pass).

Ручное управление паролем пользователя

Модуль django.contrib.auth.hashers предоставляет набор функций для создания и проверки хэшированных паролей. Вы можете использовать их независимо от модели User.

check_password(password, encoded)

Если вы хотите вручную аутентифицировать пользователя, сравнив пароль в формате обычного текста с хэшированным паролем в базе данных, используйте удобную функцию check_password(). Она принимает два аргумента: пароль в формате обычного текста для проверки и полное значение поля password пользователя в базе данных для проверки, и возвращает True, если они совпадают, False в противном случае.

make_password(password, salt=None, hasher='default')

Создаёт хэшированный пароль в формате, используемом этим приложением. Она принимает один обязательный аргумент: пароль в формате обычного текста (строка или байты). Дополнительно вы можете указать соль и алгоритм хэширования для использования, если вы не хотите использовать значения по умолчанию (первая запись в PASSWORD_HASHERS настройке). См. Включённые хэширующие алгоритмы для имени алгоритма каждого хэшера. Если аргумент password является None, возвращается непригодный пароль (который никогда не будет принят функцией check_password()).

Изменено в Django 3.1:

Параметр password должен быть строкой или байтами, если он не None.

is_password_usable(encoded_password)

Возвращает False, если пароль является результатом вызова User.set_unusable_password().

Валидация паролей

Пользователи часто выбирают слабые пароли. Для смягчения этой проблемы Django предлагает валидацию паролей с возможностью подключения. Вы можете настроить несколько валидаторов паролей одновременно. В Django включено несколько валидаторов, но вы также можете написать свои собственные.

Каждый валидатор паролей должен предоставить текст справки, чтобы объяснить требования пользователю, проверить данный пароль и вернуть сообщение об ошибке, если он не соответствует требованиям, и, при необходимости, получить пароли, которые были установлены. Валидаторы также могут иметь дополнительные настройки для настройки своего поведения.

Валидация контролируется настройкой AUTH_PASSWORD_VALIDATORS. По умолчанию для этой настройки является пустой список, что означает, что валидаторы не применяются. В новых проектах, созданных с помощью шаблона по умолчанию startproject, набор валидаторов по умолчанию включён.

По умолчанию, валидаторы используются в формах для сброса или изменения паролей, и в командной утилите управления createsuperuser и changepassword. Валидаторы не применяются на уровне модели, например, в User.objects.create_user() и create_superuser(), так как мы предполагаем, что разработчики, а не пользователи, взаимодействуют с Django на этом уровне, а также потому, что валидация модели не выполняется автоматически в процессе создания моделей.

Включение валидации паролей

Валидация паролей настраивается в настройке AUTH_PASSWORD_VALIDATORS:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 9,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

Этот пример включает все четыре включённых валидатора:

• UserAttributeSimilarityValidator, который проверяет сходство пароля с набором атрибутов пользователя.
• MinimumLengthValidator, который проверяет, соответствует ли пароль минимальной длине. Этот валидатор настроен с пользовательским параметром: теперь он требует минимальной длины в девять символов вместо стандартных восьми.
• CommonPasswordValidator, который проверяет, не встречается ли пароль в списке общих паролей. По умолчанию он сравнивает с включённым списком из 20 000 общих паролей.
• NumericPasswordValidator, который проверяет, не является ли пароль полностью числовым.

Для UserAttributeSimilarityValidator и CommonPasswordValidator в этом примере используются стандартные настройки. NumericPasswordValidator не имеет настроек.

Тексты справки и любые ошибки от валидаторов паролей всегда возвращаются в том порядке, в котором они перечислены в AUTH_PASSWORD_VALIDATORS.

Включенные валидаторы

Django включает четыре валидатора:

class MinimumLengthValidator(min_length=8)

Проверяет, соответствует ли пароль минимальной длине. Минимальная длина может быть настраиваема с помощью параметра min_length.

class UserAttributeSimilarityValidator(user_attributes=DEFAULT_USER_ATTRIBUTES, max_similarity=0.7)

Проверяет, достаточно ли пароль отличается от определённых атрибутов пользователя.

Параметр user_attributes должен быть итерируемым объектом имён атрибутов пользователя для сравнения. Если этот аргумент не указан, используется значение по умолчанию: 'username', 'first_name', 'last_name', 'email'. Атрибуты, которые не существуют, игнорируются.

Минимальное сходство отклоняемого пароля может быть установлено в диапазоне от 0 до 1 с помощью параметра max_similarity. Значение 0 отклоняет все пароли, а значение 1 отклоняет только пароли, идентичные значению атрибута.

class CommonPasswordValidator(password_list_path=DEFAULT_PASSWORD_LIST_PATH)

Проверяет, является ли пароль распространённым. Преобразует пароль в нижний регистр (для выполнения сравнения без учёта регистра) и проверяет его на соответствие списку из 20 000 распространённых паролей, созданных Royce Williams.

Параметр password_list_path можно установить в путь к файлу с пользовательскими распространёнными паролями. Этот файл должен содержать по одному паролю в нижнем регистре на каждой строке и может быть текстовым или сжатым с помощью gzip.

class NumericPasswordValidator

Проверяет, не является ли пароль полностью числовым.

Интеграция проверки

В django.contrib.auth.password_validation есть несколько функций, которые можно вызвать из собственных форм или другого кода для интеграции проверки паролей. Это может быть полезно, если вы используете пользовательские формы для установки паролей или у вас есть вызовы API, которые позволяют устанавливать пароли, например.

validate_password(password, user=None, password_validators=None)

Проверяет пароль. Если все валидаторы считают пароль допустимым, возвращает None. Если один или несколько валидаторов отклоняют пароль, генерирует ValidationError со всеми сообщениями об ошибках от валидаторов.

Объект user необязателен: если он не предоставлен, некоторые валидаторы могут не иметь возможности выполнить проверку и примут любой пароль.

password_changed(password, user=None, password_validators=None)

Сообщает всем валидаторам, что пароль был изменён. Это может использоваться валидаторами, такими как тот, что предотвращает повторное использование паролей. Это следует вызывать после успешной смены пароля.

Для подклассов AbstractBaseUser, поле пароля будет помечено как «изменённое» при вызове set_password(), что запускает вызов password_changed() после сохранения пользователя.

password_validators_help_texts(password_validators=None)

Возвращает список сообщений справки всех валидаторов. Они объясняют требования к паролю пользователю.

password_validators_help_text_html(password_validators=None)

Возвращает строку HTML со всеми сообщениями справки в <ul>. Это полезно при добавлении проверки паролей в формы, так как вы можете передать результат непосредственно в параметр help_text поля формы.

get_password_validators(validator_config)

Возвращает набор объектов валидаторов на основе параметра validator_config. По умолчанию все функции используют валидаторы, определённые в AUTH_PASSWORD_VALIDATORS, но вызвав эту функцию с альтернативным набором валидаторов и передав результат в параметр password_validators других функций, ваш пользовательский набор валидаторов будет использован вместо этого. Это полезно, когда у вас есть типичный набор валидаторов для большинства сценариев, но также есть особая ситуация, требующая пользовательского набора. Если вы всегда используете один и тот же набор валидаторов, нет необходимости использовать эту функцию, так как конфигурация из AUTH_PASSWORD_VALIDATORS используется по умолчанию.

Структура validator_config идентична структуре AUTH_PASSWORD_VALIDATORS. Возвращаемое значение этой функции может быть передано в параметр password_validators перечисленных выше функций.

Обратите внимание, что пароль, передаваемый одной из этих функций, всегда должен быть текстом - а не хэшированным паролем.

Создание собственного валидатора

Если встроенные валидаторы Django недостаточны, вы можете создать собственные валидаторы паролей. У валидаторов довольно небольшой интерфейс. Они должны реализовать два метода:

• validate(self, password, user=None): валидирует пароль. Возвращает None если пароль допустим или генерирует ValidationError с сообщением об ошибке, если пароль недопустим. Вы должны уметь обрабатывать ситуацию, когда user будет None — если это означает, что ваш валидатор не может работать, возвращайте None для отсутствия ошибки.
• get_help_text(): предоставляет сообщение справки для объяснения требований пользователю.

Любые элементы в OPTIONS в AUTH_PASSWORD_VALIDATORS для вашего валидатора будут переданы в конструктор. Все аргументы конструктора должны иметь значение по умолчанию.

Вот базовый пример валидатора с одним необязательным параметром:

from django.core.exceptions import ValidationError
from django.utils.translation import gettext as _

class MinimumLengthValidator:
    def __init__(self, min_length=8):
        self.min_length = min_length

    def validate(self, password, user=None):
        if len(password) < self.min_length:
            raise ValidationError(
                _("This password must contain at least %(min_length)d characters."),
                code='password_too_short',
                params={'min_length': self.min_length},
            )

    def get_help_text(self):
        return _(
            "Your password must contain at least %(min_length)d characters."
            % {'min_length': self.min_length}
        )

Вы также можете реализовать password_changed(password, user=None), которое будет вызываться после успешной смены пароля. Это можно использовать, например, для предотвращения повторного использования паролей. Однако, если вы решите хранить предыдущие пароли пользователя, никогда не делайте это в виде открытого текста.