Как использовать свой алгоритм хэширования пароля в Django?

bcrypt, django

Рекомендуємо хостинг TIMEWEB

Stabiles Hosting des sozialen Netzwerks EVILEG. Wir empfehlen VDS-Hosting für Django-Projekte.

1) а чем не устроил стандартный алгоритм? (мне реально просто интересно=))
2) наследуешься от этого класса, переопределяешь классовую переменную на 15 и указываешь свой класс в качестве хешера

# utils/hashers.py

class MyBCryptSHA256PasswordHasher(MyBCryptSHA256PasswordHasher):
    rounds = 15


# settings.py

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

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

спасибо за решение.

привет

если честно это просто мой интерес, а появился вопрос после того как я где то в нете прочитал что во первых bcrypt это надежнее а если фактор 15 ТО у брудфорсеров нету никакого шанса

да и по сути не важно, я просто задался вопросом )
и спасибо вам за ответ

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

при авторизации, когда пользователь ввел пароль, присходит следующее:
1) ищется пользователь по email (если не нашелся - отбой)
2) берется хэш пароля этого пользователя и из него берется алгоритм, соль, количество преобразований
3) введеный пароль хэшируется тем же алгоритмом, с той же солью, столько же раз
4) хэши сравниваются (не совпали - отбой)

самый важный момент в плане безопасности django:
если пользователь не нашелся - всеравно будет взят хэш от введеного пароля, чтобы нельзя было по времени ответа подобрать login-ы, которые уже есть (хэширование 30 000 раз - не самая быстрая операция, которая еще и выполняется на процессоре)
без этого, если login уже есть, сервер отвечал бы на сколько-то миллисекунд дольше
а уже к выявленным логинам можно применить брутфорс, от которого шифрованием защититься нельзя
брутфорс подбор пароля можно предотвратить, сделав что-то типа 3 попытки логина и если все попытки не удачные, постепенно увеличивать задержку во времени между попытками

про второй шаг:
исключительно для обратной совместимости, поскольку раз во сколько то версий разработчики Django могут увеличить количество итераций или ввести и сделать по-умолчанию новый алгоритм, и чтобы твои уже существующие пароли не превратились в тыкву - типа старые пароли проверяются старым алгоритмом, новые - новым, и никто ничего не заметил

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

главное, в продакшене не менять SECRET_KEY - он тоже используется в хэшировании паролей + генерация кук (и если куки - не так страшны, то отвалившиеся пароли - штука печальная)