Конечно, надо доверять сервису. Так же как надо доверять УЦ. И много кому еще приходится доверять.
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
выполняется кража конфиденциальных данных онлайн-банкинга за счет внедрения на легитимные-страницы фишингового содержимого.
Что все-таки делает этот зловред: крадет конфиденциальные данные или подменяет платежки? Если крадет данные, то зачем внедрять фишинговое содержимое? Опишите, пожалуйста, подробнее.
По сути вы придумали систему для защиты от подбора паролей. Эта система блокирует неизвестных пользователей до прохождения ими аутентификации по OTP.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.
Аутентификация же.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
Это какой-то SSM. Слово Hardware означает все-таки, что должен быть аппаратный модуль. Вся суть в том, что в аппаратном модуле есть защиты от вторжений, в том числе, от аппаратных вторжений. Вы не сможете, например, считать содержимое оперативной памяти HSM. При попытке практически любого внешнего несанкционированного воздействия содержимое HSM просто сотрется.
То есть все-равно иногда нужно подгружать что-то из сети. Непонятна фраза, что в смартфоне необходимые и достаточные данные. Достаточные они только для нескольких платежей, а потом нужно опять скачивать LUK. Я имею в виду, что это не полностью автономная система, и она требует периодического доступа к сети интернет.
Токенизация как раз отлично ложится на бесконтактную оплату смартфоном. Даже в спецификации EMV по токенизации (Payment Tokenisation Specification) первый use case называется: Use Case 1: Mobile NFC at Point of Sale.
Сама суть токенизации — подмена важной/секретной/чувствительной информации малополезным для злоумышленников токеном. В случае с бесконтактной оплатой подмена PAN токеном позволяет сберечь виртуальную карту от компрометации в точке обслуживания.
Данные, необходимые и достаточные для осуществления NFC-платежей, хранятся непосредственно в памяти смартфона
Ничего дополнительно для транзакции не подгружается? LUK (Limited Use Keys) то должны прийти для каждой транзакции свои или вы как-то по-другому реализовали?
Планируете ли вводить токенизацию?
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
Что все-таки делает этот зловред: крадет конфиденциальные данные или подменяет платежки? Если крадет данные, то зачем внедрять фишинговое содержимое? Опишите, пожалуйста, подробнее.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
Токенизация как раз отлично ложится на бесконтактную оплату смартфоном. Даже в спецификации EMV по токенизации (Payment Tokenisation Specification) первый use case называется: Use Case 1: Mobile NFC at Point of Sale.
Сама суть токенизации — подмена важной/секретной/чувствительной информации малополезным для злоумышленников токеном. В случае с бесконтактной оплатой подмена PAN токеном позволяет сберечь виртуальную карту от компрометации в точке обслуживания.
Ничего дополнительно для транзакции не подгружается? LUK (Limited Use Keys) то должны прийти для каждой транзакции свои или вы как-то по-другому реализовали?
Планируете ли вводить токенизацию?