Какие части сертификата клиента использовать при уникальной идентификации пользователей? - PullRequest
26 голосов
/ 13 марта 2011

Я разрабатываю систему, в которой пользователи смогут регистрироваться и впоследствии проходить аутентификацию с помощью клиентских сертификатов в дополнение к аутентификации по имени пользователя / паролю.

Сертификаты клиента должны быть действительными сертификатами, выданными настроенным списком центров сертификации, и будут проверяться (проверяться) при их представлении.

На этапе регистрации мне нужно сохранить часть (и) клиентского сертификата в хранилище пользователя (DB, LDAP и т. Д.), Чтобы я мог сопоставить пользователя, который проходит аутентификацию с помощью сертификата клиента, с внутренним «пользователем».

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

RFC 2459 определяет (4.1.2.2), что серийный номер сертификата должен быть уникальным в пределах данного CA.

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

Я что-то пропустил?

Ответы [ 3 ]

21 голосов
/ 13 марта 2011

У вас есть несколько решений:

  1. Хранение отпечатка пальца. Да, вы правы, столкновение теоретически возможно, но вероятность действительно очень мала, и вы можетеУчтите, что этого не происходит: 2 пользователя в вашей системе не будут иметь случайно одного и того же отпечатка сертификата.Однако алгоритмы хеширования со временем ослабевают, и злоумышленник может попытаться подделать сертификат, отпечаток которого совпадает с зарегистрированным.Эта атака называется атакой второго прообраза, и ее довольно сложно выполнить, поскольку злоумышленник не пытается подделать некоторые случайные данные, соответствующие отпечатку пальца, а настоящий сертификат X.509, который может пройти начальную фазу проверки (т.е. взломать PKI).Довольно сложно :) Но если вы действительно хотите защитить себя от столкновения, вы можете сохранить 2 отпечатка пальца с помощью двух разных алгоритмов (например, SHA-1 и SHA-256).

  2. Хранениеиздатель сертификата и серийный номер. Да, его можно использовать как уникальный идентификатор сертификата.Как вы писали, стандарт ( RFC 5280 устарел RFC 2459) указывает [The serial number] MUST be unique for each certificate issued by a given CA. Однако это также означает, что при обновлении сертификата серийный номер изменяется с момента выдачи СА нового сертификата.

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

1 голос
/ 18 мая 2011

Лучший способ однозначно идентифицировать пользователя по адресу электронной почты. В процессе регистрации действительный адрес электронной почты должен быть обязательным. Затем вы связываете серийный номер сертификата и издателя или, возможно, хэш самого сертификата с электронной почтой и идентификатором пользователя. Затем, когда срок действия сертификата истекает или пользователь меняет сертификат, у него / нее будет «ссылка на обновление сертификата», где он вводит адрес электронной почты и получает ссылку для загрузки нового сертификата. Затем вы можете заменить старый серийный номер / издатель новым.

0 голосов
/ 28 июля 2017

Я решил объединить имя эмитента, разделитель | и DN.

Надеюсь, это решает проблему использования серийных номеров, которые меняются при обновлении.

...