[FATHER_FBI]

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

Если кто сталкивался с этим, можете рассказать что это такое и с чем его едят. Смотрел цены на токены, они вообще очень вкусные

Допустим куплю я пачку этих ключей, как мне их связать например со своей Cisco ASA?

[s.lobanov]

У меня такой был на прошлой работе. Очень неудобно, выложил его из кармана при стирке, забыл потом положить и всё, ты без vpn-а. Или не пользуешься какое-то время и префикс забываешь. Пароль + смс намного удобнее.

[nuclearcat]

Там нюансы с ключиками.

http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-compromised/

 

Можно подобный брелок сделать свой, совместимый с открытыми стандартами.

Или же поставить Google Authenticator на мобилку и не парится, но это ненадежно, если мобилку хакнут.

[FATHER_FBI]

У меня такой был на прошлой работе. Очень неудобно, выложил его из кармана при стирке, забыл потом положить и всё, ты без vpn-а. Или не пользуешься какое-то время и префикс забываешь. Пароль + смс намного удобнее.

Дык вот как раз и подумываю что бы реализовать для VPN-а, что бы не заставлять пользователей раз в квартал менять пароль, а сделать связку пароль+RSA, по факту у пользователя пароль будет меняться каждые 60 секунд.

 

Там нюансы с ключиками.

http://arstechnica.c...is-compromised/

 

Можно подобный брелок сделать свой, совместимый с открытыми стандартами.

Или же поставить Google Authenticator на мобилку и не парится, но это ненадежно, если мобилку хакнут.

Вся засада в том что с этим RSA вся херня работают, почему то на них все ровняются, начиная от игр, windows и заканчивая ентерпрайз решениями.

[orlik]

У меня оно установлено в виде апликухе на телефоне, очень удобно

 

Есть и российские аналоги кстати

[Sergey Gilfanov]

Или же поставить Google Authenticator на мобилку и не парится, но это ненадежно, если мобилку хакнут.

По идее, должно решаться авторизацией клиентский сертификат + пароль из генератора. Сертификат - в компе, который VPN поднимает. Пароль - из генератора в мобилке. Тогда хакать придется и комп (потом еще сертификат добывать) и мобилку.

[s.lobanov]

Sergey Gilfanov

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

[jffulcrum]

Если на картинке именно OTP-генератор, то там очень жесткие требования по синхронизации времени для аутентификационного сервиса. В токене свой кварц, а у тебя в сети должен быть либо спутниковый девайс, либо очень хороший Интернет для синхронизации по NTP (и не с time.windows.com). Бывает весело, когда контроллер домена и/или сервис RSA в виртуальной машине - в ней время может достаточно сильно "плавать" и как результат - несовпадение с временем токена - все разом остаются без доступа.

 

Ставится сервис RSA на сервер (для всех ОС есть), Cisco прикручивается через RADIUS с кастомным атрибутом.

[Sergey Gilfanov]

Если на картинке именно OTP-генератор, то там очень жесткие требования по синхронизации времени для аутентификационного сервиса.

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

[Night_Snake]

У нас такое было, токены были программные. В принципе, это даже удобно, но смс выходит дешевле, т.к. за RSA токены надо платить ежегодно.

[Sergey Gilfanov]

т.к. за RSA токены надо платить ежегодно.

Мне лень проверять - а за что, собственно? В них свой ключик от своего центра авторизации залить нельзя что ли?

[Night_Snake]

Мне лень проверять - а за что, собственно? В них свой ключик от своего центра авторизации залить нельзя что ли?

Вы не поняли.

SecureID, вообще, протокол открытый (вплоть до алгоритма генерации ключей).

Но конкретная реализация от RSA (поддержка серверной части и клиентских токенов) стоит определенных денег.

[Sergey Gilfanov]

Но конкретная реализация от RSA (поддержка серверной части и клиентских токенов) стоит определенных денег.

Клиентские токены - их поддерживать не надо. Они автономные. Про серверную часть - согласен. Если она - у них. А свою сделать - не дают?

[nuclearcat]

Дык вот как раз и подумываю что бы реализовать для VPN-а, что бы не заставлять пользователей раз в квартал менять пароль, а сделать связку пароль+RSA, по факту у пользователя пароль будет меняться каждые 60 секунд.

http://lifehacker.com/the-best-two-factor-authentication-app-for-android-1638791349

 

Вся засада в том что с этим RSA вся херня работают, почему то на них все ровняются, начиная от игр, windows и заканчивая ентерпрайз решениями.

Знаете фразу: "миллионы мух не могут ошибаться"?

[Sergey Gilfanov]

http://lifehacker.com/the-best-two-factor-authentication-app-for-android-1638791349

К тому списку добавлю Authenticator Plus

[Night_Snake]

Клиентские токены - их поддерживать не надо. Они автономные. Про серверную часть - согласен. Если она - у них. А свою сделать - не дают?

