HTTP-аутентификация с парой открытого / закрытого ключей
Я ищу способ аутентификации клиентов / пользователей на веб-сервере с помощью пар открытых / закрытых ключей и уже прочитал этот вопрос: Аутентификация с открытым ключом или что-то подобное по HTTP / HTTPS? Ответы похожи на все, что я нашел в Интернете. Вкратце: «Если вы хотите аутентификацию с открытым ключом через HTTPS, используйте SSL-сертификаты клиентов» .
Однако я ищу решение, такое же простое и безопасное, как аутентификация SSH с общедоступным / частным ключи. Моя проблема с сертификатами клиентов SSL заключается в том, что вам нужен CA, и это имеет большое значение с точки зрения безопасности, imho.
Вот почему: если злоумышленники украдут закрытый ключ вашего CA, они смогут пройти аутентификацию с помощью любой пользователь, потому что он может подписывать свои собственные клиентские сертификаты. В случае SSH, если злоумышленники украдут закрытый ключ пользователя, они смогут аутентифицироваться только как этот единственный пользователь.
Итак, в заключение я должен убедиться, что мой CA защищен и лучший способ - это иметь выделенную систему / компьютер, служащий CA.Это означает значительно большие усилия и более высокие затраты.
Что касается безопасности, я считаю спорным, какой механизм лучше. Но я думаю, что если аутентификации с открытым ключом достаточно для доступа по SSH, она также должна применяться к аутентификации веб-приложений. Также обратите внимание, что я хочу использовать открытый / закрытый ключ только как дополнение к моей существующей базовой HTTP-аутентификации (пользователь / пароль), чтобы повысить безопасность. На самом деле, моей целью было повысить безопасность во второй раз с минимальными усилиями и без необходимости использования генераторов токенов.
Поскольку взаимная аутентификация, обеспечиваемая Transport Layer Security (TLS), по-прежнему является аутентификацией с открытым ключом для HTTPS ( ничего не изменилось с тех пор, как в 2011 году был задан другой вопрос), нет необходимости в SSH-подобном решении, описанном здесь. Следовательно, такого продукта/решения не существует, и вам не следует разрабатывать свой собственный. То, что относится к криптографии в целом, относится и к криптографической аутентификации: вам не следует изобретать ее самостоятельно, так как она будет слабой.
- Брюс Шнайер: Любители создают любительскую криптографию
- Джозеф Кокс: Почему вы не запускаете собственную криптографию
- Информационная безопасность SE: Зачем? Можем ли мы создать собственный?
Проблемы, которые вы описываете при внедрении собственного ЦС, не решаются при аутентификации с помощью открытого ключа SSH. Если у кого-то есть доступ к конфигурации, можно добавить свои ключи и выдать себя за пользователя. На самом деле аутентификация на основе ЦС лучше, так как позволяет подписывать сертификаты вне приложения, в котором они используются. Поверхность атаки с отдельным сервером ЦС (возможно, полностью отключенным) значительно меньше. Клиент упустит ключ (в обоих сценариях) с гораздо большей вероятностью, чем ЦС будет скомпрометирован.
Затраты не обязательно «значительно выше», так как любой старый ПК может работать как автономный центр сертификации. Это также не вопрос дорогих лицензий на программное обеспечение, как, например. GNU/Linux с OpenSSL CA — это все, что вам нужно.