Comments 42
Мне кажется пора банить за такие статьи. Кошмар какой-то
Хорошо, какова будет причина бана? Статья посвящена конкретной проблеме и довольно серьезной, можете аргументировать?
бесполезная вода
вот мой телеграм подпишись скорее
Ок, я уберу свой тг канал. Цель статьи не в этом - цель показать проблему из-за которой случаются массовые случаи фрода до сих пор в 2025 году. К тому же есть ссылки на oauth 2.0 ciba, чтобы понимать как это должно быть на самом деле.
Проблема вовсе не в том, что кто-то просит коды.
Проблема в том, что коды из второго фактора превратились в единственный.
С этим надо бороться, а не с многочисленными последствиями.
И желательно.... Законодательно.
На самом деле тут не все так плохо - кое где есть биометрия как второй фактор (webauthn). У сбера точно есть, у втб кажется тоже.
Это "пока".
Вначале вторым фактором были смс, потом они стали единственным.
Теперь вторым фактором стала биометрия ? Как быстро она станет единственным ? Насколько она вообще надёжна ? Хороший визажист загримирует вас так, что родная мать не отличит от жертвы...
И потом, как биометрия вообще может быть вторым фактором? Этож должен быть фактор который подтверждает не владение чем-то, а знание чего-то...
Теперь вторым фактором стала биометрия ? Как быстро она станет единственным ? Насколько она вообще надёжна ? Хороший визажист загримирует вас так, что родная мать не отличит от жертвы...
Так, конечно, face id взломать не получится, но можно изготовить копию лица, такая атака уже известна.
И потом, как биометрия вообще может быть вторым фактором? Этож должен быть фактор который подтверждает не владение чем-то, а знание чего-то...
Может и на данный момент она считается более безопасной, чем коды из смс.
В смысле "более безопасной чем смс" ? У вас faceid будет вместо смс ? Т.е. всё, что нужно для банковского перевода - это быть загримированном под жертву ? Больше никаких проверок :)?
Странно объяснять это вроде как работающему в безопасности человеку, но двухфакторная идентификация подразумевает не просто рандомные две разных проверки, а два разных по смыслу фактора. Один должен подтверждать факт знания о чем-то, а другой факт владения чем-то.
И нет, смс это не знание - это владение телефоном. Знание - это к примеру пинкод.
Вот в банкомате два фактора, вам нужна карта и нужен пинкод. Ну т.е. так раньше было, сейчас не удивлюсь если и банкоматы опошлили....
У вас faceid будет вместо смс ? Т.е. всё, что нужно для банковского перевода - это быть загримированном под жертву ? Больше никаких проверок :)?
Я когда это читал не мог поверить своим глазам, но все равно спасибо вам за ваше мнение, на этом диалог можно закончить.
faceid элементарно обходится.
Тут никакого грима не нужно, нейросеть можно натренить банально.
Никакая нейросеть faceid взломать не сможет - думаете никто не пробовал? Все девайсы apple при сканировании лица строят так называемую "карту глубины", т.е. грубо говоря анализируют объем изображения с помощью датчиков. А deepfake по своей природе плоское изображение будь он хоть каким реалистичным. Единственный способ взлома faceid - это изготовление 3d копии лица и хакеры это делать умеют, но эта процедура очень трудоемкая.
faceid элементарно обходится.
Приведите, пожалуйста пруф своих утверждений как можно "элементарно" обойти faceid или, может, как вы сами это делали. Deepfake сейчас создать очень легко, продемонстрируйте.
Часто они построены не на базе IT-стандартов безопасности.
Требования к ИБ регламентирует Центробанк и он же контролирует их выполнение банками.
Вы правы. Я как человек много лет проработавший в двух крупных банках знаю это не понаслышке. ЦБ знает про Oauth 2.0 и OpenID Connect. В свое время я задал вопрос сотруднику ЦБ, который проводил у нас аудит, если ЦБ настаивает на использовании Ouath 2.0, почему большинство банков игнорируют это требованию. И он ответил, что невозможно сделать это требование жестким, т.к. за давностью лет многие банки технически не могут перейти на Ouath 2.0.
за давностью лет многие банки технически не могут перейти на Ouath 2.0
То есть это слишком уж дорого для банков? При таком требовании банки обнищают?
По своему опыту скажу вам так - задача перевода банка легаси авторизации на полноценный Oauth 2.0 - это если не героическая задача, то как минимум очень трудная. Нужно идеально знать все технологии безопасности - keycloak, spring authorization server, spring security и т.д. При это обязательно нужна обратная совместимость с легаси авторизацией, чтобы разрабы в панике не правили баги на коленке. Представьте, что будет если 50 млн пользователей разом разлогинит - банк, наверное, не обнищает, но получит самый масштабный коллапс в своей истории.
В Точка-банке коллега как-то специально спрашивал о возможности подтверждения транзакций НЕ через СМС. Ответили, что такой возможности нет и что переживать из-за этого не надо. И это Точка, один из лучших банков...
Подтверждение операции по смс не так кошмарно, как просить код из смс при общении с клиентом. Это навязывает клиенту плохой шаблон поведения. Неудивительно, что после того, как банки стали так делать количество атак мошенников увеличилось в разы.
как банки стали так делать количество атак мошенников увеличилось в разы
если у вас есть подобная аналитика, возможно её стоило приложить к статье
В общем то она известна, есть на сайте ЦБ, я могу собрать ее и приложить к статье - потери банков в 2018 году 1млрд, начиная с 2019 и далее (как раз когда начали просить код из смс) - 9.7 млрд, 13.5 и т.д. Есть данные от лаборатории касперского - там это связывают с подделками номеров (сейчас уже не очень актуально, т.к. во всех банках есть проверка imsi) и запросом кода из смс. Чуть позже найду и приложу.
Добрый день. Я из Точки.
Точка строго соблюдает требования в области информационной безопасности и регулярно проходит проверки на соответствие установленным стандартам. Мы используем сертифицированные решения, одобренные ФСТЭК, для обеспечения максимальной защиты данных.
Подписание по смс-коду — это основной способ подписания для клиентов многих банков, оно предназначено для дополнительной защиты системы дистанционного обслуживания от несанкционированного доступа к расчетному счёту клиента. Защита осуществляется посредством использования альтернативного канала передачи дополнительного кода подтверждения платежа и считается аналогом других вариантов подписания платежей.
Существует несколько видов электронной подписи:
НЭП – неквалифицированная электронная подпись – генерируется в специальной криптографической программе в момент подписания документа. С помощью НЭП можно подтвердить авторство документа и неизменность его содержания. Если в подписанный НЭП файл внести правки, то подпись станет недействительной;
КЭП - квалифицированная электронная подпись – разновидность электронной подписи с высоким уровнем безопасности, для её создания применяется технология криптографической защиты информации. Сертификат подписи записывают на физический носитель, например, на USB-токен.
Как раз с помощью НЭП подписывают платежи в интернет-банке, подписание происходит при помощи смс, это юридически значимое подписание документов.
Для подтверждения также может прийти push, если у клиента установлено приложение Точки и подтверждение переводов с карты Точки происходит в стороннем интерфейсе.
Добрый день. Спасибо большое за комментарий. Но речь идет немного не об этом - то, что для подтверждения операций вы используете подписание (я так понимаю механизм otp sign) это вопросов не вызывает, хотя и у этого способа есть определенные проблемы с безопасностью. Мы обсуждаем другое - насколько правильно использовать код из смс для идентификации клиента при общении со службой поддержки. И мой основной посыл - лучше так не делать, это небезопасно.
Понимаю вас. Прокомментировала момент именно про необходимость смс-кода для транзакций.
Наши сотрудники не запрашивают коды из смс для идентификации клиентов. Коды направляются для самостоятельного входа в банк или же для подписания платежа клиентами.
Если же клиенты не могут зайти в интернет-банк, то помогаем восстановить доступ через видео-встречу и принимаем от них заявление. На встрече также не отправляем смс с кодом и не запрашиваем их.
От себя еще добавлю один момент - ваш процесс авторизации это Ouath 2.0 и это замечательно. Но вы используете публичного клиента для вашего фронта, я вижу в запросе client_id, при чем это guid. Очень похоже что у вас keycloak в качестве сервера авторизации. Рекомендую весь флоу авторизации вынести на BFF, например шлюз spring cloud gateway, и сделать его приватным клиентом.
Вам стоит поправить шаблон на что-то вроде:
Привет, я бот из Точки и копипасчу ответы по ключевым словам.
Обслуживание клиентов рассчитываются на все случаи жизни и категории клиентов. Плюс возможны разные ситуации, когда у клиента нет устройства в руках, оно потеряно или еще чего хуже. Рассчитывать, что у всех на руках девайст для биометрии несколько оптимистично.
Но я соглсен с тем, что спрашивать голосом код - плохая практика, т.к. это облегчает работу мошенников, которым теперь легче мимикрировать под "службу безопасности банка".
Тем не менее я так-же согласен с замечанием выше, что статья пустовата. Было бы лучше, если бы в ней ыли проанализированы существующие схемы аутентификации и предложили в статье свои реальные схемы аутентификации при звоках в колцентр, нежели просто отсылатать на стандарт в интернете без какоу-то конкретики. Статья из-за жтого выглядит пустой и незавершенной.
Спасибо за фидбэк. Я упоминал в статье про Client-Initiated Backchannel Authentication Flow или CIBA. Это расширение Ouath 2.0 специально для таких случаев. Он довольно сложен в описании, и я решил вынести это за скобки. В keycloak он есть, но проблема в том, что во многих банках используются свои самописные серверы авторизации и такого флоу там просто нет. Да и мало кто про него знает.
Вы бы лучше не упоминали, а популярным языком рассказали как оно работает и чем так замечательно. Тогда в статье был бы смысл
Спасибо за фидбэк, хорошее замечание. Доступно рассказать про Client-Initiated Backchannel Authentication Flow трудно, но я подумаю как это можно сделать.
Вся соль в том, что обычному клиенту, у которого что-то случилось и горит тоже долдно быть понятно. А если и специалисту не понятно, то о чем тут говорить.
Я сходил по ссылке, почитал. Вернее даже так. По ссылке слабо что можно понять. Но поиском в гугле есть пример некого шведского банка, где при звонке в колцентр, клиента аутентифицируют через спец. приложение, которое у него стоит на смартфоне и клиент должен там приложить палец. Вот таким языком это понятно, незачем простые вещи маскировать под стандарты.
Так вот, все в этой схеме прекрасно, но не учитывает ситуации. когда нет у клиента смартфона на руках, или нет приложения на нем или ... много чего еще из реальной жизни простых людей. Так что эта схема годится не для всех. А надо, что бы для всех и что бы схема была максимально дешевой в эксплуатации и логистике до клиента. Может лет через пять-семь при смене поколений как раз время и подойдет.
А какой есть простой и универсальный способ авторизации, кроме смс? Если у человека стоит приложение банка - то да, оператор при обслуживании отправляет туда запрос и вы тыкаете кнопку "да, это я". Но если приложения нет, то только код из смс.
Например, в CITI банке в процессе звонка в тональном режиме необходимо ввести свой секретный код.
Если приложения нет, то это проблема, т.к. безопасного способа без явных векторов атак не будет.
Если у человека стоит приложение банка - то да, оператор при обслуживании отправляет туда запрос и вы тыкаете кнопку "да, это я"
В общем то в этом и есть суть CIBA, но мало у кого такое есть.
Когда присылают SMS, там же написано большими буквами «Никому не говорите код». Я думал, у всех так, по заголовку даже не понял, о чем статья.
До последнего надеялся, что хотя бы часть статьи будет о банках, которые поддерживают аппаратные генераторы одноразовых паролей. Два банка из списка в статье это поддерживали несколько лет назад, но тоже принудительно на СМС перешли. Как говорится, увы.
Кто из банков просит код из смс в 2025 году