Рейтинг:0

Криптография с открытым ключом для входа в систему

флаг ky

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

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

Чтобы замедлить атаку грубой силы, ключ должен быть получен из пароля и соли с использованием медленного KDF, прежде чем генерировать закрытый/открытый ключи.

В качестве альтернативы сервер может потребовать от клиента получить ключ из случайно сгенерированного значения, используя какой-нибудь медленный KDF, прежде чем оно будет подписано, хотя мне это кажется менее идеальным, чем простое замедление получения ключа. Чтобы сэкономить ресурсы сервера при проверке подписи, можно использовать механизм стиля Proof of Work вместо медленного KDF, где клиент должен найти одноразовый номер такой, что hash(randomly_generated_value + nonce) > some_set_difficulty, затем одноразовый номер подписывается и отправляется сервер для проверки. Сервер может даже изменять сложность, например увеличивать сложность для каждой неудачной попытки входа в систему.

Каковы были бы некоторые преимущества и недостатки такой схемы? Я подозреваю, что раскрытие соли при каждой попытке входа в систему будет проблемой.

флаг in
Хотя это сработает, я не вижу преимуществ использования этого по сравнению с использованием медленного алгоритма хеширования, такого как bcrypt?
Manish Adhikari avatar
флаг us
Использование пароля + хорошего PBKDF для шифрования вашего закрытого ключа и его хранения в безопасном месте, как в SSH, делает по сути то же самое, не подвергая вашу соль потенциально небезопасной сети. Было бы лучше хранить его в надежном месте, к которому вы можете получить доступ через безопасную сеть, и использовать его для аутентификации на этом сервере по небезопасному каналу.
Maarten Bodewes avatar
флаг in
Одна из проблем заключается в том, что генерация закрытого ключа из любого случайного начального числа чрезвычайно нетривиальна. Если вы никогда не меняете детерминированный алгоритм, то все в порядке, но это означает, что 1. RNG не меняется, 2. извлечение битов никогда не меняется, 4. генерация ключа не меняется и 4. что биты извлекаются из ГСЧ всегда одним и тем же способом. Некоторые из них могут показаться тривиальными, но помните, что, например. Для генерации пары ключей RSA требуется 2 случайных простых числа, и существует множество способов их создания.

Ответить или комментировать

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