Главная Security, Без рубрики, Новое Аутентификация на основе одноразовых паролей: Теоретические основы.
  • Аутентификация на основе одноразовых паролей: Теоретические основы.

    16_1

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

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

    Привычный, ставший стандартным метод – использование долговременных, запоминаемых паролей. Этот способ проверки «правильности» пользователя в рамках современных ИТ-решений должен уйти в прошлое, хотя и имеет место в огромном числе компаний, в силу простоты использования и реализации.

    Тем не менее использование такой аутентификации скорее должно свидетельствовать о незрелости ИТ-инфраструктуры с точки зрения безопасности или об отсутствии потребности бизнеса в построении защищенной информационной системы. Парольная аутентификация потенциально уязвима ввиду использования социотехники, внедрения клавиатурных шпионов, возможности перехвата и т.п. Я специально не касаюсь методов защиты, предлагаемых в рамках операционных систем, поскольку, во-первых, они не обеспечат решение вышеупомянутых проблем, во-вторых, эта тема подробно рассматривалась в статье «Active Directory Domain Services. Двухфакторная аутентификация. Теоретические основы»

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

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

     
    OTP – One Time Password, одноразовый пароль.
    Фактор аутентификации — определенный вид информации, предоставляемый субъектом системе, например, пароль или отпечаток пальца.

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

    Консьюмеризация – тенденция широкого внедрения пользовательских устройств (смартфонов, планшетов) в корпоративную IT-систему.

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

     

    Одноразовые пароли. Терминология. Форм-факторы

     

    Итак, начнем с определений.

    Одноразовые пароли (OTP, One-Time Passwords) – динамическая аутентификационная информация, генерируемая различными способами для однократного использования. Применение одноразового пароля возможно лишь один раз либо в некоторых реализациях в течение незначительного промежутка времени.

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

    Одноразовый пароль (OTP) практически неуязвим для атаки сетевого анализа пакетов, что является существенным преимуществом перед обычными долговременными паролями. Даже если одноразовый пароль будет перехвачен, вероятность того, что им смогут воспользоваться, весьма сомнительна, чтобы ее рассматривать всерьез.

    Еще одним важным преимуществом использования OTP-токенов является то, что они дополнительно требуют от пользователя ввода PIN-кода, например, при активации, генерации OTP, для предъявления аутентифицирующему серверу совместно с OTP. Следовательно, у нас возникает еще один фактор аутентификации, и мы говорим о двухфакторной аутентификации пользователя в системе на основе обладания чем-либо (Authentication by Ownership) и на основе знания чего-либо (Authentication by Knowledge).

    Существуют различные варианты подобных устройств. Это может быть карманный OTP-калькулятор, брелок, смарт-карты, устройство, обеспечивающее двойную функциональность (USB-ключ + OTP), например, SafeNet eToken NG-OTP. Кроме того, может использоваться программное обеспечение, скажем, выполняемое на смартфоне пользователя. Существует целый ряд компаний, выпускающих подобные средства, как программные, так и аппаратные, например, SafeNet, RSA, Gemalto.

      

    Принципы работы

     

    Для генерации одноразовых паролей OTP-токены используют криптографические алгоритмы:

     

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

     

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

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

     

    «Запрос-Ответ» (Challenge-Response)

     

    Рассмотрим принципы работы метода «запрос-ответ» (см. рис. 1):

     

    1

    Рисунок 1

     

    1. Пользователь вводит свое имя на рабочей станции. Имя пользователя передается серверу по сети в открытом виде.
    2. Сервер генерирует случайный запрос.
    3. Этот запрос передается по сети в открытом виде.
    4. Пользователь вводит полученные данные в свой OTP-токен.
    5. OTP-токен шифрует запрос с помощью секретного ключа пользователя, и формируется ответное значение, которое отображается на экране токена.
    6. Пользователь вводит это значение на своей рабочей станции.
    7. Затем ответ передается по сети в открытом виде.
    8. Сервер осуществляет поиск записи пользователя в аутентификационной БД, используя секретный ключ пользователя, шифрует тот же запрос.
    9. Далее сравниваются два значения: полученное от пользователя и вычисленное сервером. При их совпадении аутентификация считается успешной.

     

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

     

    Альтернативным вариантов является метод «только ответ».

    «Только ответ» (Response only)

    В методе «только ответ» OTP-устройство и сервер аутентификации генерируют скрытый запрос, используя значение предыдущего запроса. На первоначальной стадии используется уникальное случайное начальное значение, формируемое при инициализации токена.

    Рассмотрим принципы работы (см. рис. 2).

     

    1

    Рисунок 2

     

    1. Пользователь активирует токен, который отображает ответ на скрытый запрос.
    2. Пользователь вводит свое имя и этот ответ на рабочей станции.
    3. Имя пользователя и ответ передаются по сети в открытом виде.
    4. Сервер находит запись пользователя и генерирует такой же скрытый запрос, шифруя его с помощью секретного ключа пользователя.
    5. Сервер сравнивает ответ, полученный от пользователя, с вычисленным.
    6. При совпадении результатов аутентификация считается успешной.

     

    Синхронизация по времени (Time synchronous)

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

     

    3

     

    Рисунок 3

     

    1. Пользователь активизирует свой токен, который генерирует OTP, зашифровывая показания часов с помощью своего секретного ключа.
    2. Пользователь вводит свое имя и этот OTP на своей рабочей станции. Имя пользователя и OTP передаются по сети в открытом виде.
    3. Сервер находит запись пользователя и шифрует показания своих часов с помощью хранимого им секретного ключа, получая в результате OTP.
    4. Далее сравниваются вычисленный и полученные OTP. При совпадении значений аутентификация считается успешной.

     

    Необходимо учитывать, что такие системы чувствительны к синхронизации времени.

     

    Синхронизация по событию

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

     

    1. Пользователь активирует токен, который генерирует OTP, зашифровывая количество прохождений аутентификаций данного пользователя с помощью своего секретного ключа.
    2. Пользователь вводит свое имя и OTP на рабочей станции.
    3. Эти данные передаются по сети в открытом виде.
    4. Аутентификационный сервер находит запись пользователя и шифрует значения количества прохождений аутентификаций данного пользователя с помощью хранимого секретного ключа, получая в результате OTP.
    5. Далее сравниваются полученные значения, и при совпадении аутентификация считается успешной.

     

    3

    Рисунок 4

     

    В этом варианте проблему представляет ситуация, когда устройство аутентификации «обгонит» сервер, например, при многократном повторном нажатии кнопки генерации OTP на устройстве.

    Характерными представителями таких устройств являются eToken PASS и eToken NG-OTP компании SafeNet.

     

    Типичные атаки и методы борьбы с ними

     

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

    «Человек посередине»

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

    Кража, утеря токена

    Это типичная ситуация, и решением в этом случае будет использование не только одноразовых паролей для аутентификации в системе, но и обязательное применение PIN-кода, то есть переход к двухфакторной аутентификации.

    Подбор PIN-кода

    Такой вид атаки трудно воспринимать всерьез, поскольку решение проблемы лежит на поверхности – блокировка токена при многократном неправильном вводе PIN-кода.

    Извлечение значения секретного ключа из программного аутентификационного токена

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

    Нечестный администратор безопасности

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

    ***

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

    RFID – Radio Frequency Identification (радиочастотная идентификация) — метод автоматической идентификации объектов, при котором посредством радиосигналов считываются или записываются данные.

    В одной из следующих статей мы рассмотрим, как осуществляется внедрение одноразовых паролей на практике, и поговорим о внедрении OTP-технологий для аутентификации в службе каталога Active Directory Domain Services.

     

     

    Статья опубликована в журнале «Системный Администратор» № 9 за 2012 г.

    Леонид Шапиро, MVP, MCT.

