Я написал небольшой веб-сервер, который в настоящее время использует базовый auth over ssl. Пока все отлично работает. Теперь я хочу (нужно) переключиться на дайджест auth. Но я не могу понять, как сделать эту работу с паролями, которые не хранятся как открытые в базе данных? У меня есть только парольный дайджест (сгенерированный с помощью bcrypt) паролей моих пользователей. Возможно ли вообще аутентификация http digest?
Зашифрованный пароль в архиве базы данных и браузера
Ответ 1
Просто смотрел в это только сейчас. Во-первых, я прочитал RFC 2617 - HTTP-аутентификация: аутентификация основного и дайджест-доступа, чтобы получить представление о спецификации и посмотреть, как ее можно адаптировать для аутентификации REST API.
Отвечайте на тот же вопрос, что и вы, - означает ли аутентификация дайджеста, что сервер должен хранить пароль пользователя в виде открытого текста?
В этом Ответ на переполнение стека дает понять: Нет. Сервер не хранит пароль открытого текста - он должен хранить хэш (username|realm|password).
Это было бы прекрасно, за исключением одного: каноническая спецификация поддерживает только MD5 как хеш-функцию.
Конечно, вы можете хранить как хэш-код bcrypt, так и хэш-код MD5, но это только подрывает безопасность хэша bcrypt, фактически делая его бесполезным (так как злоумышленник может переключить свои усилия на грубые, заставляя хеш-память MD5 вместо этого).
Итак, я сделал шаг назад и подумал: почему бы не игнорировать спецификацию и использовать bcrypt с обеих сторон как хеш-функцию (bcrypt(username|realm|password))?
Ну, кроме того, чтобы быть целенаправленно медленным, bcrypt имеет максимальную длину пароля, которая делает его непригодным для использования в качестве общего алгоритм дайджеста.
Ух, теперь моя голова плавала, но я все еще думал, чтобы он снова пошел. Некоторые из предложений заключались в использовании TLS с SRP или аутентифицированным шифрованием, в частности EAX, но я чувствовал, что, возможно, это делали вещи слишком далеко за простой веб-сервис.
Проще говоря, если вы действительно намереваетесь сделать это, вы можете работать с ограничением символов bcrypt, используя предварительный хэш.
Короче говоря, вы можете сделать:
bcrypt(sha256(username|realm|password))
И используйте это вместо H(A1) в бастардированной версии спецификации.
Теперь возникает вопрос - была ли вообще такая сложная сложность? Получили ли мы дополнительный уровень безопасности по сравнению с Basic auth over HTTPS?