Веб-аутентификация с использованием PKI-сертификатов

Я достаточно хорошо понимаю PKI с концептуальной точки зрения - т.е. частные ключи / открытые ключи - математика, стоящая за ними, использование хэша и шифрования для подписи сертификата, цифровая подпись транзакций или документов и т. Д. Я также работал над проектами, в которых openssl Библиотеки C использовались с сертификатами для обеспечения связи и аутентификации. Я также очень хорошо знаком с инструментами командной строки openssl.

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

Требования

Это сайт для банка. Всем пользователям интернет-банка разрешается использовать любой сертификат, выданный несколькими известными центрами сертификации (verisign, Thawte, entrust и т. Д.). Банк не несет ответственности за приобретение сертификатов для пользователя. Эти сертификаты будут использованы для аутентификации на сайте банка. Платформы / ОС и т. Д. Все еще не исправлены.

дизайн

Мне было интересно, что является лучшим способом сделать аутентификацию.

1. Я видел, что у Apache есть способ включить двухсторонний ssl - в этом случае, я думаю, что переход на веб-сайт автоматически запросит сертификат у пользователя. Но я не уверен, что этого достаточно, потому что кажется, что он проверяет только то, подписан ли сертификат доверенным центром сертификации, а также может ли он попасть в белый список строк темы сертификатов и т. Д. Но этого недостаточно. для банковского дела, потому что вы должны иметь возможность связать идентификатор пользователя банка с сертификатом.

2. Кажется, у IIS есть способ, которым я могу сохранить сертификат для каждого пользователя в Active Directory. Это то, что я понял, прочитав несколько статей MSDN. Вы включаете двухсторонний SSL в IIS, а затем, когда пользователь пытается перейти на веб-сайт, IIS отправит браузеру запрос со списком утвержденных центров сертификации, а браузер позволит пользователю выбрать соответствующий сертификат из своего хранилища сертификатов и отправит его. бэкэнд Я предполагаю, что IIS сделает 2 вещи

   • Убедитесь, что у пользователя есть закрытый ключ, соответствующий сертификату (путем переговоров прикрытия)
   • На основе сопоставления сертификатов пользователей AD IIS сообщит имя пользователя приложению.

3. Сделайте простоту аутентификации, вызывая криптографические функции, в зависимости от того, какой веб-сервер это делает.

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

Мне было интересно, какой метод обычно используется? Каковы лучшие практики? Если я должен пойти с # 3, каковы лучшие способы сделать это?

То, что также может легко работать с приложениями для смартфонов, станет дополнительным бонусом.

Обновить

Позвольте мне прояснить мое утверждение «закодировать часть аутентификации самостоятельно», потому что некоторые ответы, кажется, указывают на то, что это было неправильно понято - мой недостаток в том, что я не ясен.

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

Хотя я действительно хотел ответить на вопрос за вопросом, я думаю, что попаду в эту тему по теме:

Авторизация / аутентификация

ОК, обо всем по порядку. Для вашего примера вам нужны оба:

• Аутентификация - доказательство того, что пользователь является тем, кем он говорит. Вы выбрали PKI с подразумеваемым подтверждением секретного ключа в качестве вашей аутентификации.
• Авторизация - подключение пользователя к тому, что ему разрешено делать. Это точка соединения между входом в систему и получением доступа к разрешенным учетным записям. Сопоставление сертификата с учетной записью и возможностями доступа к учетной записи - это авторизация.

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

SSL, аутентификация клиента / сервера, подтверждение закрытого ключа

Протокол SSL всегда включает проверку подлинности сервера с дополнительным необязательным параметром для авторизации на стороне клиента. Вы правы с # 1 в том, что Apache предлагает параметр, который добавляет аутентификацию клиента с помощью PKI, и вы можете предоставить ему список доверенных CA. Во время настройки сеанса SSL, который требует аутентификации клиента через PKI - вы получите подтверждение закрытого ключа.

Это обеспечит либо опция № 1, либо опция № 2 - и Apache, и IIS могут быть настроены таким образом. Наилучшая практика, я бы предпочел любой вариант, если бы вы катали собственное решение. № 3 опасно близок к правилу «не пиши крипто». Предполагая, что вы можете связать свою транзакцию с наличием аутентифицированного сеанса SSL, нет никаких оснований накатывать свою собственную.

Кроме того, либо в варианте № 1, либо в варианте № 2 есть способ получить в свое распоряжение весь сертификат и оттуда любую его часть. Обычно Subject DN и / или серийный номер сертификата используются для определения личности пользователя в целях авторизации.

С точки зрения «общего использования» - все основные веб-серверы довольно распространены. IIS, Apache, Tomcat и многие другие могут быть настроены с помощью аутентификации клиента SSL. Решение оттуда в значительной степени основано на общей реализации. На всех основных веб-серверах есть способы получить доступ к сертификату, предоставленному в сеансе SSL, что необходимо для более подробной проверки.

Дополнения проверки сертификата

Как минимум, вам необходимо:

• настроить сеанс SSL
• получить сертификат (большинство веб-серверов проверяют подпись сертификата и подтверждение секретного ключа)
• проверить срок действия сертификата (не указан ни на одном веб-сервере)
• выполнить проверку авторизации, для каких учетных записей этот сертификат может получить доступ

