Назад | Перейти на главную страницу

HTTP-аутентификация с парой открытого / закрытого ключей

Я ищу способ аутентификации клиентов / пользователей на веб-сервере с парами открытого / закрытого ключей и уже прочитал этот вопрос: Аутентификация с открытым ключом или аналогичный по HTTP / HTTPS? Ответы похожи на все, что я нашел в Интернете. Коротко: "Если вы хотите аутентификацию с открытым ключом через HTTPS, используйте сертификаты клиента SSL".

Однако я ищу решение, столь же простое и безопасное, как аутентификация SSH с общедоступными / закрытыми ключами. Моя проблема с сертификатами клиентов SSL заключается в том, что вам нужен CA, и это имеет большое значение с точки зрения безопасности, imho.

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

Итак, в заключение я должен убедиться, что мой ЦС защищен, и лучший способ - иметь выделенную систему / компьютер, выступающий в качестве ЦС. Это означает значительно более высокие усилия и более высокие затраты.


Что касается безопасности, я считаю спорным, какой механизм лучше. Но я думаю, что если аутентификации с открытым ключом достаточно для доступа по SSH, она также должна применяться к аутентификации веб-приложений. Также обратите внимание, что я хочу использовать открытый / закрытый ключ только как дополнение к моей существующей базовой HTTP-аутентификации (пользователь / пароль), чтобы повысить безопасность. Фактически, моей целью было повысить безопасность вторым фактором с минимальными усилиями и без необходимости использования генераторов токенов.

Как взаимная аутентификация предоставленный Безопасность транспортного уровня (TLS) по-прежнему в аутентификация с открытым ключом для HTTPS (ситуация не изменилась с тех пор, как в 2011 году был задан другой вопрос), здесь нет необходимости в SSH-подобном решении, описанном здесь. Следовательно, такого продукта / решения не существует, и вы не должны разрабатывать свой собственный. То, что применимо к криптографии в целом, также применимо к криптографической аутентификации: вы не должны изобретать ее самостоятельно, поскольку она будет слабой.

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

Затраты не обязательно «значительно выше», поскольку любой старый компьютер может работать как автономный центр сертификации. И дело не в дорогих лицензиях на программное обеспечение, как, например, GNU / Linux с OpenSSL CA - это все, что вам нужно.