Comments 51
Интересная статья. О какой платежке идет речь?
Многие используют Google Authenticator app, выходит что это ненадежно?
Удалось ли поймать хакеров? Они же как-то выводили деньги.
Когда высылается смска с паролем, то обычно показывается куда (кому) осуществляется перевод. И юзер на этом моменте может заметить подвох (конечно, если телефон не протроянен). В этом плюс смс и большой минус программных OTP (например, от Google).
Это верно. Мы тоже на это надеялись, но есть несколько моментов: 1) ОТР в смс не привязан к данным и может быть ситуация, когда в СМС попадет “нужная” информация; 2) смс может быть перехвачено, дублировано и т.д. 3) Не все пользователи обращают внимание на что-то еще, кроме ОТР в таких смс. К тому же, смс имеет ограничение на длину сообщения, и не все параметры, которые могут быть подвергнуты атаке реально отобразить в одном сообщении, например баланс до и после транзакции и т.д.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Ну и в СМС можно сразу открытым текстом писать «перевод денег с вашего счета на Васю Пупкина» + в случае, если идет перевод денег на счет ранее никогда не используемый владельцем, дополнительно что-то делать — запрашивать еще одно подтверждение и т.д.
Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
Ну и в СМС можно сразу открытым текстом писать «перевод денег с вашего счета на Васю Пупкина» + в случае, если идет перевод денег на счет ранее никогда не используемый владельцем, дополнительно что-то делать — запрашивать еще одно подтверждение и т.д.
Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Скорее всего, связь кодов подтверждения была не с транзакциями, а с телефоном пользователя, т.е. подтверждалась не сама транзакция, а то, что человек владеет телефоном.
Скорее всего, связь кодов подтверждения была не с транзакциями, а с телефоном пользователя, т.е. подтверждалась не сама транзакция, а то, что человек владеет телефоном.
как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Если я всё верно понял, то не обязательно так. Схема может быть такая:
1. Юзер пытается сделать операцию «кинуть 100 рублей на телефон».
2. Вредонос анализирует этот запрос и формирует страничку, визуально выглядящую, как запрос кода подтверждения для этой операции…
3.… но в банк отправляет данные на запрос подтверждения для «кинуть все деньги на аккаунт Мистера Х»
Т.е. юзер делает операцию «кинуть 100 рублей на телефон» в фейковом интерфейсе, а бот в это время делает в реальном перевод на другой аккаунт?
Если так, то я не правильно понял ситуацию.
В этом случае спасает сообщение + двойное подтверждение, ибо врядли до этого юзер имел дело с аккаунтом данного мистера.
Есть еще одна штука, почему не читают сообщения с OTP — очень часто они засраны рекламой, если этого не было — пользователи были бы более внимательны.
Если так, то я не правильно понял ситуацию.
В этом случае спасает сообщение + двойное подтверждение, ибо врядли до этого юзер имел дело с аккаунтом данного мистера.
Есть еще одна штука, почему не читают сообщения с OTP — очень часто они засраны рекламой, если этого не было — пользователи были бы более внимательны.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Вы говорите о варианте 2 (см. статью), но в этом пункте описан просто один из возможных вариантов развития событий.
В нашей системе привязка OTP к транзакции существовала, но злоумышленниками была подделана часть важных параметров в самой транзакции.
Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
OTP и так запрашивался, какие дополнительные средства защиты Вы имеете в виду?
Грубо говоря следующие действия:
1) от имени юзера происходит операция, запрашивается OTP на нее
2) на телефон юзера приходит сообщение «Перевод XXX рублей на счет ZZZZ, если вы подтверждаете это, используйте код YYYY
3) пользователь не читает, вводит YYYY
4) система в банке проверяет, имел ли дело данный пользователь с этим счетом, если нет — генерит еще один OTP
5) приходит еще одна смс — вы не разу не работали с данным счетом и действительно хотите перевести на него XXX рублей? Для подтверждения используйте код CCCC
На второй раз пользователь очень вероятно, что поглядит текст СМС. Это не панаяцея, но думается, что большинство людей не попадутся.
Главное, что сообщение об отсутствии взаимодействия с данным счетом приходило именно вторым, не первым. Первое никогда не читают.
1) от имени юзера происходит операция, запрашивается OTP на нее
2) на телефон юзера приходит сообщение «Перевод XXX рублей на счет ZZZZ, если вы подтверждаете это, используйте код YYYY
3) пользователь не читает, вводит YYYY
4) система в банке проверяет, имел ли дело данный пользователь с этим счетом, если нет — генерит еще один OTP
5) приходит еще одна смс — вы не разу не работали с данным счетом и действительно хотите перевести на него XXX рублей? Для подтверждения используйте код CCCC
На второй раз пользователь очень вероятно, что поглядит текст СМС. Это не панаяцея, но думается, что большинство людей не попадутся.
Главное, что сообщение об отсутствии взаимодействия с данным счетом приходило именно вторым, не первым. Первое никогда не читают.
Я бы проклял такой сервис :)
Думаю, что в предложенном подходе есть недостаток, т.к. Вы предлагаете использовать второй раз тот же самый фактор (смс-ки), а он может быть скомпрометирован. Надо использовать другой фактор, но среди пользователей не будет популярен такой “удобный сервис”.
Многие не включают даже простую двухфакторную аутентификацию, что говорить о таких сложных пируэтах )
Многие не включают даже простую двухфакторную аутентификацию, что говорить о таких сложных пируэтах )
UFO just landed and posted this here
При этом перевод с карты на карту выглядит как «Сбербанк Онлайн. Внимательно проверьте реквизиты операции: карта списания **** XXXX, карта зачисления **** YYYY, сумма ZZZZ RUB. Пароль для подтверждения данной операции — AAAA» и всё. Из этого длинного сообщения ценной информацией является только YYYY, а это всего 4 цифры. Хотя при оплатах через платёжные шлюзы смска выглядит вполне лаконично: «назначение (RUB сумма) пароль: цифры. Не сообщайте этот пароль никому, в том числе сотруднику Банка»
А я, когда приходит смс, смотрел в статус бар, пока он не прокрутит до кода подтверждения. Благо фильтровать информацию с сайтов умею и попадаюсь на зловреды ну максимум раз в пару месяцев. Теперь буду внимательным :)
запрашивать доп. OTP ну и все
двойное подтверждение
Вы не могли бы привести реальные примеры, где на одну операции отправляется 2 OTP?
Я могу ошибаться, но с точки зрения пользователя это не очень удобно.
Любая защита — это вообще не удобно для пользователя.
Тут соблюдается баланс — в случае, если пользователь имеет отношение с публичными компаниями — OTP будет спрошен один раз. Это не доставит никаких неудобств.
В случае подозрения будет спрошено два раза — это во-первых даст возможность в случае проведения таки такого платежа, ткнуть, что Вас предупреждали два раза, во-вторых сильно повысит внимательность пользователя, но да, через его неудобство, увы.
Тут соблюдается баланс — в случае, если пользователь имеет отношение с публичными компаниями — OTP будет спрошен один раз. Это не доставит никаких неудобств.
В случае подозрения будет спрошено два раза — это во-первых даст возможность в случае проведения таки такого платежа, ткнуть, что Вас предупреждали два раза, во-вторых сильно повысит внимательность пользователя, но да, через его неудобство, увы.
Зачем все эти сложности? В статье описан более удобный и дешевый (ведь каждая дополнительная отправка SMS стоит денег) способ защиты, который позволяет избежать неудобств пользователя и дополнительных расходов системы, связанных с двойной отправкой OTP, и при этом отлично справляется с угрозами автозалива и реплейсмента.
Вы про CWYS?
Там тоже не все гладко, если пользователь работает через фейковый интерфейс, то все данные за него формирует он.
Ну или я не понимаю технологию. Смотрите:
1) пользователь в фейкфейсе делает транзакцию на 100 рублей
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
3) пользователь вводит код (который от совсем другой операции) и подтверждает его
4) и где защита?
Там тоже не все гладко, если пользователь работает через фейковый интерфейс, то все данные за него формирует он.
Ну или я не понимаю технологию. Смотрите:
1) пользователь в фейкфейсе делает транзакцию на 100 рублей
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
3) пользователь вводит код (который от совсем другой операции) и подтверждает его
4) и где защита?
Есть несколько точек контроля: во-первых, в приложении отображается информация о том, куда реально уйдут деньги (как и для случая с смс); во-вторых, есть встроенные механизмы контроля целостности и согласованности данных фронтэнда и бекэнда, которые получают информацию по разным каналам; в-третьих, забегая наперед, генерация ОТР и подтверждение транзакции происходит в несколько этапов, при подмене данных между этапами взаимодействия, ОТР попросту будет не валиден.
Мне тоже интересно, но ответ я не понял. Зловред полностью контролирует клиентскую сторону, с точки зрения бэкенда все будет совершенно валидно — пользователь хочет перевести все деньги на другой аккаунт и зловред предоставил для этого все данные. Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта. Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта.
Да, они говорят серверу
Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
Для данного кейса этого достаточно для предотвращения кражи
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
В этом случае пользователь получит сообщение, что он переводит 1000р (кому и какой баланс) и пункт №3 не произойдет.
Изначально посыл был в том, что пользователи далеко не всегда читают то, что пришло с кодом подтверждения. Т.е. CWYS здесь ничем не лучше обычных OTP — про что я, собственно, Вам и написал :) И в данном случае он ничем не поможет, ИМХО. Пользователь тупо подтвердит транзакцию, ну да, зато теперь подписанную :)
По поводу примеров.
Могу привести Райфазен, правда там было не совсем OTP ))
При подозрительной транзакции, после подтверждения со мной связались из банка, проверили меня секретным вопросом и уточнили, реально ли я хочу сделать данную транзакцию.
Могу привести Райфазен, правда там было не совсем OTP ))
При подозрительной транзакции, после подтверждения со мной связались из банка, проверили меня секретным вопросом и уточнили, реально ли я хочу сделать данную транзакцию.
Звонившие как нибудь подтвердили что они именно из банка вам звонят?
Да-да… пришла тут на днях СМСка «ваша карта скомпромитирована, срочно позвоните в сбербанк и городской номер +7812....»
Если бы не номер с которого пришла СМС — +44… я бы возможно дернулся позвонить или по крайней мере достать карту и посмотреть на ней номер Сбера (+8800...)
Если бы не номер с которого пришла СМС — +44… я бы возможно дернулся позвонить или по крайней мере достать карту и посмотреть на ней номер Сбера (+8800...)
Звонок был с номера банка, звонившая была моим менеджером этого банка (представилась, назвала ФИО и должность — я уже работал с ней в этом банке) и сказала секретную фразу банка — так что подтвердили 3 способами ;)
UFO just landed and posted this here
Можно было сделать так:
1. Пользователь задает свой пароль для проведения транзакции\входа в кабинет и тп.
2. Выдается пользователю OTP.
3. Для подтверждения перевода пользователь вводить свой пароль + код с OTP.
1. Пользователь задает свой пароль для проведения транзакции\входа в кабинет и тп.
2. Выдается пользователю OTP.
3. Для подтверждения перевода пользователь вводить свой пароль + код с OTP.
руководство компании компенсировало часть потерь пострадавшему
Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации. Спустя какое время клиент пожаловался? Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции? Детектирует ли какое-либо антивирусное ПО этот вид зловредов?
Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации.
В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери. Но учитывая то, что этот юзер является нашим давним клиентом с большими оборотами и использовал все средства защиты, предлагаемые нашим сервисом, руководством компании было принято решение о возмещении большей части его потерь.
Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции?
В нашей системе не поддерживается диспут и транзакции являются необратимыми. Клиент пожаловался в тот же день, часть украденных денег была заблокирована в партнерских платежках и возвращена, но основная часть была выведена злоумышленником в криптовалюты и дальнейший путь отследить не удалось.
Детектирует ли какое-либо антивирусное ПО этот вид зловредов?
Подобный софт затачивается конкретно под определенную систему и часто трудно диагностируем. В нашем случае антивирус пользователя не сработал.
Что, это правда? А если стал жертвой card fraud, тоже нельзя транзакцию отменить? Но это же означает, что банковскими услугами в россии пользоваться нельзя т.к. есть риск потерять все сбережения по независящим от клиента причинам.
А теперь банки предлагают застраховать операции по картам всего за пару тысяч рублей в год. Уверяют что всё-всё вернут при любых несанкционированных операциях.
Прямым приемом платежей с карт мы не занимаемся, работаем через партнеров. Потому вся ответственность за безопасность таких платежей переноситься на партнеров, у которых есть собственные специалисты по безопасности, anti-fraud фильтры, механизмы верификации и другие стандартные инструменты безопасности.
В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери.
Да ну. По закону 161-ФЗ, банк должен доказать, что был факт утери. В противном случае он обязан возместить потери клиента.
Статья 9
13. В случае, если оператор по переводу денежных средств не исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи, оператор по переводу денежных средств обязан возместить клиенту сумму операции, о которой клиент не был проинформирован и которая была совершена без согласия клиента.
14. В случае, если оператор по переводу денежных средств исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент не направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств не обязан возместить клиенту сумму операции, совершенной без согласия клиента.
15. В случае, если оператор по переводу денежных средств исполняет обязанность по уведомлению клиента — физического лица о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент — физическое лицо направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств должен возместить клиенту сумму указанной операции, совершенной без согласия клиента до момента направления клиентом — физическим лицом уведомления. В указанном случае оператор по переводу денежных средств обязан возместить сумму операции, совершенной без согласия клиента, если не докажет, что клиент нарушил порядок использования электронного средства платежа, что повлекло совершение операции без согласия клиента — физического лица.
Из ссылок в статье могу предположить, что у вас двухфакторная аутентификация от https://www.protectimus.com. Так ли это? И если да, то почему выбрали именно этот сервис? Кто еще предоставляет CWYS-решения по защите от автозалива?
Я думаю, что с помощью совместного (связанного) использования капчи и СМС с кодом подтверждения(инструкцией) можно гарантировано обезопасить клиента от автозалива и реплейсера.
Вот простенький пример, сделанный на скорую руку, иллюстрирующий суть идеи:
1. на странице банка(платежной системы) информация выводится в виде картинки примерно такого вида
2. по СМС приходит инструкция примерно следующего содержания:
Для подтверждения перевода на сумму ХХХХХ.ХХ со счета ЯЯЯЯ на счет ОООО введите сумму первых 3-х зеленых цифр а затем с 3-й по 8-ю красную цифру
Цветовая схема капчи и условия ввода в инструкции должны быть индивидуальными для каждой операции, и подобраны так, чтобы исключить анализ цветовой схемы и содержания условий ввода по данным введенной пользователем.
Условие ввода должно включать в себя важные (ключевые) данные о переводе. То есть в него должны войти цифры из суммы перевода и номеров счетов участников.
Если выполнить все эти условия, то будет крайне затруднительно (на мой взгляд — невозможно) использовать код полученный выполнением инструкции из СМС для перевода не соответствующего указанному на картинке.
ЗЫ: данная схема не учитывает вариант, когда телефон пользователя также скомпрометирован.
Вот простенький пример, сделанный на скорую руку, иллюстрирующий суть идеи:
1. на странице банка(платежной системы) информация выводится в виде картинки примерно такого вида
2. по СМС приходит инструкция примерно следующего содержания:
Для подтверждения перевода на сумму ХХХХХ.ХХ со счета ЯЯЯЯ на счет ОООО введите сумму первых 3-х зеленых цифр а затем с 3-й по 8-ю красную цифру
Цветовая схема капчи и условия ввода в инструкции должны быть индивидуальными для каждой операции, и подобраны так, чтобы исключить анализ цветовой схемы и содержания условий ввода по данным введенной пользователем.
Условие ввода должно включать в себя важные (ключевые) данные о переводе. То есть в него должны войти цифры из суммы перевода и номеров счетов участников.
Если выполнить все эти условия, то будет крайне затруднительно (на мой взгляд — невозможно) использовать код полученный выполнением инструкции из СМС для перевода не соответствующего указанному на картинке.
ЗЫ: данная схема не учитывает вариант, когда телефон пользователя также скомпрометирован.
Sign up to leave a comment.
Двухфакторная аутентификация. Новые вызовы