Pull to refresh

Comments 51

Интересная статья. О какой платежке идет речь?
Спасибо, я старался. В статье я писал о репутационных рисках. Именно поэтому я не могу ответить на данный вопрос. Скажу одно: думаю, что о нас Вы слышали.
Многие используют Google Authenticator app, выходит что это ненадежно?
С целями, для которых его разработал Гугл он успешно справляется, а именно для процесса аутентификации в Гугл сервисах. Если мы говорим о подтверждении платежной операции, то это как “микроскопом дверь открывать”:) Надеюсь, ясно, что я имел в виду.
Удалось ли поймать хакеров? Они же как-то выводили деньги.
Поймать кого-то в таких случаях очень трудно, т.к. деньги выводятся на подготовленные для таких ситуаций аккаунты, созданные на фейковые документы или во внешние системы, а с появлением криптовалют отследить что-то иногда представляется невозможным.
Когда высылается смска с паролем, то обычно показывается куда (кому) осуществляется перевод. И юзер на этом моменте может заметить подвох (конечно, если телефон не протроянен). В этом плюс смс и большой минус программных OTP (например, от Google).
Это верно. Мы тоже на это надеялись, но есть несколько моментов: 1) ОТР в смс не привязан к данным и может быть ситуация, когда в СМС попадет “нужная” информация; 2) смс может быть перехвачено, дублировано и т.д. 3) Не все пользователи обращают внимание на что-то еще, кроме ОТР в таких смс. К тому же, смс имеет ограничение на длину сообщения, и не все параметры, которые могут быть подвергнуты атаке реально отобразить в одном сообщении, например баланс до и после транзакции и т.д.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

Ну и в СМС можно сразу открытым текстом писать «перевод денег с вашего счета на Васю Пупкина» + в случае, если идет перевод денег на счет ранее никогда не используемый владельцем, дополнительно что-то делать — запрашивать еще одно подтверждение и т.д.

Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

Скорее всего, связь кодов подтверждения была не с транзакциями, а с телефоном пользователя, т.е. подтверждалась не сама транзакция, а то, что человек владеет телефоном.
Ну это очень и очень плохо с точки зрения безопасности. ИМХО.
как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?


Если я всё верно понял, то не обязательно так. Схема может быть такая:

1. Юзер пытается сделать операцию «кинуть 100 рублей на телефон».
2. Вредонос анализирует этот запрос и формирует страничку, визуально выглядящую, как запрос кода подтверждения для этой операции…
3.… но в банк отправляет данные на запрос подтверждения для «кинуть все деньги на аккаунт Мистера Х»
Т.е. юзер делает операцию «кинуть 100 рублей на телефон» в фейковом интерфейсе, а бот в это время делает в реальном перевод на другой аккаунт?

Если так, то я не правильно понял ситуацию.

В этом случае спасает сообщение + двойное подтверждение, ибо врядли до этого юзер имел дело с аккаунтом данного мистера.

Есть еще одна штука, почему не читают сообщения с OTP — очень часто они засраны рекламой, если этого не было — пользователи были бы более внимательны.
Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

Вы говорите о варианте 2 (см. статью), но в этом пункте описан просто один из возможных вариантов развития событий.

В нашей системе привязка OTP к транзакции существовала, но злоумышленниками была подделана часть важных параметров в самой транзакции.

Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.

OTP и так запрашивался, какие дополнительные средства защиты Вы имеете в виду?
Грубо говоря следующие действия:
1) от имени юзера происходит операция, запрашивается OTP на нее
2) на телефон юзера приходит сообщение «Перевод XXX рублей на счет ZZZZ, если вы подтверждаете это, используйте код YYYY
3) пользователь не читает, вводит YYYY
4) система в банке проверяет, имел ли дело данный пользователь с этим счетом, если нет — генерит еще один OTP
5) приходит еще одна смс — вы не разу не работали с данным счетом и действительно хотите перевести на него XXX рублей? Для подтверждения используйте код CCCC

На второй раз пользователь очень вероятно, что поглядит текст СМС. Это не панаяцея, но думается, что большинство людей не попадутся.
Главное, что сообщение об отсутствии взаимодействия с данным счетом приходило именно вторым, не первым. Первое никогда не читают.
Я бы проклял такой сервис :)
А потерять все деньги? Что лучше?

Во-вторых, еще раз — в случае публичных компаний Вы вообще ничего не заметите — OTP будет один.
Думаю, что в предложенном подходе есть недостаток, т.к. Вы предлагаете использовать второй раз тот же самый фактор (смс-ки), а он может быть скомпрометирован. Надо использовать другой фактор, но среди пользователей не будет популярен такой “удобный сервис”.

Многие не включают даже простую двухфакторную аутентификацию, что говорить о таких сложных пируэтах )
Если таких вариантов не много (подозрительные транзакции) — я, к сожалению, не знаю статистики — но Вы знаете — может есть вариант обзванивать данных пользователей, до подтверждения транзакции со стороны банка ( т.е. после OTP от пользователя ).

