Хеширование, соление и борьба с грубой силой!
Сегодня начинаю работу с бэкендом. Скучная штука. Но это составляет «ядро» любого веб-приложения. Ядро должно быть сильным.
Как решить проблему ответственного и безопасного хранения паролей пользователей? Ответ: я их не храню (как и любой ответственный поставщик веб-сервисов).
Типичный рабочий процесс здесь — хеширование паролей перед их сохранением (предварительное подключение) в базе данных. «Хеш» — это просто красивое слово, обозначающее зашифрованную версию пароля.
Но на этом решение не заканчивается. Оказывается, люди «статистически» используют одинаковые пароли. Это означает, что теоретически возможно запустить базу данных статистически похожих паролей (легко висящие плоды даркнета) с помощью одного и того же алгоритма хеширования для грубого доступа.
Такие атаки известны как «атаки радужной таблицы». Противодействием таким атакам является добавление хотя бы одной уникальной (сгенерированной) строки к входному паролю пользователя перед его хешированием.
Эта строка обычно называется «Соль» или «Перец» или и то, и другое, в зависимости от того, как она реализована. Таким образом, сохраненный хэш будет совершенно другим, даже если два пользователя выберут один и тот же пароль.
Если вам интересно узнать больше об этой теме, я написал эссе на эту тему здесь.
На заглавном изображении вы видите простую пользовательскую схему, которую я написал для начала. После этого я написал собственный файл раздачи, который заполняет (тестовую) базу данных тестовыми пользователями (нижняя половина изображения).
Я буду использовать этот упрощенный макет для разработки основных функций серверной части (регистрация, проверка, верификация и т. д.) для начала, прежде чем приступить к работе над интерфейсом; все еще бегает на скорости. Веселые времена.