На сервере есть ограничение на количество поддерживаемых токенов. Свыше лицензированного просто не получится зарегистрировать. Серверная часть ставится у вас, разумеется. Но - опять же от RSA.

Использовать rsa-токены со своей серверной частью, насколько я знаю, нельзя.

[orlik]

 

По идее, должно решаться авторизацией клиентский сертификат + пароль из генератора. Сертификат - в компе, который VPN поднимает. Пароль - из генератора в мобилке. Тогда хакать придется и комп (потом еще сертификат добывать) и мобилку.

 

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

[Sergey Gilfanov]

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

Полная схема (которую никто использовать, разумеется, не будет - с пароноидальностью и неудобством перебор) выглядит так:

1) Для поднятия туннеля нужен клиентски сертификат и одноразовый пароль.

2) Сертификат живет в компе. И закрыт парольной фразой.

3) Одноразовый пароль живет в приложении на мобилке. Но для его генерации нужно ввести пин. Который не просто открывает данные для генерации пароля, но и используется в этой генерации. И да, сообщения 'пин неправильный' - нет. Просто всегда выдаем результат вычисления для того, что ввели.

 

Тут имеем целых три фактора.

a) Сертификат.

b) seed генерации пароля.

c) Парольная фраза на сертификат и пин на пароль.

 

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

[jffulcrum]

У RSA есть токены с хранилищем сертификата и OTP одновременно. Никаких преимуществ у RSA сейчас нет, такое есть уже у всех: те же Aladdin и SAFENet предлагают то же самое: токены и разворачиваемый сервис аутентификации. С API у всех тоже более-менее ровно. Цены при этом гуманней.

[nuclearcat]

Только когда попытаетесь купить эти добровольные бекдоры - вам выжгут мозг экспортным контролем и санкционными вопросами.

Потому очень советую послать их в задницу, и использовать что-то опенсурсное.

[SergoINFOLAN]

Яровая разве разрешает такие штуки юзать без записи кода на листок ?

[vop]

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

[Macil]

В основном информация о том как это круто и ни одного технического манула.

И не будет: патенты и коммерческая тайна. Платишь денюку, получаешь коробочное решение.

 

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

 

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

 

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

 

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

 

Токены дёшевы сами по себе, т.к. работают только в составе дорогих коробочных решений ОИБ.

 

Именно поэтому, ЕМНИП две штуки RFC на эту тему (лень искать) не получили хоть сколь угодно серьёзного развития.

 

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

 

С развитием виртуальных валют (Биткоин и иже с ним) возник устойчивый спрос на управление криптографическими секретами. Есть большой спектр решений, но и они пока не получили широкого распространения, ибо всем по большому счёту пофиг.

 

В твоём конкретном случае плясать нужно от административной составляющей, и подбирать решение под конкретные требования ИБ/ОИБ. Или просто забить.

Edited July 9, 2016 by Macil

[Sergey Gilfanov]

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

Кстати, двухфакторная авторизация для Microsoft/Win10 так и сделана. Там на десктопе набираешь сравнительно короткий PIN, и тебе в телефон в их приложение падает "тут залогинится хотят, пустить?'.

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

 

Есть большой спектр решений, но и они пока не получили широкого распространения, ибо всем по большому счёту пофиг.

Не совсем пофиг. Целая толпа солидных товарищей в FIDO alliance мееееедленно, но гнут линию по внедрения чего-нибудь приличнее логин-пароля.

[Macil]

Там на десктопе набираешь сравнительно короткий PIN

Даже это — излишне. Есть QR-коды. Выводи их хоть в консоль. Нужно всего-то 256 бит.

 

FIDO alliance мееееедленно, но гнут линию по внедрения чего-нибудь приличнее логин-пароля.

Как я понял — хотя я не изучал стандарты подробно — FIDO alliance больше смарт-карта на стероидах без исошных заморочек двадцатипятилетней давности. Тот же yubikey реализует как U2F HID, так и CCID/ICCID наряду с собственным HID интерфейсом.

 

Но в современных условиях... Самый простой телефон за 5 коп. кучка, может прикидываться хоть HID, хоть последовательным портом, хоть MassStorage, хоть UCD. И это просто тупо что есть в линуксе. Из коробки, как говориться. CCID/ICCID нету, но при желании любой школьник напишет. Если бы не огороженные решения производителей, то любой телефон превращался бы в идеальное устройство обеспечения безопасности просто сменой прошивки. Хорошее устройство должно не просто обеспечивать нескучную крипторафию, а ещё и удобный интерфейс с пользователем и альтернативные каналы передачи данных, вплоть до самых экзотических типа аудио.

 

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

 

Но всё упирается в махровый пофигизм и жажду наживы. Отрасль решений ОИБ во всём мире занимает привилегированное положение, ей не нужен полностью открытый стек, т.к. не позволит тихо пилить бабло.