Ну да, вот они как раз уязвимы к фишингу, и перехвату, а я показываю пример системы 2FA, которая устраняет эту уязвимость.
Visa, например, использует подобный аутентификатор для 3DSecure.
Если хотите безопасный банкинг — можете отправить эту статью своим банкам и «другим ресурсам» — пускай думают. Вы как пользователь вольны выбирать с кем работать, не так ли?
Так что давайте переключаться на конструктивное обсуждение того, что работает, а не жаловаться на то, что не работает.
Конечно можно взломать. Только сколько это займет времени и усилий? Если за вами лично охотится ФСБ, ФБР и КГБ КНР — да.
Если Ваш телефон найдет в сугробе ХаКиР Петя — думаю вы быстрее отвяжете телефон от SSO (еще одно преимущество SSO — не нужно в панике менять пароли на 100500 разных сайтах), чем он пробьет вменяемо защищенный современный смартфон.
А фишинг — это то, с чего началась эта статья. Выходит, Ваши комментарии к ней не относятся? :)
Мы с Вами переходим в область проектирования систем и продуктов.
Вот только несколько вопросов, на которые нужно ответить.
* Если украдут листок и телефон, где быстрее получат доступ к аутентификационным данным? Мне кажется, я в комментарии внизу довольно подробно расписал.
* Какой % клиентов самого популярного банка пользуется онлайн-банкингом и не имеет телефона?
* Внедрен ли в системе способ отката/восстановления доступа при потере аутентификатора (листка/телефона)?
* Что важнее для данного приложения — удобство пользователя или безопасность доступа?
Я нахожусь в аналогичной ситуации со своим банком (но в другой теме — у них неудобное и дырявое приложение моб. банкинга) и прекрасно Вас понимаю.
По хорошему, банк (или другая организация) должен учитывать интересы всех клиентов (в т.ч. потенциальных) и предоставлять необходимые и удобные для них способы доступа. В реалии, всё это стоит денег и несет риски. Поэтому нужны компромисы, включается правило Парето, банк описывает свою ЦА, и листики, к сожалению, уходят. Но вы же можете поискать другой банк с листиками или купить подешевке мобилку без SIM-карты, если этот банк Вам всем остальным подходит?
Можете попробовать написать обращение в банк. Я в свой написал. Что мне в вежливой форме ответили, думаю, описывать не надо :)
Резонный вопрос.
Поэтому я написал, что SSO должно MDM работать вместе с MDM — тогда есть возможность вменяемо обезопасить телефон и проверять его на целостность при аутентификации.
Пример:
* Телефон зашифрован. Зафорсена политика, требующая Lock Screen. Ключи шифрования выводятся из пароля, при блокировке телефона выкидываются из памяти (iPhone, Android 8+).
* Аутентификатор может всё аналогичное проделывать лично для разблокировки доступа к приватному ключу, которым подписывается ответ на запрос от SSO.
Здесь же работает второй фактор (пароль от телефона не совпадает с паролем от аутентификатора). Геморройно, и скорее всего не будет включено для каждого прилжения, но там где безопасность требует жертв — можно делать.
* Т.к. телефон находится под управлением MDM — аутентификатор стоит в отдельном (managed) разделе ОС, личные приложения пользователя доступа к нему не имеют. Плюс, MDM агент может проверять телефон на целостность/рутованность и т.д.
(Для личного пользования аутентификатор должен реализовать свою крипту и проверки целостности — см. выше )
* Я, правда, лично имел рутованный телефон, который проходил все проверки на рутованность, но это была спец прошивка с Magisk и настройками, которые нужно было сделать ДО того, как ставить все остальные приложения. Возможно ли это сделать на существующем телефоне — ХЗ?
* Одна из фишек MDM — возможность автоматом (допустим, при большом количестве неудачных попыток разблокировки) или руками (через Self-Service для пользователя) пометить телефон как потерянный (или потерявший доверие). При этом МДМ агент на телефоне моментально трет все managed приложения, сертификаты и т.д. (или вообще делает Factory Reset — зависит).
В общем, вариантов защиты телефона довольно много. Главное, балансировать защиту с ценностью данных — если сильно (и без причины) перенаворотить — пользователь просто забьет, и все деньги на внедрение уйдут вникуда.
Поэтому для телефонов чаще всего делают SSO через сертификат/2FA палец (как бы второй фактор, хоть и ненадежный) с проверкой на Compliance телефона — быстро, удобно, в меру безопасно(хоть и не целиком — но см. выше про баланс), чуть что — сертификат/аутентификатор отзываются (не с телефона — а инвалидируются со стороны SSO) и всё закрывается.
Для особо тяжёлых случаев есть аутентификаторы для десктопа или… другого телефона. :)
Я соглашусь, что это самый low-tech метод, для тех мест, куда high-tech не добрался или добраться не может.
Но с другой стороны, именно это метод пробивается фейковыми страницами, листик может потеряться, его могут найти вместе с Вашим ID, его может сожрать собака или испортить маленький ребенок, в конце концов.
Учитывая, что банкам нужно считать риски, единственный вариант сохранять эти листики, это заставлять пользователя подписывать бумагу, что при взломе аккаунта через именно этот метод банк ответственности не несет и убытков не возмещает (а возможно, еще и взымает с пользователя за восстановление/санацию аккаунта). Вы бы подписали?
Я же написал, что каждое приложение привязывается к SSO путем взаимного обмена сертификатами/ключами. При этом отсутствуют даже цепочки доверия сертификатам, так что даже при украденном Intermediate/Root CA Cert ничего подделать не удастся.
Аналогичный обмен происходит между SSO и приложением-аутентификатором.
Когда ваша фишинговая страница отправит свой левый запрос к SSO — куда он будет автоматически послан?
Ну а те, кто не читают… Ну есть люди, которые ездят непристегнутыми и любят неизвестно кого без предохранения. Как вы предлагаете о них заботится? :)
А если помеха?
Задержки и джиттер между SATA и многослойным беспроводным стеком сравнимы?
Параллельные операции? (два провода могут работать одновременно, а два радио на одном канале?)
Да и не такие уж расстояния короткие — то, что на 10м не будет декодироваться сигнал, еще не значит, что его там нет, и он не создает шум для соседей.
В конце концов, если всё равно тянуть кабель (питание) — зачем усложнять систему?
Хорошее начинание, но как-то простовато для «специалиста по ИБ»… Ко мне приходили такие на собеседования: выучил N продуктов, прочитал пару блогов — уже «искперт».
У меня складывается впечатление, что именно в сегменте безопасности очень много людей с отрывочными и продуктовыми знаниями, которые не понимают даже саму концепцию безопасности: модели рисков и угроз, политики, фреймворки, взаимодействие ИБ с другими функциями организации (линейные подразделения, ИТ, физическая безопасность и т.д.).
Я бы этому вначале учил.
Потом рассмотреть классы угроз и решений (системы, сети, мобильные устройства, ПО). Дать домашку «натянуть» что-то универсальное (вроде Common Criteria) на одну из таких сфер (разбить курс на группы) и выписать какие классы решений могут помочь, и как. Потом устроить междусобойчик. Глядишь — полгода и пролетело :)
На выходе получатся люди, способные потом пойти в любую сферу ИБ, разумно быстро вникнуть в специфику и продукты, и выдавать обоснованные(!) решения.
Классно, что у вас всё запустилось! Для информации:
* «Бесшовный» роуминг был в стандарте 802.11 с самого начала — нужно просто настроить на точках одинаковый SSID. 802.11r/k/v позволяют процесс ускорить, если, конечно, корректно поддерживается клиентом.
* В рамках небольшого офиса часто бывает, что 802.11r не работает, но и без него всё хорошо — часто встречаемое явление.
* Если хотите реальных тестов, берите не видео с буферизацией, а честный поток UDP (iPerf), сниффер (для отловли и анализа моментов роуминга) и часики. Тогда будет видно, поддерживает ли клиент эти расширения, насколько он косячит при роуминге (например, не следует рекомендациям AP), насколько сильно «прилипает» к точке, может ли WLAN-сеть корректно сбалансировать клиента или «пересадить» его на другую точку, если сам клиент залип и т.д.
* VoIP/VoWLAN имеет смысл тестить, если есть не менее 20 активных клиентов (10 ЫШЗ-звонков), которые активно сходятся-расходятся по всей территории. Тестировать Skype и проч интернет-телефонами практически бесполезно, т.к. они не работают только если совсем уж всё плохо :)
Отпишитесь, как оно год с лишним спустя работает?
Всё правильно, но вот Вы видели рекламу новой технологии со словами «запасаемся терпением и верим»? :) Суть поста в том, чтобы когда вы увидите «здесь, сейчас, и всё сразу» — можно было сравнить с реальным положением вещей.
Visa, например, использует подобный аутентификатор для 3DSecure.
Если хотите безопасный банкинг — можете отправить эту статью своим банкам и «другим ресурсам» — пускай думают. Вы как пользователь вольны выбирать с кем работать, не так ли?
Так что давайте переключаться на конструктивное обсуждение того, что работает, а не жаловаться на то, что не работает.
Если Ваш телефон найдет в сугробе ХаКиР Петя — думаю вы быстрее отвяжете телефон от SSO (еще одно преимущество SSO — не нужно в панике менять пароли на 100500 разных сайтах), чем он пробьет вменяемо защищенный современный смартфон.
А фишинг — это то, с чего началась эта статья. Выходит, Ваши комментарии к ней не относятся? :)
Лучше, расскажите, как такой листок от «ШОК» фейковых страниц защищать?
Вот только несколько вопросов, на которые нужно ответить.
* Если украдут листок и телефон, где быстрее получат доступ к аутентификационным данным? Мне кажется, я в комментарии внизу довольно подробно расписал.
* Какой % клиентов самого популярного банка пользуется онлайн-банкингом и не имеет телефона?
* Внедрен ли в системе способ отката/восстановления доступа при потере аутентификатора (листка/телефона)?
* Что важнее для данного приложения — удобство пользователя или безопасность доступа?
Я нахожусь в аналогичной ситуации со своим банком (но в другой теме — у них неудобное и дырявое приложение моб. банкинга) и прекрасно Вас понимаю.
По хорошему, банк (или другая организация) должен учитывать интересы всех клиентов (в т.ч. потенциальных) и предоставлять необходимые и удобные для них способы доступа. В реалии, всё это стоит денег и несет риски. Поэтому нужны компромисы, включается правило Парето, банк описывает свою ЦА, и листики, к сожалению, уходят. Но вы же можете поискать другой банк с листиками или купить подешевке мобилку без SIM-карты, если этот банк Вам всем остальным подходит?
Можете попробовать написать обращение в банк. Я в свой написал. Что мне в вежливой форме ответили, думаю, описывать не надо :)
Поэтому я написал, что SSO должно MDM работать вместе с MDM — тогда есть возможность вменяемо обезопасить телефон и проверять его на целостность при аутентификации.
Пример:
* Телефон зашифрован. Зафорсена политика, требующая Lock Screen. Ключи шифрования выводятся из пароля, при блокировке телефона выкидываются из памяти (iPhone, Android 8+).
* Аутентификатор может всё аналогичное проделывать лично для разблокировки доступа к приватному ключу, которым подписывается ответ на запрос от SSO.
Здесь же работает второй фактор (пароль от телефона не совпадает с паролем от аутентификатора). Геморройно, и скорее всего не будет включено для каждого прилжения, но там где безопасность требует жертв — можно делать.
* Т.к. телефон находится под управлением MDM — аутентификатор стоит в отдельном (managed) разделе ОС, личные приложения пользователя доступа к нему не имеют. Плюс, MDM агент может проверять телефон на целостность/рутованность и т.д.
(Для личного пользования аутентификатор должен реализовать свою крипту и проверки целостности — см. выше )
* Я, правда, лично имел рутованный телефон, который проходил все проверки на рутованность, но это была спец прошивка с Magisk и настройками, которые нужно было сделать ДО того, как ставить все остальные приложения. Возможно ли это сделать на существующем телефоне — ХЗ?
* Одна из фишек MDM — возможность автоматом (допустим, при большом количестве неудачных попыток разблокировки) или руками (через Self-Service для пользователя) пометить телефон как потерянный (или потерявший доверие). При этом МДМ агент на телефоне моментально трет все managed приложения, сертификаты и т.д. (или вообще делает Factory Reset — зависит).
В общем, вариантов защиты телефона довольно много. Главное, балансировать защиту с ценностью данных — если сильно (и без причины) перенаворотить — пользователь просто забьет, и все деньги на внедрение уйдут вникуда.
Поэтому для телефонов чаще всего делают SSO через сертификат/2FA палец (как бы второй фактор, хоть и ненадежный) с проверкой на Compliance телефона — быстро, удобно, в меру безопасно(хоть и не целиком — но см. выше про баланс), чуть что — сертификат/аутентификатор отзываются (не с телефона — а инвалидируются со стороны SSO) и всё закрывается.
Для особо тяжёлых случаев есть аутентификаторы для десктопа или… другого телефона. :)
Уфф… Вроде, ничего не забыл?
Но с другой стороны, именно это метод пробивается фейковыми страницами, листик может потеряться, его могут найти вместе с Вашим ID, его может сожрать собака или испортить маленький ребенок, в конце концов.
Учитывая, что банкам нужно считать риски, единственный вариант сохранять эти листики, это заставлять пользователя подписывать бумагу, что при взломе аккаунта через именно этот метод банк ответственности не несет и убытков не возмещает (а возможно, еще и взымает с пользователя за восстановление/санацию аккаунта). Вы бы подписали?
Аналогичный обмен происходит между SSO и приложением-аутентификатором.
Когда ваша фишинговая страница отправит свой левый запрос к SSO — куда он будет автоматически послан?
Ну а те, кто не читают… Ну есть люди, которые ездят непристегнутыми и любят неизвестно кого без предохранения. Как вы предлагаете о них заботится? :)
Или вы какой-то другой сценарий подразумеваете?
Задержки и джиттер между SATA и многослойным беспроводным стеком сравнимы?
Параллельные операции? (два провода могут работать одновременно, а два радио на одном канале?)
Да и не такие уж расстояния короткие — то, что на 10м не будет декодироваться сигнал, еще не значит, что его там нет, и он не создает шум для соседей.
В конце концов, если всё равно тянуть кабель (питание) — зачем усложнять систему?
У меня складывается впечатление, что именно в сегменте безопасности очень много людей с отрывочными и продуктовыми знаниями, которые не понимают даже саму концепцию безопасности: модели рисков и угроз, политики, фреймворки, взаимодействие ИБ с другими функциями организации (линейные подразделения, ИТ, физическая безопасность и т.д.).
Я бы этому вначале учил.
Потом рассмотреть классы угроз и решений (системы, сети, мобильные устройства, ПО). Дать домашку «натянуть» что-то универсальное (вроде Common Criteria) на одну из таких сфер (разбить курс на группы) и выписать какие классы решений могут помочь, и как. Потом устроить междусобойчик. Глядишь — полгода и пролетело :)
На выходе получатся люди, способные потом пойти в любую сферу ИБ, разумно быстро вникнуть в специфику и продукты, и выдавать обоснованные(!) решения.
Или, слишком круто забираю? :)
Интересно, сколько девайсов останутся к тому времени…
* «Бесшовный» роуминг был в стандарте 802.11 с самого начала — нужно просто настроить на точках одинаковый SSID. 802.11r/k/v позволяют процесс ускорить, если, конечно, корректно поддерживается клиентом.
* В рамках небольшого офиса часто бывает, что 802.11r не работает, но и без него всё хорошо — часто встречаемое явление.
* Если хотите реальных тестов, берите не видео с буферизацией, а честный поток UDP (iPerf), сниффер (для отловли и анализа моментов роуминга) и часики. Тогда будет видно, поддерживает ли клиент эти расширения, насколько он косячит при роуминге (например, не следует рекомендациям AP), насколько сильно «прилипает» к точке, может ли WLAN-сеть корректно сбалансировать клиента или «пересадить» его на другую точку, если сам клиент залип и т.д.
* VoIP/VoWLAN имеет смысл тестить, если есть не менее 20 активных клиентов (10 ЫШЗ-звонков), которые активно сходятся-расходятся по всей территории. Тестировать Skype и проч интернет-телефонами практически бесполезно, т.к. они не работают только если совсем уж всё плохо :)
Отпишитесь, как оно год с лишним спустя работает?