Contents of this directory is archived and no longer updated.

Остальные материалы цикла:


КДПВДанная серия постов заказана и оплачена благотворительным фондом винниклОлега Крылова и всех-всех-всех.

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

Password-based authentication background

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

  • Пароли очень короткие (5-8 символов);

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

  • Пароли забываются;

Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:

  • Пароли записываются на бумажки и приклеиваются на монитор;

Я думаю, что многие администраторы с таким встречались. Поскольку наши пользователи очень современны, они часто обитают на различных интернет-ресурсах, форумах, чатах и прочих социальных сетях. Чтобы не сильно забивать себе голову паролями:

  • Один и тот же пароль используется для множества сетевых ресурсов одновременно;

Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).

Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.

Introduction to certificate-based authentication

Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.

Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.

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

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

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

Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number). Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.

Где можно применять аутентификацию пользователей по сертификатам?

В Microsoft Windows мы можем применять пользовательские сертификаты для:

  • Интерактивного логона в домен (требуется смарт-карта);
  • Логона на сервер терминалов при помощи Remote Desktop (требуется смарт-карта);
  • Аутентификации на веб-странице;
  • Аутентификации в VPN;
  • Аутентификации в 802.11х сетях (они же wireless).
  • Аутентификации в ActiveSync;
  • и ещё по мелочам.

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


Share this article:

Comments:

Alexander Trofimov
Alexander Trofimov 22.01.2012 21:57 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

1) ну я же правильно понимаю, что это только начало? =) 2) •Пароли очень короткие (5-8 символов) это не короткий пароль. Это вообще не пароль при нынешних вычислительных мощностях. Особенно, если как-то получен hash.

Oleg Krylov
Oleg Krylov 23.01.2012 07:42 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

Ну начало положено, это хорошо. Теперь "озвучить в комментариях": Я вместо "секретного текстового файлика" давно использую утилиту KeePass (http://keepass.info/). Из плюсов: 1. База данных, шифрованная. 2. Встроенный генератор паролей по гибко задаваемым условиям. 3. Возможность хранения базы на съемном носителе. 4. Аутентификация при помощи сложного мастер-пароля и\или аккаунта пользователя и\или файла-ключа, который так же может храниться (не может, а должен, естественно) на съемном носителе. Из минусов: Пока не встречал, но это же все субъективно, правда? ;)

Vadims Podāns
Vadims Podāns 23.01.2012 08:30 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

Саша, я с тобой совершенно прав. Я здесь не говорю о том, что вместо паролей следует использовать кодовые фразы (отрывок из любимого стихотворения, например) и всё такое, я говорю за объективную реальность. Олег, я пробовал себя приучить к keepass какое-то время назад. Но ничего не вышло.

Vadim Sterkin
Vadim Sterkin 23.01.2012 12:18 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

Вадимс, а что помещало приучиться к KeePass? По-моему, очень удобная программа, хотя я даже не использую многочисленные плагины.

Vadims Podāns
Vadims Podāns 23.01.2012 13:03 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

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

dant
dant 27.01.2012 05:27 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

Для локального хранения паролей с давних времен использую софтинку Pins в dropbox-е и на карманной флэшке. Утилитка очень маленькая, простенькая и удобная : ) http://www.mirekw.com/winfreeware/pins.html Более современные аналоги а-ля keepass-ы смотрел, но как-то не прижились. Для нелокального хранения паролей сервис http://lastpass.com очень интересен. Не храню там только критичные и важные пароли типа гмейла, яндекса, платежных систем итд. А всякому остальному малокритичному вебу - там самое место : )

greeneer.myopenid.com
greeneer.myopenid.com 25.12.2012 14:25 (GMT+3) Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов (акт первый)

Пару лет назад я записывал пароли в Excel'е. Потом надоело, начал искать альтернативы. С Keepass я тоже не подружился. Потом попробовал Roboform. Она позволяет не только хранить пароли в зашифрованном виде, но и синхронизировать их между различными устройствами. Кроме того, она способна автоматически их подставлять на веб-сайтах, остается только нажать кнопку вход и все! Потихоньку все пароли перекочевали туда. 2 года покупал лицензию на эту программу. А вот полгода назад я открыл для себя lastpass. Чудесная штука, ещё лучше roboform, и при этом бесплатная. Устанавливается просто как расширение для любого браузера (на сегодняшний день все популярные браузеры это поддерживают). Можно быстро установить где угодно, просто добавив расширение в браузер. Сейчас я не понимаю, как можно обходиться без этой программы. Когда вижу юзеров, судорожно набирающих или копирующих и вставляющих пароли в веб-формы, мне их жаль. Ведь потратив 15 минут на освоение этой программки, можно экономить эти 15 минут ежедневно.

Comments are closed.