OpenID & phishing, продолжение

Идею, описанную во вчерашнем посте, подхватил Дмитрий Шехтман.
Он значительно упростил ее, также добавив некоторые аспекты, о которых я до этого не подумал. Разберу его замечания, и добавлю кое-что от себя.

Итак, его резюме всей идеи:

1. При каждой успешной попытке аутентификации при помощи логина и пароля, OP устанавливает secure (подразумевается, что аутентификация должна происходить только в режиме HTTPS) cookie. Имя cookie получено при помощи username/userId, что решает проблему, когда несколько пользователей одного OP используют один и тот же браузер. В этом случае браузер может хранить несколько cookies для разных пользователей. Значение cookie - случайная строка, полученная из источника с высокой энтропией (в этом случае ее трудно будет подделать.


2. OP дает возможность аутентифицировать клиента при помощи логина и пароля только при наличии у него выданной cookie.


3. При попытке использовать cookie в короткое время после ее получения, OP регистрирует подозрительную операцию, и извещает о ней пользователя по email.

Для проблемы, которая возникает, если у пользователя такой cookie нет, Дмитрий предложил простое решение — для пользователя генерируется одноразовый пароль, и отправляется пользователю на email, после чего процесс аутентификации приостанавливается.

Кроме того, Дмитрий предложил снабдить форму для аутентификации визуальным элементом - site seal, который показывается только при наличии необходимой cookie.

Разбираем проблему дальше. Что я вчера не учел, так это то, что OP в момент попытки авторизации знает Claimed Identifier, т.е. тот OpenID-идентификатор, который пользователь вводит на удаленном сайте. Соответственно, зная кому он выдал cookie, и кому принадлежит предложенный OpenID-идентификатор, OP может сравнить эти значения, и принять соответствующие меры, если в списке предоставленых cookies не нашлось ни одной, которая принадлежит предоставленному claimed identifier. Причем, он может принять решение еще еще до момента вывода формы для ввода логина и пароля!

Само собой, для этого необходимо как-то связывать выданную cookie с пользователем OP. Сервер должен хранить список выданных cookies, связанных с пользователями. При этом может быть несколько cookies, если они выданы разным браузерам. Само собой, у cookie есть lifetime, после которого записи очищаются. Если новая cookie выдается взамен старой, то старая удаляется. И, конечно, весь этот механизм работает только если пользователь не отключил cookies.

Таким образом, мы имеем довольно надежный механизм, который становится еще проще:

1. Форма для логина выводится пользователю только в случае, когда у пользователя есть cookie, который есть в таблице соответствий, причем Claimed Identifier должен принадлежать тому же пользователю, которомы cookie была выдана. Браузер может предоставить несколько cookies, при этом одна из них должна соответствовать.


2. Если cookie не найдена, то пользователю отправляется email с one-time password. Выводится соответствующая форма для ввода one-time password.


3. При успешной аутентификации пользователю устанавливается cookie. Если она используется через достаточно короткий срок, то, как и раньше, подозреваем мошенничество и извещаем всех кому надо.

Последние два пункта требуют пояснения.
Авторизация при помощи логина и пароля обычно подразумевает, что пользователь получает аутентифицированный сеанс на сайте OP (ему выдается сеансовая cookie, содержащая идентификатор сеанса на сервере, который содержит информацию о пользователе). Это позволяет пропустить процедуру аутентификации по логину и паролю в следующий раз когда пользователь попросит подтвердить его OpenID-идентификатор.
В том случе, когда пользователь идентифицируется в нашей схеме по one-time password, так делать не следует, т.к. в этом случае фишер, хотя и не получив постоянный пароль пользователя, тем не менее получит идентификатор сеанса, что позволит ему войти на сайт без ввода этого пароля. Одноразовый пароль должен быть использован только с одной целью — подтвердить OpenID-идентификатор удаленному сайту, на котором он был введен.

Что касается очень скорого использования cookie. Ранее я рассматривал ситуацию, когда evil proxy выписывает себе cookie прямо перед тем как запросить страницу аутентификации для пользователя-жертвы. Т.к. мы теперь знаем, надо ли выводить форму, прямо в начале запроса (сравнением принадлежности cookie и claimed identifier), то такая атака становится невозможна. Однако становится возможен другой вариант атаки — запись выданной cookie после ввода one-time password, и перенаправление пользователя опять на форму аутентификации, но уже передавая от его имени на сайт OP выданную немного ранее cookie!
Еще один вариант решения этой проблемы — по one-time password не только не аутентифицировать сеанс пользователя, но также и не выдавать ему cookie для последующей аутентификации по OpenID. Для того, чтобы получить cookie, пользователь должен честно войти хотя бы раз на сайт при помощи логина и пароля, при этом этот вход должен быть вне процедуры подтверждения OpenID-идентификатора.

Решает ли этот механизм все проблемы? К сожалению, нет.
Этот механизм решает проблему в том случае, если фишер использует проксирование реального сервера OP. Однако, фишер может использовать и специально сконструированные страницы на своем сервере, и собирать данные так, что реальный OP даже знать об этом ничего не будет. Конечно, в этом случае у него не будет шанса удостовериться, что введенные логин и пароль соответствуют действительности, но, как мы понимаем, это — небольшая для него проблема.

UPD. Решение - в комментарии Дмитрия. Я не сразу понял всю мощь идеи site seal. Site seal в нашем случае - это картинка, загруженная самим пользователем при регистрации или включении OpenID-идентификатора! В этом случае пользователю просто нужно запомнить эту картинку, и потом обращать внимание, показана ли она вместе с формой. Всё, проблема решена.

Как всегда, приветствуются комментарии.