2009-06-16 2 views
9

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

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

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

ответ

7

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

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

Смежные вопросы