По сути вы придумали систему для защиты от подбора паролей. Эта система блокирует неизвестных пользователей до прохождения ими аутентификации по 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) то должны прийти для каждой транзакции свои или вы как-то по-другому реализовали?
Планируете ли вводить токенизацию?