Окремо слід поговорити про безпеку endpoint-а. Оскільки це елемент платіжної системи, безумовно, до нього повинні пред'являтися вимоги. Ідеально, якщо банк міг би перевірити їх виконання, але на практиці це вкрай складно, тому, в обов'язковому порядку:
- банк повинен давати рекомендації для користувачів сервісу "Online Shopping-а"
- бажано наявність будь-яких сервісів від банків, де можна було б перевірити цей compliance (не обов'язково online-ових)
- повинна бути чітко визначена відповідальність клієнта в даному сервісі: клієнт повинен відповідати тільки за повне дотримання вимог, але не за весь сервіс.
Так, я тут пишу "банк". "Банк". Справа в тому, що 3DS - це лише framework, конкретна реалізація схеми аутентифікації - за банком, тому, наскільки хороша (надійна, безпечна) схема повністю залежить від банку. Так, є "дурні", завдяки яким і з'являються всі ці наукоподібні статті і "дослідження", але є і цілком собі гідні.
Упевнений, що для наведення порядку в цьому 3DS, Visa повинна випустити ряд вимог до реалізації цього 3DS, як це зроблено, наприклад в PCI DSS.
В П 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 тільки вимоги і поділ відповідальності.