19.06.2017 10:52
EminH 4 1000 Источник
В этой статье мы хотим рассказать о нашем продукте TOTPRadius. Это RADIUS сервер, спроектированный для применения в системах двухфакторной аутентификации. Помимо стандартного для этого протокола фунционала, TOTPRadius предоставляет несколько дополнительных функций, одной из которых является возможность организации самостоятельной регистрации второго фактора для рядовых пользователей

RADIUS для двухфакторной аутентификации


RADIUS — это стандартный протокол принятия и обработки запросов проверки подлинности. Помимо обычной (однофакторной) аутентификации, многие системы используют протокол RADIUS для двухфакторной аутентификации, чаще всего для проверки подлинности второго фактора. Принцип довольно простой: если взять в качестве примера алгоритм TOTP, в котором для генерации одноразового пароля (one-time password- OTP) используется текущее время и секретный ключ, то OTP, введенный пользователем, передается RADIUS серверу, который, в свою очередь, и проверяет его подлинность. Конечно, и секретный ключ и текущее время должны совпадать с генератором OTP. RADIUS для двухфакторной аутентификации используется, например, в VMWare View/Horizon, Citrix NetScaler, Fortinet VPN и др.

Самостоятельная регистрация и зачем она нужна


Очень часто возникает необходимость предоставить пользователям возможность активировать второй фактор самостоятельно. Стандартные реализации такой возможности не дают, и это понятно: в обычной имплементации двухфакторной аутентификации она или есть, или ее нет, третьего не дано. Это может привести к сложностям — например, при миграции большого количества пользователей регистрация второго фактора должна быть централизована. В случае, если используется софт-токен (например, приложения типа Google Authenticator или Token2 Mobile OTP) на персональных мобильных устройствах, логистику миграции даже сложно себе представить.
В этом случае может помочь самостоятельная регистрация. Идея такая: пользователям без активного второго фактора (иными словами, без записи в базе данных сервера RADIUS) пускать в систему один раз (ну или два, если допускать возможность что в первый раз что-то может пойти не так) – и далее предоставить им возможность самостоятельно запустить процесс регистрации второго фактора (создания профиля TOTP в приложении). Token2 TOTPRadius представляет возможность организовать такую регистрацию через простой RESTful API. В упрощенном виде, это запрос в формате 
https://Адрес-Сервера/api?username=[имя_пользователя]&api-key=[ключ-для-подключения]
где ответом от сервера при успешном выполнении запроса будет сгенерированный для данного пользователя секретный ключ в текстовом и QR-code формата.

Пример интеграции: TOTPRadius с Citrix NetScaler + Storefront


Связка Citrix Netscaler + Storefront применяется для осуществления доступа к продуктам Citrix XenApp и XenDesktop. NetScaler из коробки поддерживает использование RADIUS сервера в качестве источника аутентификации второго фактора. Дополнительной интеграцией в данном случае будет только реализация самостоятельной активации TOTP профиля софт-токена в интерфейсе Storefront посредством RESTful API. Процесс подключения довольно прост и описан в этом документе. Как это выглядит глазами конечного пользователя показано на видео:


Дополнительные возможности


Помимо готовых скриптов интеграции со Storefront, TOTPRadius также легко интегрируется с Wordpress и Drupal (с использованием плагинов Token2). Мы будем также рады помочь с интеграцией с любыми другими системами.
TOTPRadius можно использовать и без функции cамостоятельной регистрации, если она вам не нужна (или невозможна)
Преимущества TOTPRadius будут и в этом случае, а именно:
— поддержка как аппаратных, так и софт-токенов TOTP
— возможность автоопределения и корректирования дрифта (смещения времени) аппаратных токенов
— импорт и экспорт списков пользователей в формате CSV
— подробные журналы попыток аутентификации


Спасибо за внимание!
Поделиться с друзьями
-->

Комментарии (4)


  1. nmk2002
    20.06.2017 19:29
    #10274238

    У вас по ссылке на сайт путаница с RFC:

    RFC-2865 algorithm (TOTP: Time-Based One-Time Password Algorithm)

    На самом деле номер RFC на TOTP — 6238.

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

    Нужно ли создавать пользователей заранее вручную или они создаются на лету?
    Еще вопрос: делаете ли вы автоматическую подстройку времени на сервере для каждого пользователя при каждой аутентификации?

    Ну и позанудствую: не люблю когда seed передается/отображается в открытом виде. Лучше бы проводить активацию через ссылку с одноразовым кодом активации. Eсли seed попал в этот момент к злоумышленнику, то он сможет без проблем генерировать TOTP в любом времени в будущем и все они будут валидными. Обычно я рекомендую использовать HOTP, вместо TOTP, чтобы одного знания seed было бы недостаточно для генерации одноразового пароля.


    1. EminH
      20.06.2017 20:26
      #10274336

      Спасибо за отзыв, RFC сейчас поправим.

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

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

      На лету если с помощью REST API. А так можно и вручную, и импорт CSV.
      Еще вопрос: делаете ли вы автоматическую подстройку времени на сервере для каждого пользователя при каждой аутентификации?

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

      От TOTPRadius передается зашифрованным. Если имеется в виду фаза передачи ключа конечному пользователю, то и там риск не такой большой: например в том же StoreFront для отображения seed-a пользователь должен быть залогинен с AD credentials. На нашем облачном сервисе используется SMS активация, но TOTPRadius пока этого не предоставляет.
      рекомендую использовать HOTP, вместо TOTP

      Эта статья о продукте заточенном именно под TOTP. И вы, наверное, согласитесь что TOTP гораздо проще внедрять.


      1. nmk2002
        20.06.2017 21:18
        #10274414

        Спасибо за подробный ответ.

        Если имеется в виду фаза передачи ключа конечному пользователю, то и там риск не такой большой: например в том же StoreFront для отображения seed-a пользователь должен быть залогинен с AD credentials.

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

        И вы, наверное, согласитесь что TOTP гораздо проще внедрять.

        Интересно было бы услышать аргументы против HOTP. Мне на ум приходят только вопросы пересинхронизации, но и тут есть свои плюсы и минусы.


        1. EminH
          20.06.2017 21:41
          #10274448

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