Комментарии

  1. Как то не хорошо поступил автор. Чернила на сентябрьском номере журнала еще не остыли, а он уже опубликовал статью на другом ресурсе. Разрешение самага есть?

  2. А договор у журнала с авторами есть? С каких пор его стали заключать?

  3. В http://samag.ru/main/part/5 написано
    При этом редакция получает эксклюзивное право на распространение принятого материала в журнале, включая возможность его публикации в любой электронной форме. Редакция выплачивает авторские гонорары.
    По истечении двух месяцев, а в некоторых случаях всего двух недель, с момента выхода журнала содержащего публикации, автор имеет право опубликовать свой материал в другом месте только с предварительного письменного согласия редакции и с обязательной ссылкой на журнал «Системный администратор».
    По истечении одного года с момента первой публикации автор имеет право опубликовать свой материал в другом месте без предварительного письменного согласия редакции, с обязательной ссылкой на журнал.

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

  4. А на заборе написанно и не такое. И что? Страничка в инете юр. силы не имеет. Получить эксклюзивное право только на основе того, что я так хочу нельзя.
    P/S Про деньги не смешите, проще флаеры раздавать чем статьи писать, больше выйдет. Если кто туда и пишет, то явно не из за денег.

  5. Так почему автор сразу сюда не написал? Не захотел флаеры продавать? Как по мне просто не мужицкий поступок. Есть формальный договор, даже хоть на уровне “пацан сказал, пацан сделал”, он свое слово не сдержал. Интересно мнение самого Шапиро.

  6. Вот даже у Вас внизу “При использовании материалов, ссылка обязательна.” Как то интересно. Отсюда тырить низя, а у других как бэ можно.

  7. Это как раз и есть надпись на заборе. Поверьте, в инете моего контента выложено столько.. и 99% без моего уведомления. Но я реально отношусь к этому и не хожу по блогам с претензиями.
    Лёне, нужны активности для MVP, вот и спешит выкладывать. Сергей, вам какая разница ?

  8. Так, коллеги, насчет моего мнения… Я, пожалуй, действительно немного поторопился. Я проверил требования журнала, там действительно полтора мес., а не мес. Статья выложена 30/09, а сдавал я ее в августе. Надо было подождать недельку перед тем как публиковать ее здесь. В любом случае в редакцию уже направлено мое письмо с объяснением ситуации. Ссылка на публикацию в “Самаге”приводится, так что нарушение договоренностей только в сроке публикации. Тем не менее, впредь буду внимательней к формальным требованиям.

  9. Сергей, не смешите. Развели тут «дискуссию» не по делу! Надо больше всех? Статья вполне сносная.
    Авторы нужны и журналам, тем более известные в узких кругах. Привлечет и рекламу (за известное имя) и новых читателей. Леонида не раз видел на крупных площадках. Все презентации по делу!
    Согласен с Ильей – здесь гонорары смешные, да еще все с претензией Не думаю, что после таких постов авторы захотят работать с журналом (ми), будут здесь публиковать , отвечая в комментариях по делу за решения для ИТ!

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

  11. Сергей, почему публикация статьи здесь у тебя вызвала такую попаболь? Ну опубликовал автор свою статью чуть раньше срока, что теперь? Ну перестань его публиковать. А лучше сразу всех авторов пошли и сам наполняй журнал своими статьями, которые нигде больше публиковать не будешь. Из-за таких людей как ты от Самага начинают отворачиваться читатели и авторы.
    В курилке на сисадминсе есть такой мем, как “Вахтер”. Как показывает практика, вахтерами становятся те люди, которые получили небольшую власть над пользователями (модера дали, ага) и резко ощутили себя “царьками всего мира”.
    Совет на будущее, – “Будь проще и люди потянутся…”

    ЗЫЖ А статейка хорошая для общего развития.

  12. Я перестал писать по следующим причинам:
    1. Процесс согласования статьи иногда превращается в веселуху, человек который вообще слабо разбирается в технологии начинает спорить. В результате все заканчивается “а да действительно так, ну тогда ладно”. Я не готов на подобные споры свое врем тратить.
    2. Статья это две недели вечеров. Мои две недели вечеров стоят гораздо больше 100 баксов.
    3. Я пишу для себя, а когда я пишу для себя, я не буду ждать два месяца, я хочу видеть отзывы и обсуждения сразу.
    P/S Бумажные журналы уже мертвы, некоторые еще это не поняли. То, что сейчас это фантомные боли пройдут 🙂

  13. Я, кстати, об этом тоже давно говорю. Илья 100% прав. Бумажные журналы долго не проживут. Давно пора перейти к электронной версии в качестве основы и бумажной как дополнению.

  14. Илья, Лень, по поводу электронных журналов – Моя позиция такова, если наконец-то в Google.Play введут продажу и подписку на журналы/книги в электронном виде, то я их лучше буду читать на планшетнике, да и цена у электронной версии журналов должна быть соответствующая.
    Кстати, возможно электронную подписку сделает новоявленный сервис от Яндекса (аналог Google.Play) который будет запущен уже скоро…

  15. Интересная дискуссия. Я просто спросил почему человек нарушает договор, даже и вообщем условный. Как по мне это не очень хорошо характеризует любого, пусть даже и “известного в узких кругах”. Автор признал сам что поторопился (и кстати срок отсчитывается не со времени сдачи, а с момента выхода номера), но в итоге все равно оказался виноват я.
    На счет “простоты”, не Вам Inecs меня характеризовать так как в реале мы не знакомы. Те кто меня знает и так считают что я простой дальше некуда, а вот что принципиальный, то да. Но пока это все ставят в +.
    > Бумажные журналы долго не проживут.
    Поверьте мне проживут. Это у человека заложено где то внутри, я знаю многих, которые ждут именно бумажную версию, платят за нее бабулесы, когда на обменниках уже давно лежит скан. И сам я читаю исключительно бумагу, хотя бы потому что от экрана монитора уже тошнит.

  16. Сергей, Вы вполне могли бы спросить меня в приватном порядке, не делая этот разговор публичным, и не обращаясь ко мне в третьем лице, обвиняя, скажем так, в непорядочности. Мои контактные данные не так трудно найти, не так ли? Вряд ли ответ как-то отличался бы от того, что Вы прочитали здесь. Как Вы имели возможность видеть, произошло недоразумение, только и всего. Кроме того, это вопрос моих взаимоотношений с редакцией журнала, и мне не совсем понятно, почему Вас это так задело. Поэтому нагнетать “на ровном месте”, мне кажется, не стоит, тем более, что ссылка на журнал стоит, равно как и в других моих статьях, опубликованных в журнале и размещенных где-то еще.

  17. > вполне могли бы спросить меня в приватном порядке, не делая этот разговор публичным,
    Отвечу вашими же словами
    > В сущности все верно, получается, когда надо что-то публиковать быстро
    Зачем мне искать информацию о человеке и писать ему @ тем более что “мне нужно быть проще” (с) Вот я так и поступил увидел => спросил. Я ж не виноват что прочитаное запоминаю, поэтому помню и статью и правила самага. А вообще здесь есть модератор он может удалить.

  18. 1. Это тут не причем. Относилось к совершенно другой теме. Речь шла о том, что если мы хотим, что-то быстро опубликовать, то правила журналов накладывают ограничения. Я же опубликовал слишком рано, просто по ошибке.
    2. По второму вопросу… это, разумеется, личный выбор. Если бы меня что-то удивило/возмутило и т. п., и я захотел бы пообщаться на эту тему, то разумеется написал бы лично. Кроме того, форма вопроса может быть разная, не так ли?

  19. 1-2. Все так. Но принцип тот же. Увидел неувязку и просто написал где было удобно/быстро. Тем более как писали выше “а мне какое дело”. Модератор вместо того чтобы спорить и переходить на личности, и обвинять во всех грехах меня, мог бы просто удалить сообщение и сказать об этом автору. Так делают на многих сайтах. И для связи с автором есть поле для комментариев.
    Учитывая, что условия нарушены, но статья все еще тут, с самагом вы договорились, а значит можно все это удалять.

  20. Сергей, с Вашей подачи превратили дискуссию в болотце., когда Леонид уже и так все объяснил.

  21. Собственно – статья в тему, кратко и по делу, спасибо.

    Системный администратор – унылый журнал для “велосепедистов”, любящих изобретать то, что уже сто раз изобретено. Удивительно, что туда взяли данную статью, прочитал несколько номеров – своим сотрудникам, очень настоятельно не рекомендую читать, если они хотят чему-то научиться.