Хранение пароля в таблицах и проверка подлинности дайджеста

Вопрос о том, как хранить пароли пользователей веб-сайтов в таблицах, несколько раз поднимался на SO, и общий совет - хранить хэш пароля, в конечном итоге хеш HMAC. Это отлично подходит для обычной проверки подлинности или для проверки подлинности на основе форм (на самом деле то же самое). Моя проблема в том, что я должен предоставить также аутентификацию Digest, нацеленную на автоматизированные инструменты, подключающиеся к моему сервису. Я рассматривал эту проблему, и, как я вижу, единственным хешем, который я могу сохранить, является часть HA1 в Digest : хэш username : realm : password. Таким образом, я могу проверить как Basic / Form, так и Digest.

Моя проблема в том, что я не вижу никакой пользы в этом. На самом деле злоумышленник не может использовать аутентификацию на основе Basic или на основе форм, если он получает мою таблицу паролей (поскольку он имеет только хэшированное значение, и ему нужно отправить четкий пароль), но ничто не мешает ему использовать аутентификацию Digest и давать действительный ответ к моей службе: он просто начинает с предварительно вычисленного HA1 из таблицы и продолжает обработку ответа оттуда (т. е. то же самое, что я сделал бы, чтобы проверить пользователя на внутреннем сервере).

Я что-то упускаю? Является ли добавление требования к дайджесту в основном делает хранение хешированных паролей no-op из security pov, в лучшем случае запутывание?

security,authentication,

9

Ответов: 1


7 принят

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

Атакующий может действительно аутентифицироваться, но он не может (легко) видеть пароль моих драгоценных пользователей и компрометировать другие службы, которые они используют и т. Д.

безопасность, аутентификация,
Похожие вопросы