Учитывая высокие банковские ставки, вы также можете проверить статус отзыва сертификата - в случае утери или кражи закрытого ключа пользователя его сертификат следует отозвать.

У IIS могут быть зацепки для проверки OCSP или CRL - это, как правило, более всеобъемлющая (рука держится!) Система, но я не помню, чтобы она была в моей голове. Я также не помню, заставит ли это вас использовать продукты Microsoft для этого. Для Apache вам почти наверняка придется кодировать или добавлять проверку OCSP / CRL. Я полагаю, что во время установления сеанса SSL он имеет хуки - обычно эта проверка выполняется один раз при настройке сеанса SSL.

авторизация

На # 1 против # 2 - вы правы, что IIS имеет некоторые встроенные функции, которые свяжут сертификат, предоставленный в сеансе SSL, с хранилищем AD. Это один из случаев, когда Microsoft делает все возможное, чтобы упростить покупку и использование большего количества своих продуктов. :) Существуют нюансы того, как IIS связывается с AD, которые выходят за рамки этого вопроса и не поддаются моему непосредственному воспоминанию. Я сделал довольно сумасшедшие вещи с IIS и AD, и моя общая мысль заключается в том, что хотя вы делаете что-то относительно простое, например, извлекая имя пользователя на основе сертификата из репозитория AD, вы, вероятно, в порядке. Когда вы сталкиваетесь с более сложными проблемами хранения данных, странным поиском в AD и особенно сумасшедшими (но законными) вещами с PKI, вы '

Даже с IIS - вам нужно что-то добавить в свою структуру AD или где-то еще, привязав имя пользователя к банковскому счету. Как правило, в банковской сфере, пользователь имеет несколько учетных записей. И 2 пользователя могут иметь общую учетную запись, так что это отношения многих ко многим.

Для # 1 - да, вам нужно написать свой собственный поиск. Вам необходимо кодировать: - базу данных или иерархию LDAP, соединяющую сертификат с пользователем и пользователя с банковскими счетами пользователя. Гарантированная уникальная часть сертификата - серийный номер + DN эмитента. Часто Subject DN будет работать, но это не гарантируется во всех системах PKI.

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

Это звучит как смесь № 1 и № 3 - мой сильный совет - использовать собственные возможности любого приложения / веб-сервера, который вы используете для генерации сеанса SSL. Это позволит настроить браузер на сервер с запросом сертификата стандартным, наилучшим образом. Оттуда, с Apache, вам нужно будет запустить собственную систему авторизации. IIS предоставит Microsoft представление о том, как это должно работать для вас.

Известные Gotchas

Сделайте кучу тестирования браузера. Из года в год, от браузера к браузеру, я нахожу ошибки с обработкой сеансов SSL. Правильное связывание сеанса SSL с серией запросов веб-страниц и обеспечение правильной обработки выхода из системы - это самые большие проблемы. И это во многом связано как с сервером, так и с программным обеспечением браузера. SSL достаточно стабилен, поэтому, когда он работает, он обычно работает, хотя могут быть проблемы IE и всех остальных.

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

Смартфоны

Хорошо. Удача. это все, что я могу сказать. Я вовсе не являюсь разработчиком мобильных приложений, но до сих пор у меня сложилось впечатление, что в среднем смартфоне обработка сертификатов PKI не отвечает требованиям или не существует.

Я бы так хотел быть неправым.

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

но там, где это не удается

• Стоимость за сертификат
• совместимость с современными браузерами
• конечные пользователи извлекают сертификаты и хранят закрытые ключи небезопасно

Имейте в виду, что современные персональные сертификаты с подписью sha-2 не работают с Safari на iPad и во многих современных браузерах. Это потому, что личные сертификаты никогда не снимались так, как думали организации по сертификации. Выпуск 30000 сертификатов (что мы делаем) стоит примерно столько же на каждый сертификат, сколько некоторые типы аппаратных токенов.

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

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

Далее, позвольте мне настоятельно рекомендовать вам не кодировать собственную процедуру аутентификации. Есть много отличных, проверенных библиотек, которые справляются с этим. Вы сохраните ошибки функциональности и безопасности, запустив зрелую библиотеку для аутентификации. Использование проверенной, зрелой библиотеки для этого определенно будет лучшей практикой.

Следующая лучшая практика - использование каталога для обработки вашего клиента: сопоставление сертификатов. Так что вы будете смотреть на AD или LDAP. Как вы упомянули, Windows и IIS делают это довольно легко для вас. IIS.net имеет хорошее краткое изложение по настройке сопоставления сертификатов в IIS .

Если вы катитесь с Apache, это не так просто из коробки. Похоже, что mod_authz_ldap выполняет сопоставление клиентских сертификатов, но я лично с ним не работал.

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

Я бы посмотрел, что Google и Facebook делают для настройки файлов cookie для доверенных устройств, чтобы избежать двухфакторной. Я хотел бы иметь новые устройства аутентификации с двухфакторной, прежде чем разрешить аутентификацию только для сертификатов.

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

На самом деле это сводится к следующему: откуда я знаю, что могу доверять тому, что сертификаты пользователей не были скомпрометированы, и как я могу доверять тому, что я могу сопоставить сертификат X с пользователем Y.