Эта задачка возникает, когда один человек заводит несколько аккаунтов. Конечно, есть способы «регистрации», которые действительны сразу на многих сайтах:
- все веб-сайты в одной доменной зоне и администрируются одним человеком;
- OpenID;
- клиентский сертификат SSL.
Но сейчас о ситуации, когда несколько аккаунтов уже есть.
Действительно ли владелец аккаунта А владеет также аккаунтом Б? Очевидный способ проверки следующий: если ты владеешь аккаунтом Б, значит ты управляешь аккаунтом Б, значит ты можешь написать что-нибудь от имени аккаунта Б. То есть нам нужно, чтобы из аккаунта Б вышло сообщение: владелец аккаунта А управляет также и данным аккаунтом. Обозначим через А~>Б факт выхода такого сообщения. Таким образом, мы определили бинарное отношение ~> .
Если вы решили, что А~>Б означает аккаунтами А и Б владеет один человек, вы ошиблись. Строго говоря, владелец аккаунта Б по собственной инициативе и без чьего-либо разрешения может создать факт А~>Б. Отличить такую ситуация никак нельзя. Что же на самом деле означает А~>Б?
Рассмотрим такой немного наивный пример. Известно, что аккаунтом А владеет нобелевский лауреат, и аккаунтом Б владеет директор завода. А~>Б истинно. Если аккаунт А выдаёт мнение, это авторитетное научное мнение. Если аккаунт Б выдаёт приказ, работники завода обязаны его исполнить. Что, если аккаунт Б выдаст мнение? Так как может быть, что А~>Б возник без согласия владельца аккаунта А, то есть без согласия нобелевского лауреата, то мнение не является авторитетным научным мнением. Что, если аккаунт А выдаст приказ? Всё наоборот, то есть работники обязаны исполнить этот приказ. Никто же не заставлял директора завода создавать факт А~>Б.
Общее правило такое: если А~>Б, то ресурс переходит от Б к А. В моём примере нобелевский лауреат имел ресурс научный авторитет и директор завода имел ресурс административная власть на заводе.
Вернёмся к определению А~>Б. Иногда его изменяют следующим образом: требуют, чтобы из аккаунта Б вышло сообщение, содержащее некоторый код или ключ (последовательность букв и цифр). якобы этот код обязателен для подтверждения, ля-ля-ля. Если вам такое предлагают, не соглашайтесь ни в коем случае. Эта схема уязвима для атаки man in the middle.
Описание атаки. Допустим, аккаунт М передаёт код К аккаунту А. Владелец аккаунта А публикует код из-под аккаунта Б. Хитрость в том, что М получил К от некоторого аккаунта В. Ситуация выглядит так, что В передаёт К аккаунту М и К выходит из-под Б. Отсюда В делает вывод, что владелец М управляет также Б, что неверно. Может, вы догадались, почему аккаунт М назван М от слова мошенник. М и является тем самым мэном in the middle.
