Обработать вход пользователя с использованием асимметричной криптографии

Question

Возможно ли реализовать протокол входа в систему с асимметричной криптографией вместо метода хеширования пароля?

Например, при создании учетной записи клиент создает пару частного/открытого ключа из хэша имени пользователя и пароля. Открытый ключ затем отправляется на сервер с именем пользователя, а сервер сохраняет имя пользователя и открытый ключ. Когда пользователь хочет войти в систему, он вводит свой пароль, клиент восстанавливает закрытый ключ, подписывает с ним nonce и отправляет подписанное сообщение на сервер. Затем сервер может аутентифицировать пользователя, поскольку он знает открытый ключ, связанный с именем пользователя.

Есть ли недостатки в этом протоколе?

И каковы были бы преимущества перед хранением пароля хэша?

Answer 1

Возможно, существует серьезный недостаток аутентификации, да, в зависимости от реализации. Если Боб - это сервер, а Алиса - клиент, а Мэллори - злонамеренный подслушиватель:

Если Алиса генерирует случайное число, объединяет это с ее именем пользователя, зашифровывает его своим личным ключом и отправляет на сервер. Сервер расшифровывает и проверяет открытый ключ Алисы. Без сервера, сохраняющего случайное число, это восприимчиво к повторным атакам - Мэллори мог просто прослушать, сохранить блоки, которые Алиса отправляет на сервер, и просто повторить их позже. Без их сохранения сервер не был бы более мудрее.

Чтобы защитить сервер от этого, серверу пришлось бы генерировать случайное число. Это также должно быть безопасным случайным числом, в противном случае Мэллори может предсказать или, по крайней мере, угадать, каким будет следующий номер.

Если Мэллори может перехватывать сообщения, то он может претендовать на роль Алисы - он перехватывает все сообщения и просто передает их, даже если сервер генерирует случайное число.

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

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