Но уже несколько лет как индустрия не стоит на месте, и вместо одноразовых TAN/PIN-кодов прилетающих по SMS или через приложения типа RSA Token, Steam Guard, Google Authenticator есть и другие варианты.
Вот видео, нас интересует самый первый сценарий. Что происходит?
Вкратце
- Пользователь логинится в приложение. Приложение не выполняет аутентификацию само — оно перенаправляет пользователя в его систему контроля доступа.
- Система контроля доступа (IAM — Identity & Access Management, SSO — Single Sign On) активирует приложение для Single Sign On на смартфоне пользователя.
- Пользователь видит на экране смартфона, что пришел запрос (кто, откуда и т.д.), аутентифицируется и разрешает доступ
- Система IAM получает зеленый свет и возвращает пользователя в приложение, прилагая параллельно разрешение на доступ.
Вопросы
- Q1: Где здесь пользватель вводил что-то в свой компьютер?
- Q2: Куда дружным строем отправляются фейковые страницы?.
Я понимаю, что теперь могут возникнуть и другие вопросы, поэтому
Подробнее
1. Пользователь логинится в приложение. Приложение не выполняет аутентификацию само — оно перенаправляет пользователя в его систему контроля доступа.
* Работает это не только для веб-сайтов, но и для десктопных и мобильных приложений. Типичный пример в бизнес-среде: приложения из MS Office 2013+ (реально 2010+, но там всё было очень кривенько).
* Стандартам и протоколам для интеграции с системами IAM/SSO (SAML, OAuth, OpenID Connect) уже много лет, за ними стоят такие гиганты как Google, Facebook и представители OpenSource сообщества. Есть куча библиотек, SDK и т.д. Так что не интегрируется только ленивый.
* Интеграция подразумевает обмен сертификатами между SSO/IAM и приложением — удачи в подделке
2. Система контроля доступа (IAM — Identity & Access Management, SSO — Single Sign On) активирует приложение для Single Sign On на смартфоне пользователя.
* Нормальные и продвинутые системы позволяют гибко настраивать параметры 2FA
- по приложениям (почта/финансы — важно, расписание корпоративного спортзала — можно и без 2FA),
- по типу аутентификации в приложении-аутентификаторе (почта — палец/PIN, финансы — полный длинный пароль)
- контексту и т.д. (диапазон IP — внутри из офиса или из аэропорта; с какого устройтва, является ли устройство корпоративным; соответствует ли оно Compliance Policy и т.д.).
* Таким образом можно реализовать интересные сценарии. Например, тот же доступ к финансовому приложению:
- Корпоративный лаптоп в офисе — SSO через сертификат, пользователь просто заходит без вопросов, но только если лаптоп прошел проверку Health Attestation (антивирус, файрволл и т.д. отписались, что всё ОК)
- Тот же лаптоп вне офиса (дома, в пути) — 2FA
- [опционально] Тот же лаптоп вне офиса в VPN — пароль
- Свой лаптоп — доступ запрещен, и даже знание пароля и установленный VPN-клиент не помогут, т.к. к проверкам подключается корпоративная MDM-система.
- Но посмотреть расписание корпоративного спортзала можно и со своего лаптопа/телефона — но через 2FA
- А если хочется со своего и без 2FA — регистрируй устройство в корпоративном MDM (с разделением приватного и фирменного) и тогда можно и без 2FA
3. Пользователь видит на экране смартфона, что пришел запрос (кто, откуда и т.д.), аутентифицируется и разрешает доступ
* Обратите внимание, что при таком подходе пользователь, даже находясь на новогодней корпоративной вечеринке, сразу увидит, если кто-то пытается доступиться к его ресурсам.
Но вместо того, чтобы рвать на себе волосы достаточно просто отклонить запрос на доступ и продолжать
* Также, нигде не фигурирует реальный пароль пользователя, и ничто не пишется в веб-страницу/приложение — фейковое или реальное
4. Система IAM получает зеленый свет и возвращает пользователя в приложение, прилагая параллельно разрешение на доступ.
* Разрешение (SAML Assertion) подписано ЭЦП системы IAM и действительно только для этой сессии — просто так не подделать
* Разрещение может содержать дополнительные параметры доступа: роль, ограничения (закрытие определенных разделов портала), временное окно для реаутентификации и т.д.
* И что тоже очень полезно (но должно поддерживаться с обеих сторон) — Just in time Provisioning — т.е. динамическое создание аккаунта в приложении.
Если в компанию пришло 10 человек, и каждому нужно создать 10 аккаунтов — какова вероятности, что админы где-то напортачат и сколько это потом исправлять? С помощью JIT Provisioning приложение получает данные из системы IAM и автоматом всё создает. Хороший пример — Salesforce.
В завершение
Тему можно развивать долго. Вариантов много. Важно, что всё описанное выше — не космос, а вполне реальные вещи, которые может себе позволить любая организация числом от 1 до 100000 чел.
Естественно, если есть много корявых старых приложений, то всё будет сложнее, но в типичных сценариях сроки внедрения <1 мес — реальны.
Важным нюансом является то, что система IAM должна уметь работать с MDM (система управления мобильными устройствами, включая лаптопы/ПК) — иначе должный уровень безопасности не обеспечить (сохраняя вменяемый уровень простоты).
Два крупнейших решения (согласно Gartner MQ 2018):
* Microsoft Azure AD Premium P2 + Intune или MS 365 E3/E5
Отлично вписывается в формат организаций (особенно крупных), внедряющих Office 365 или двигающихся в облако Azure, есть пара подводных камней в лицензировании (типа отдельной платы на 2FA за каждую аутентификацию в отдельных пакетах), что компенсируется кучей всевозможных интеграций с другими продуктами MS и Azure (в т.ч. мобильными приложениями), аналитикой, ИИ и т.д.
Как вариант, MS ADFS (Active Directory Federation Services) позволяет многое реализовать самому и без облака (в т.ч. что, чего Azure до сих пор не умеет, но приходится буквально сшивать лоскутное одеяло, интегрируя и поддерживая различные продукты от разных вендоров
* VMware WorkSpace ONE
VMware купила в 2014 абсолютного (по сей день, включая MQ 2018) лидера MDM/EMM рынка AirWatch и расширила функциональность своими решениями.
Наворотов не так много как у Microsoft, зато работает не только в облаке, больше возможностей для интеграции, больше поддерживаемых платформ (и зачастую больше функциональности — Mac, Android) экосистема (не заточена на Microsoft, как Intune/AzureAD, куча интеграций со специализированными вендорами безопасности, Threat Intelligence, Threat Management), проще лицензирование и, как результат, малые организации могут позволить себе «взрослые» фишки без доплаты.
Оба решения поддерживают управление Windows 10 Modern Management, т.к. MDM-протокол для Win10 разрабатывался (насколько мне известно) с привлечением AirWatch.
В общем, пора закругляться. Думаю дырки в повествовании еще остались. Если есть вопросы — задавайте. С Наступающими!
Комментарии (23)
pfemidi
23.12.2018 08:54В некоторых «особо продвинутых» европейских банках до сих пор пор можно разжиться листиком с одноразовыми TAN-кодами.
IMHO это самый нормальный способ, именно листочек с одноразовыми паролями. И двухфакторная авторизация есть, и пользователи, физически не имеющие мобильного телефона (да, я такой! :-) ) не остаются в стороне. Жаль что вот уже два года как (или больше??? уже не помню) самый популярный в России банк отказался от этих одноразовых листочков, которые ранее можно было в любом банкомате этого самого популярного в России банка получить.apcsb Автор
23.12.2018 15:45Я соглашусь, что это самый low-tech метод, для тех мест, куда high-tech не добрался или добраться не может.
Но с другой стороны, именно это метод пробивается фейковыми страницами, листик может потеряться, его могут найти вместе с Вашим ID, его может сожрать собака или испортить маленький ребенок, в конце концов.
Учитывая, что банкам нужно считать риски, единственный вариант сохранять эти листики, это заставлять пользователя подписывать бумагу, что при взломе аккаунта через именно этот метод банк ответственности не несет и убытков не возмещает (а возможно, еще и взымает с пользователя за восстановление/санацию аккаунта). Вы бы подписали?pfemidi
23.12.2018 16:14За других не скажу, но я бы подписал. Потому что
1) лично у меня нет мобильного телефона и не планируется, приходится каждый раз к банкомату бегать чтобы оплатить тот же ЖКХ и хотя раз в месяц это не особо критично, но всё же неудобно, лучше уж online не выходя из дома как я и делал раньше пока самый популярный в России банк не отказался от листочков с одноразовыми TAN-кодами.
2) как ниже сказал ssh24:
И как тогда телефон выносить из дома? Его можно потерять, или могут украсть
И чем тогда данный поворот событий лучше «листик может потеряться, его могут найти вместе с Вашим ID, его может сожрать собака или маленький ребенок, в конце концов»? IMHO ничем не лучше, но геморроя по сравнению с наличием листочка с одноразовыми TAN-кодами гораздо больше хотя бы в том, что обязательно надо иметь мобильный телефон.apcsb Автор
23.12.2018 16:28Мы с Вами переходим в область проектирования систем и продуктов.
Вот только несколько вопросов, на которые нужно ответить.
* Если украдут листок и телефон, где быстрее получат доступ к аутентификационным данным? Мне кажется, я в комментарии внизу довольно подробно расписал.
* Какой % клиентов самого популярного банка пользуется онлайн-банкингом и не имеет телефона?
* Внедрен ли в системе способ отката/восстановления доступа при потере аутентификатора (листка/телефона)?
* Что важнее для данного приложения — удобство пользователя или безопасность доступа?
Я нахожусь в аналогичной ситуации со своим банком (но в другой теме — у них неудобное и дырявое приложение моб. банкинга) и прекрасно Вас понимаю.
По хорошему, банк (или другая организация) должен учитывать интересы всех клиентов (в т.ч. потенциальных) и предоставлять необходимые и удобные для них способы доступа. В реалии, всё это стоит денег и несет риски. Поэтому нужны компромисы, включается правило Парето, банк описывает свою ЦА, и листики, к сожалению, уходят. Но вы же можете поискать другой банк с листиками или купить подешевке мобилку без SIM-карты, если этот банк Вам всем остальным подходит?
Можете попробовать написать обращение в банк. Я в свой написал. Что мне в вежливой форме ответили, думаю, описывать не надо :)geher
23.12.2018 22:31При потере листка с одноразовыми паролями обычно работал простой до безобразия способ — в банкомате по карте с вводом пин-кода выпускадся новый листок, отменяющий пароли из старого и дающий список новых.
Более того, это настоятельно рекомендовалось проделать при подозрении на попадание информации из листка не в те руки.
Так что вариант "собака съела" абсолютно безопасен.apcsb Автор
24.12.2018 15:03Потеря смартфона, как по мне, тоже ничем не грозит. Как вы считаете?
Лучше, расскажите, как такой листок от «ШОК» фейковых страниц защищать?geher
24.12.2018 16:20-1Потеря смартфона иногда грозит очень многим, поскольку это как правило не просто потеря ключа доступа к одному сайту, а некоторое количество ключей к разным ресурсам плюс некоторое количество конфиденциальной информации.
Даже если смарт весь насквозь зашифрован, его завсегда можно взломать.
Другой вопрос, если смартфон съела собака. Тогда могут возникнуть проблемы со здоровьем собаки.
А фишинг — это совсем другая история, к которой ни потеря смартфона, ни потеря листка с паролями никак не относятся.
apcsb Автор
24.12.2018 17:33Конечно можно взломать. Только сколько это займет времени и усилий? Если за вами лично охотится ФСБ, ФБР и КГБ КНР — да.
Если Ваш телефон найдет в сугробе ХаКиР Петя — думаю вы быстрее отвяжете телефон от SSO (еще одно преимущество SSO — не нужно в панике менять пароли на 100500 разных сайтах), чем он пробьет вменяемо защищенный современный смартфон.
А фишинг — это то, с чего началась эта статья. Выходит, Ваши комментарии к ней не относятся? :)geher
24.12.2018 20:45Мои комментарии относятся к теме комментариев в данной ветке.
Позабавило про собаку, съевшую листок с паролями, вот и отписался.
ssh24
23.12.2018 12:32Сейчас многие переходят на такую аутентификацию. И как тогда телефон выносить из дома? Его можно потерять, или могут украсть, а вместе с ним уйдет контроль над банковским аккаунтом, например.
И второе. Как правило это все относится для защиты десктопа. А у приложений на телефоне как реализуется 2FA? никак?apcsb Автор
23.12.2018 16:03Резонный вопрос.
Поэтому я написал, что SSO должно MDM работать вместе с MDM — тогда есть возможность вменяемо обезопасить телефон и проверять его на целостность при аутентификации.
Пример:
* Телефон зашифрован. Зафорсена политика, требующая Lock Screen. Ключи шифрования выводятся из пароля, при блокировке телефона выкидываются из памяти (iPhone, Android 8+).
* Аутентификатор может всё аналогичное проделывать лично для разблокировки доступа к приватному ключу, которым подписывается ответ на запрос от SSO.
Здесь же работает второй фактор (пароль от телефона не совпадает с паролем от аутентификатора). Геморройно, и скорее всего не будет включено для каждого прилжения, но там где безопасность требует жертв — можно делать.
* Т.к. телефон находится под управлением MDM — аутентификатор стоит в отдельном (managed) разделе ОС, личные приложения пользователя доступа к нему не имеют. Плюс, MDM агент может проверять телефон на целостность/рутованность и т.д.
(Для личного пользования аутентификатор должен реализовать свою крипту и проверки целостности — см. выше )
* Я, правда, лично имел рутованный телефон, который проходил все проверки на рутованность, но это была спец прошивка с Magisk и настройками, которые нужно было сделать ДО того, как ставить все остальные приложения. Возможно ли это сделать на существующем телефоне — ХЗ?
* Одна из фишек MDM — возможность автоматом (допустим, при большом количестве неудачных попыток разблокировки) или руками (через Self-Service для пользователя) пометить телефон как потерянный (или потерявший доверие). При этом МДМ агент на телефоне моментально трет все managed приложения, сертификаты и т.д. (или вообще делает Factory Reset — зависит).
В общем, вариантов защиты телефона довольно много. Главное, балансировать защиту с ценностью данных — если сильно (и без причины) перенаворотить — пользователь просто забьет, и все деньги на внедрение уйдут вникуда.
Поэтому для телефонов чаще всего делают SSO через сертификат/2FA палец (как бы второй фактор, хоть и ненадежный) с проверкой на Compliance телефона — быстро, удобно, в меру безопасно(хоть и не целиком — но см. выше про баланс), чуть что — сертификат/аутентификатор отзываются (не с телефона — а инвалидируются со стороны SSO) и всё закрывается.
Для особо тяжёлых случаев есть аутентификаторы для десктопа или… другого телефона. :)
Уфф… Вроде, ничего не забыл?
Thero
24.12.2018 12:16приложения на телефоне обычно токенизируются при авторизации и ставятся на уникальный пинкод, вторым фактором тут выступает способность разблокировать телефон\незаметно получить к нему физический доступ
особо чувствительные приложения ещё могут проверять не было ли модифицировано защищённое окружение и всякое прочее… тут уже вопрос уровня а как вы носите ключи от дома просто в кармане, в бронированном потайном кармане трусов, под языком… может вообще просто кладёте под коврик выходя из дома… телефон сейчас является максимально персонифицированным предметом поэтому его лидирующая роль как устройства второго фактора безальтернативна.
вот кстати я как второй фактор своего банка могу использовать десктопное приложение и подтверждать операции в нём по пинкоду приложения.
sergeyns
24.12.2018 09:47А чем вам не нравиться листочек (стретч карта) с паролями? Банкам то понятно, дешевле смс-ки отсылать, но надежней таки стретч карта. Конечно оплачивать очередной ерунды в китае так будет несколько труднее, но вот когда речь идет о 6-значных суммах, пусть и в рублях, почему-то все чаще вспоминаются стретч-карты…
Thero
24.12.2018 12:22шестизначные суммы вообще только с паспортом можно провести вроде… или с заранее оговорёнными третьими факторами идентификации личности.
apcsb Автор
24.12.2018 15:04И как вы его от фейковых страниц защитите?
geher
24.12.2018 16:27-1СМС с паролями тоже не сильно защищают от фишинга (в силу самой природы СМС).
Другие методы могут сильно осложнить жизнь мошенникам, но тоже не панацея.apcsb Автор
24.12.2018 17:27Вы видео смотрели? Статью читали? При чём тут СМС с паролями?
geher
24.12.2018 20:53СМС с паролями тут при том, что на данный момент это основной способ защиты, мрименяемый в массовом порядке банками и доугими ресурсами.
Thero
25.12.2018 02:18смс не является безопасным вторым фактором по современным стандартам. собственно статья про нормальные системы 2fa
apcsb Автор
25.12.2018 14:14Ну да, вот они как раз уязвимы к фишингу, и перехвату, а я показываю пример системы 2FA, которая устраняет эту уязвимость.
Visa, например, использует подобный аутентификатор для 3DSecure.
Если хотите безопасный банкинг — можете отправить эту статью своим банкам и «другим ресурсам» — пускай думают. Вы как пользователь вольны выбирать с кем работать, не так ли?
Так что давайте переключаться на конструктивное обсуждение того, что работает, а не жаловаться на то, что не работает.
mwizard
В вашем мире MITM еще не изобрели?
Другими словами, хокир делает фишинговую страницу авторизации. При заходе на нее сервер поднимает у себя Headless Chrome с настоящим ресурсом и отправляет запрос на аутентификацию. Жертве приходит push-сообщение в приложуньку на телефоне, где жертва нажимает на accept. Сервер видит, что в Headless Chrome авторизация прошла, сессия получена, и данные жертвы у нас в руках. Опционально форвардим полученные данные к жертве на фейковую страницу, чтобы не сразу тревогу забили.
И каким образом это решение защитит от настолько банальной атаки?
UPD: даже если там будет что-то типа «Вы пытаетесь зайти из г. Иннсмут, штат Массачусетс» — в зависимости от уровня нацеленности на целевую аудиторию, можно арендовать по прокси-серверу во всех крупных городах. Да и все ли читают?
avg
А настоящий ресурс, на который пришёл запрос на аутенфикацию отвечает не всем, а только тем, кто пришёл с правильный сертификатом и с правильного ip. Настоящий сервер все сервера, с которых такие запросы легальны, наизусть знает, да ещё и паспорт каждый раз просит, а то ходют тут всякие.
В вашем сценарии хокир хныча уйдёт читать журнал ксакеп дальше.
apcsb Автор
Я же написал, что каждое приложение привязывается к SSO путем взаимного обмена сертификатами/ключами. При этом отсутствуют даже цепочки доверия сертификатам, так что даже при украденном Intermediate/Root CA Cert ничего подделать не удастся.
Аналогичный обмен происходит между SSO и приложением-аутентификатором.
Когда ваша фишинговая страница отправит свой левый запрос к SSO — куда он будет автоматически послан?
Ну а те, кто не читают… Ну есть люди, которые ездят непристегнутыми и любят неизвестно кого без предохранения. Как вы предлагаете о них заботится? :)
Или вы какой-то другой сценарий подразумеваете?