Хеш пароля в базе данных рассматривается как критически чувствительное значение, несмотря на то, что сам по себе он не является исходным паролем. От правильного хранения зависит устойчивость системы к компрометации учетных записей при утечке данных.
Хеш, получаемый в JavaScript при использовании библиотек уровня password-hash, bcrypt или argon2, представляет собой строку переменной длины, содержащую:
В реляционных базах данных чаще всего используются:
VARCHAR(255) — универсальный вариант для большинства
современных алгоритмовTEXT — при использовании алгоритмов с длинными
выходными значениями (например, Argon2id с расширенными
параметрами)Использование фиксированных бинарных типов (BINARY,
VARBINARY) возможно, но требует строгого контроля формата
сериализации.
Хранение исходного пароля в любом виде исключается:
Даже кратковременное присутствие пароля в памяти процесса без необходимости увеличивает поверхность атаки.
При использовании JavaScript-библиотек формат строки хеша обычно включает все необходимые компоненты внутри одного значения.
Пример структуры:
$algorithm$parameters$salt$hashОсобенности хранения:
Современные библиотеки автоматически генерируют соль и включают её в итоговый хеш. Это исключает необходимость отдельного хранения.
Ошибки при проектировании схемы:
saltКаждая запись должна иметь уникальную соль, встроенную в хеш.
Дополнительный секретный параметр, называемый pepper, не хранится в базе данных.
Особенности:
Типичная ошибка — сохранение pepper в той же базе данных, что и хеши. В таком случае его защитная функция теряется при утечке.
Хеш пароля не участвует в поисковых или сортировочных операциях.
Следовательно:
Использование индексов увеличивает размер таблицы без практической пользы.
Проверка пароля осуществляется не сравнением строк напрямую, а через функцию проверки библиотеки.
Особенности процесса:
Прямое SQL-сравнение исключается как архитектурная ошибка.
При хранении хешей важно учитывать:
Ошибка усечения строки приводит к невозможности проверки пароля.
Со временем алгоритмы могут устаревать. В таких случаях:
Такой подход позволяет постепенно мигрировать систему без принудительного сброса паролей.
Наиболее распространённые проблемы:
В распределённых системах важно учитывать:
Несогласованность версий библиотеки password-hash или аналогов приводит к невозможности проверки ранее созданных паролей.
При изменении алгоритма хранения:
Разделение версий внутри одной таблицы предпочтительнее создания отдельных таблиц под каждый алгоритм.
Даже корректно захешированные пароли при утечке базы могут быть атакованы методом перебора.
Факторы, влияющие на стойкость:
При использовании ORM в JavaScript (Sequelize, TypeORM и аналогов):
Некорректная конфигурация ORM может привести к повторному хешированию уже хешированного значения.