Системы паролей, которые запрашивают отдельные письма - что они хранят?

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

Очевидно, что такая схема не может работать с использованием обычного хеширования паролей, так как вам нужно знать весь пароль для вычисления хэша.

Что обычно используют такие системы для серверной части, чтобы сделать эту работу?

Сохранят ли они пароль в виде открытого текста или, может быть, отдельный хэш каждой буквы или что?

Ответ 1

Как вы правильно заметили, стандартные схемы хэширования пароля не будут работать, если проверка подлинности выполняется с использованием только подстроки пароля. Существует несколько способов реализации такой системы:

Сохранить пароль в обычном режиме:

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

Сохраните пароль, зашифрованный, расшифруйте, чтобы проверить:

Не более безопасно, чем хранить его в обычном режиме, если ключ шифрования также скомпрометирован.
Может удовлетворять правилам, запрещающим хранение паролей в обычном режиме.
Можно сделать более безопасным, используя выделенный аппаратный модуль безопасности или отдельный сервер аутентификации, который сохранит ключ и предоставит черно- box для проверки шифрования и подстроки.

Хранить хэши всех (или достаточно много) возможных подстрок:

Требуется гораздо больше места для хранения, чем другие решения.
Пароль может быть восстановлен достаточно легко с помощью грубой силы, если база данных скомпрометирована, поскольку каждая подстрока может быть атакована отдельно.

Использовать k-out-of-n пороговый секретный доступ:

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

В конечном счете, все эти схемы страдают от слабости от нападений грубой силы, если база данных скомпрометирована. Основная причина этого заключается в том, что в трехбуквенной подстроке типичного пароля (или, действительно, даже особо сильного) имеется не очень много энтропии, поэтому не требуется много догадок для взлома.

Какой из них лучше? Это трудно сказать. Если бы мне пришлось выбирать одну из этих схем, я бы, вероятно, пошел за зашифрованным хранилищем, используя сильное симметричное шифрование (например, AES), с отдельным сервером или HSM для обработки шифрования и проверки. Таким образом, по крайней мере, злоумышленник, ставящий под угрозу работу переднего сервера, не сможет просто скопировать базу данных и атаковать ее в автономном режиме (хотя они все равно могут установить атаку грубой силы на HSM, если она не реализует эффективное ограничение скорости).

Однако я бы сказал, что вся идея использования только части пароля для аутентификации глубоко ошибочна: на самом деле она не обеспечивает преимуществ безопасности, которые она должна была использовать, за исключением нескольких особо ограниченных сценариев атак (таких как подслушивающее устройство, которое может наблюдать только одно событие аутентификации и не может просто продолжать попытки до тех пор, пока не получит тот же вызов), но он в основном ослабляет безопасность за счет сокращения объема информации, необходимой для успешной аутентификации. Есть гораздо лучшие решения, такие как TAN, к соображениям безопасности, которые должны адресовать частичная аутентификация по паролю.