Управление паролями в 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.contrib.auth.hashers.BCryptPasswordHasher',
]

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

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

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

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

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

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

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

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.contrib.auth.hashers.BCryptPasswordHasher',
   ]
   

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

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

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

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

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

2. Измените PASSWORD_HASHERS, поместив BCryptSHA256PasswordHasher в первую позицию. В вашем файле настроек это будет выглядеть так:

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

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

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

Увеличение коэффициента сложности алгоритма паролей

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.contrib.auth.hashers.BCryptPasswordHasher',
   ]
   

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

Argon2

Argon2 имеет три настраиваемые характеристики:

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

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

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

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

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

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

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

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

Если у вас есть существующая база данных со старым слабым хешем, например 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(PBKDF2WrappedSHA1PasswordHasher, self).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, и коэффициентом сложности по умолчанию хеширователя. Это предотвращает атаки на перечисление пользователей с таймингом из-за разницы между запросом входа в систему для пользователя с паролем, закодированным в старом числе итераций, и несуществующим пользователем (который использует число итераций по умолчанию хеширователя).

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

Если ваш хеширователь не имеет коэффициента сложности, реализуйте метод как no-op (pass).

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

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

check_password(password, encoded) [source]

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

make_password(password, salt=None, hasher='default') [source]

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

is_password_usable(encoded_password) [source]

Проверяет, является ли заданная строка хешированным паролем, который может быть проверен против check_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, который проверяет, не встречается ли пароль в списке распространённых паролей. По умолчанию он сравнивает с включённым списком из 1000 распространённых паролей.
• NumericPasswordValidator, который проверяет, не является ли пароль полностью цифровым.

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

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

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

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

class MinimumLengthValidator(min_length=8) [source]

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

class UserAttributeSimilarityValidator(user_attributes=DEFAULT_USER_ATTRIBUTES, max_similarity=0.7) [source]

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

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

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

class CommonPasswordValidator(password_list_path=DEFAULT_PASSWORD_LIST_PATH) [source]

Проверяет, является ли пароль распространённым. По умолчанию, это проверяет список из 1000 распространённых паролей, созданных Марком Бернеттом.

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

class NumericPasswordValidator [source]

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

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

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

validate_password(password, user=None, password_validators=None) [source]

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

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

password_changed(password, user=None, password_validators=None) [source]

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

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

password_validators_help_texts(password_validators=None) [source]

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

password_validators_help_text_html(password_validators=None)

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

get_password_validators(validator_config) [source]

Возвращает набор объектов валидаторов, основанных на параметре 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 ugettext as _

class MinimumLengthValidator(object):
    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), который будет вызван после успешного изменения пароля. Это можно использовать для предотвращения повторного использования пароля, например. Однако, если вы решите хранить предыдущие пароли пользователя, никогда не делайте это в открытом тексте.