Verified by Visa

Любопытная статья и еще более любопытный документ. Названия тянут на бомбу, но по сути изложены очевидные вещи. Речь идет о безопасности протокола аутентификации владельцев карты Visa при выполнении ими online-покупок. В целом, мое мнение, чтобы написать подбные "труды" достаточно самому хотя бы раз выполнить покупку картой виза через Интернет и прочитать статью на Wikipedia. Конечно, я делал и то и другое, поэтому позволю себе тут рассуждения. Читать лучше сразу PDF, так как статья содержит в себе еще меньше пользы, хотя размер их соизмерим :-) Полезная нагрузка начинается с главы 2, где повествуется об уязвимостях схемы 3DS.
Самая первая уязвимость, видимо, самая важная - "Confusing the user - hiding security cues" о том, что окно аутентификации при реализации 3DS открывается в iFrame и поэтому не видно домена (а также того, как браузер подсвечивает строку URL с неправильным сертификатом TLS), запросившего аутентификацию. Может, в какой-то мере, это снижает безопасность, но:
1. Ничто не мешает банку аутентифицировать в новом окне браузера, тогда даже и строку URL будет видно со всеми ее подсветками.
2. Легитимность сайта подтверждается его сертификатом. При этом, если сертификат протух, не на тот сайт или выдан неизвестным CA браузер выбрасывает промптер предупржедения в котором подробнейшим образом указана проблема, предлагается посмотреть сертификат собственноручно, и только после добавления в исключения все-таки показать его контент. Обход столь сложной процедуры возможен только если:
-- "зловредный" CA, выдавший сертификат подложному сайту, каким-то образом "протрастщен" (добавлен в доверенные удостоверяющие центры) на endpoint-е => мой endpoint компрометирован => есть масса других способов утащить мои секреты и обмануть меня.
-- секретный ключ CA компрометирован и я об этом не знаю (или никто об этом не знает) и злоумышленники подписывают им сертификаты всем негодяям подряд. На этот риск я не могу сильно вилять => его не следует рассматривать

Отдельно следует поговорить про безопасность endpoint-а. Поскольку это элемент платежной системы, безусловно, к нему должны предъявляться требования. Идеально, если банк мог бы проверить их выполнение, но на практике это крайне сложно, поэтому, в обязательном порядке:
- банк должен давать рекомендации для пользователей сервиса "Online Shopping-а"
- желательно наличие каких-либо сервисов от банков, где можно было бы проверить этот compliance (не обязательно online-овых)
- должна быть четко определена ответственность клиента в данном сервисе: клиент должен отвечать только за полное соблюдение требований, но не за весь сервис.

Да, я тут пишу "банк"... "банк".... Дело в том, что 3DS - это лишь framework, конкретная реализация схемы аутентификации - за банком, поэтому, насколько хороша (надежна, безопасна) схема полностью зависит от банка. Да, есть "глупцы", благодаря которым и появляются все эти наукообразные статьи и "исследования", но есть и вполне себе достойные.

Уверен, что для наведения порядка в этом 3DS, Visa должна выпустить ряд требований к реализации этого 3DS, как это сделано, например в PCI DSS.

Но вернемся к статье.
В П 2.2. "Activation during shopping" указана уязвимость слабой аутентификации клиента, указано, что кто-то спрашивает только день рождения. Согласен, что это бред и процедура здесь должна быть аналогична применяемым в системах ДБО. Где-то это какие-то секретные ключи, за которыми надо пешком сходить в банк, где-то это SMS-уведомления с одноразовыми паролями. Если кто-то реализовал глупость, не следует ее сразу обобщать на всех. Также указано, еще более веселая мысль о том, что сайт запрашивает у клиента персональную информацию и это делает его более склонным к социальной инженерии, когда уже фишеры будут запрашивать то же самое: ответил банку, ответит и фишеру. Даже комментировать не буду :-)

В П 2.3 "Informed consent and password choice" утверждается, что: Пользователь, сконцентрированный на приобретение товара (сценарий activation during shopping (ADS)) будет выбирать слабый пароль. Контроль оцевиден: банк не должен принимать простые пароли и вообще реализовывать политику: сложность, длина, периодическая смена, автоблокировка при неправильных вводах.

П 2.4 "Liability shifting" посвящен тому, что Банк "по-тихому" взваливает всю ответственность за компрометацию на клиента. Это тоже необходимо разрулить Визе (как я отмечал выше): пользовать может (и должен!) следовать только четко указанным требованиям, отвечать за все он не может технически (и не должен!). Снимать ответственность полностью с пользователя - не правильно, так как его endpoint - компонента общей системы и ее компрометаци приводит к компрометации системы.

В п 2.5 предлагается некоторое усиление механизма аутентификации банка у клиента, думаю сертификата вполне достаточно (см выше). Если хочется реализовывать еще и это - лишним не будет.

П 2.6 посвящен раличным чудачествам банков относительно того, как они аутентифицируют клиентов при использовании схемы и при смене аутентификационных данных. Что же в семье, как говорится, не без урода. Требовния от Visa к реализациям аутентификации в 3DS должны решить проблему.

П 2.7 - про Privacy. О этот вечный баланс между Security и Privacy:

Нужно помнить следующее:
1. Про аутсорсинг. Если есть объективные причины мои данные передавать аутсорсеру и аутсорсер обязуется охранять мои данные не хуже банка, какой для меня риск? Я на днях ходил в ГИБДД за справкой о ДТП там на входе мои паспортные данные записали в журнальчик... меня больше беспокоит этот журнальчик, кто его читает, как он утилизируется и т.п. Причем такой журнальчик есть практически везде. А мы тут голову ломаем о том что говорить Роскомнадзору и ФСБ, когда ФЗ-152 - нигде не работает.
2. В конечном счете, меня, как субъекта можно аутентифицировать только моими персональными данными. У меня больше ничего нет.

Сухой остаток:
1. Ждем от Visa требований к реализации протоколов аутентификации.
2. От банков ждем требований по безопасности endpoint-а (кое-где видел, но Visa должна обязать такие требования готовить).
3. То, что аутентификационные механизмы отданы на реализацию банкам - правильно, с Visa только требования и разделение ответственности.