tgoop.com/reinforced_sc/87
Last Update:
Многофакторная аутентификация
Я испытываю фейспалм всякий раз, когда натыкаюсь на криво прописанную логику многофакторной аутентификации. Происходит это в самых разных продуктах: Яндекс, Альфа-Банк, Открытие, Кинопоиск. Меня это бесит, поэтому я давно хотел сделать обстоятельный пост мини-продуктового анализа вокруг многофакторной аутентификации. Вот он.
Что вообще такое "фактор аутентификации"? Вот смотрите, есть у нас пользователь Вася. Системе, которая предоставляет Васе персонифицированные услуги, нужно как-то быть уверенной что Вася — действительно тот, за кого себя выдаёт. Для этого Васе надо привести какие-то аргументы. Они и называются "факторы аутентификации". В современном мире кибератак и утечек данных, важно предоставить Васе как можно больше таких факторов. Поэтому и появилось MFA.
Базовым фактором аутентификации до сих пор остаётся логин и пароль. Он должен быть всегда. Даже если пользователь зашёл через "одноклассники", эти базовые установочные данные ему нужно сгенерировать. Тут есть некоторое пространство для манёвра: можно отправить сгенерированный пароль по потенциально скомпрометированному каналу данных (e-mail, SMS). Можно сгенерировать одноразовый пароль и заставить пользователя сменить его, что плохо скажется на UX, но хорошо скажется на безопасности.
Само собой на стороне бекенда пароли должны быть хэшированными и посоленными. Желательно несколько раз. Каждая новая соль в пароль усложняет жизнь злоумышленнику, решившему пойти по вектору атаки "спиздить данные". Если соли нет — достаточно стащить базу данных. Если соль задаётся в конфиге приложения — конфиг тоже придётся утащить. Если соль вшита в код, то придётся упереть ещё и исходники. Каждая следующая точка соления повышает цену всего вектора атаки, вынуждая злоумышленника в конце концов отказаться от этой идеи.
Но какие факторы есть помимо логина и пароля? Тут есть из чего выбрать:
— авторизация через OpenAPI соцсети
— по клиентскому сертификату
— одноразовый код, присланный по e-mail или телефон
— список одноразовых паролей
— ответы на секретные вопросы
— MFA через мобильное приложение Authenticator от Google/MS/whoever. Там внутри ГПСЧ, синхронизирующий seed с системой. Иногда такой Authenticator имеет аппаратный корпус и называется PIN-калькулятор. Странно что российские банки до этой идеи не додумались.
Прикольный фактор аутентификации был когда-то у Facebook: тебе показывали аватарки твоих друзей и предлагали ответить как кого зовут. Готовы осознать все грани собственной асоциальности? :)
Это далеко не полный список. У каждого фактора есть своя специфика работы, но выстраивая их систему надо уметь сделать правильные трейд-оффы между UX и безопасностью. Увы, это как раз тот случай когда одно исключает другое.
Пользователи могут тупо терять некоторые факторы аутентификации. SIM-карта может сломаться, пользователь может уехать в другой регион. Пароль можно забыть, друзей не иметь, e-mail удалит спам-фильтр, а телефон сменится на новенький-чистенький айфон, в котором нет приложения Authenticator. Потеря фактора адово просаживает UX и чем быстрее мы поможем пользователю восстановить доступ — тем лучше.
Но иногда факторы аутентификации крадут. Крадут пароли, братья и сёстры знают друзей, близкие знают ответы на секретные вопросы, e-mail могут угнать, телефон украсть, а SIM-карту скопировать. В этом случае, вор предъявит нам один из факторов и будет требовать пустить его. Чем раньше и жестче мы ему откажем — тем лучше. Парадокс!
Многофакторная аутентификация основывается на предположении, что все факторы одновременно не украдут и не потеряют. Но, как видите, вопрос довольно щепетильный и политику MFA надо калибровать индивидуально под каждую систему. Желательно, с диаграммами и картинками.
Такие дела
BY Novikov on Soapbox
Share with your friend now:
tgoop.com/reinforced_sc/87