Если же их много, то да, вопрос, как обойтись…
UFO just landed and posted this here
При этом перевод с карты на карту выглядит как «Сбербанк Онлайн. Внимательно проверьте реквизиты операции: карта списания **** XXXX, карта зачисления **** YYYY, сумма ZZZZ RUB. Пароль для подтверждения данной операции — AAAA» и всё. Из этого длинного сообщения ценной информацией является только YYYY, а это всего 4 цифры. Хотя при оплатах через платёжные шлюзы смска выглядит вполне лаконично: «назначение (RUB сумма) пароль: цифры. Не сообщайте этот пароль никому, в том числе сотруднику Банка»
UFO just landed and posted this here
А я, когда приходит смс, смотрел в статус бар, пока он не прокрутит до кода подтверждения. Благо фильтровать информацию с сайтов умею и попадаюсь на зловреды ну максимум раз в пару месяцев. Теперь буду внимательным :)
UFO just landed and posted this here
запрашивать доп. OTP ну и все

двойное подтверждение

Вы не могли бы привести реальные примеры, где на одну операции отправляется 2 OTP?
Я могу ошибаться, но с точки зрения пользователя это не очень удобно.
Любая защита — это вообще не удобно для пользователя.
Тут соблюдается баланс — в случае, если пользователь имеет отношение с публичными компаниями — OTP будет спрошен один раз. Это не доставит никаких неудобств.
В случае подозрения будет спрошено два раза — это во-первых даст возможность в случае проведения таки такого платежа, ткнуть, что Вас предупреждали два раза, во-вторых сильно повысит внимательность пользователя, но да, через его неудобство, увы.
Зачем все эти сложности? В статье описан более удобный и дешевый (ведь каждая дополнительная отправка SMS стоит денег) способ защиты, который позволяет избежать неудобств пользователя и дополнительных расходов системы, связанных с двойной отправкой OTP, и при этом отлично справляется с угрозами автозалива и реплейсмента.
Вы про CWYS?
Там тоже не все гладко, если пользователь работает через фейковый интерфейс, то все данные за него формирует он.

Ну или я не понимаю технологию. Смотрите:
1) пользователь в фейкфейсе делает транзакцию на 100 рублей
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
3) пользователь вводит код (который от совсем другой операции) и подтверждает его
4) и где защита?
Есть несколько точек контроля: во-первых, в приложении отображается информация о том, куда реально уйдут деньги (как и для случая с смс); во-вторых, есть встроенные механизмы контроля целостности и согласованности данных фронтэнда и бекэнда, которые получают информацию по разным каналам; в-третьих, забегая наперед, генерация ОТР и подтверждение транзакции происходит в несколько этапов, при подмене данных между этапами взаимодействия, ОТР попросту будет не валиден.
Мне тоже интересно, но ответ я не понял. Зловред полностью контролирует клиентскую сторону, с точки зрения бэкенда все будет совершенно валидно — пользователь хочет перевести все деньги на другой аккаунт и зловред предоставил для этого все данные. Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта. Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта.

Да, они говорят серверу
Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.

Для данного кейса этого достаточно для предотвращения кражи
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей

В этом случае пользователь получит сообщение, что он переводит 1000р (кому и какой баланс) и пункт №3 не произойдет.
Изначально посыл был в том, что пользователи далеко не всегда читают то, что пришло с кодом подтверждения. Т.е. CWYS здесь ничем не лучше обычных OTP — про что я, собственно, Вам и написал :) И в данном случае он ничем не поможет, ИМХО. Пользователь тупо подтвердит транзакцию, ну да, зато теперь подписанную :)
По поводу примеров.
Могу привести Райфазен, правда там было не совсем OTP ))

При подозрительной транзакции, после подтверждения со мной связались из банка, проверили меня секретным вопросом и уточнили, реально ли я хочу сделать данную транзакцию.
Звонившие как нибудь подтвердили что они именно из банка вам звонят?
Да-да… пришла тут на днях СМСка «ваша карта скомпромитирована, срочно позвоните в сбербанк и городской номер +7812....»
Если бы не номер с которого пришла СМС — +44… я бы возможно дернулся позвонить или по крайней мере достать карту и посмотреть на ней номер Сбера (+8800...)
Звонок был с номера банка, звонившая была моим менеджером этого банка (представилась, назвала ФИО и должность — я уже работал с ней в этом банке) и сказала секретную фразу банка — так что подтвердили 3 способами ;)
UFO just landed and posted this here
Можно было сделать так:
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. на странице банка(платежной системы) информация выводится в виде картинки примерно такого вида
image
2. по СМС приходит инструкция примерно следующего содержания:
Для подтверждения перевода на сумму ХХХХХ.ХХ со счета ЯЯЯЯ на счет ОООО введите сумму первых 3-х зеленых цифр а затем с 3-й по 8-ю красную цифру

Цветовая схема капчи и условия ввода в инструкции должны быть индивидуальными для каждой операции, и подобраны так, чтобы исключить анализ цветовой схемы и содержания условий ввода по данным введенной пользователем.
Условие ввода должно включать в себя важные (ключевые) данные о переводе. То есть в него должны войти цифры из суммы перевода и номеров счетов участников.

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

ЗЫ: данная схема не учитывает вариант, когда телефон пользователя также скомпрометирован.
Only those users with full accounts are able to leave comments. Log in, please.

Articles