Аутентификация в распределенной блогосфере
Jan. 8th, 2013 05:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
О существующем положении вещей
Практика показала, что OpenID довольно плохое решение для "бегства из ЖЖ". Пока ЖЖ лежит, никто блог и не комментирует, поскольку аутентифицироваться через OpenID не может.
Вообще, OpenID за те годы, которые прошли со времен его изобретения Фицпатрикром испортился. Исходно идея была очень симпатична - человек, приходя комментировать в чужой блог, представляется URL своего блога. Представляться комментатор должен для того, чтобы у него накопилась репутация. Очевидно, что "владелец такого-то блога" это вполне себе репутация.
К сожалению, в сети тут же развелись всякие сервисы, которые предоставляют OpenID с URL, которая не содержит никакой информации о человеке, псевдониме или персонаже, от имени которого комментатор аутентифицируется.
Особенно, тут отличился гугль. У которого URL вообще неудобочитаема. Конечно, с тех пор в OpenID появлись всякие расширения, которые позволяют запросить определенную информацию о том, кто аутентифицировался. Но нужна ли эта информация читающим блог? Ну ладно E-Mail, он нужен самому блогодвижку, чтобы комменты на почту отправлять. Но всё остальное? Самого главного-то что пользователя как-то характеризует - какой-нибудь ссылки на то, что он ещё написал в интернете, нет.
Кстати, если подумать, то требование чтобы в момент регистрации пользователя его OpenID провайдер был online есть содержательный смысл. Ведь куда мы пойдем для того, чтобы что-то узнать о пользователе? На ту URL, которая является его claimed identity. Ничего другого у нас всё равно нет. Если пользователь у нас не первый раз, то можно просто когда он первый раз (при активном своём сервере) аутентифицируется, выдавать ему уже местную куку на месяц-другой, как делает lj.rossia.org.
Еще хуже с так называемыми "социальными сетями". Почему в этом блоге нету аутентификации через фейсбук или вконтакте? А потому что для того чтобы хотя бы прочитать девелоперскую документацию, нужно иметь аккаунт в этих сетях. А у меня его нет и я его заводить не хочу.
Не говоря уж о том, что для аутентификации через OAuth, поддеживаемой этими сетями, любой сайт, желающий аутентифицировать своих пользователей должен зарегистирроваться у соответствующей социальной сети и получить там некий секретный код, который использовать при обмене. То есть решению своего пользователя пойти на этот сайт они не доверяют. Они еще хотят и сам сайт заранее знать.
О том, чего хотелось бы
Что такое, на мой взгляд, распределенная блогосфера?
Это множество разных серверов, на каждом из которых может быть от одного блога, до нескольких тысяч, которые используют самый разный софт, кому какой удобно, самую разную политику по отношению к содержимому и так далее, но при этом все позволяют комментировать друг у друга без дополнительной регистрации на каждом сервисе, и обеспечивает устойчивость к высоким нагрузкам, то есть каждый блог тем доступнее, чем больше людей его регулярно читают.
Последнее можно достаточно легко организовать, если в рамках создания френдленты - общей ленты читаемых пользователем постов, кэшировать у себя все читаемые им блоги, позволять в кэшированных копиях комментировать.
Потребуется, конечно, какая-нибудь процедура для поиска пользователем наиболее доступной (либо ближайшей, либо наименее загруженной) копии блога. Но по-моему, чего нельзя категорически, так это требовать ради этого наличия у пользователя какого-либо софта, кроме стандартного браузера. Читать блоги должен иметь возможность любой аноним с браузером. Писать/комментировать - уже можно предъявлять несколько более высокие требования.
Но опять же надо зарекаться на то, что родной любимый сервер данного пользователя может быть в данный момент offline - то-ли затоплен водой вместе с датацентом каким-нибудь ураганом, то-ли конфискован злой полицией тоталитарного режима какого-нибудь Тувалу.
Я уже как-то раз предлагал систему аутентификации, основанную на встроенной в браузеры поддержку авторизации по клиентским сертификатам в HTTPS. Благо, утверждение, что сертификат обязательно должен быть выдан каким-нибудь коммерческим удостоверяющим центром - это неправда, и наш серверный софт вполне может работать удостоверяющим центром для своих клиентов. Это хорошо тем, что
- Используются надежные криптографические алгоритмы и протоколы.
- В этих протоколах предусмотрен срок действия сертификатов
- Предусмотрена процедура отзыва.
Плоха эта процедура в первую очередь тем, что требует наличия закрытого ключа на компьютере пользователя. На самом деле есть ещё андроиды <4, которые не умеют работать с посторонними удостоверяющими центрами, и более новые андроиды, которые не хотят с ними работать, если отключены блокировка устройства.
Но вот придумать процедуру авторизации, которая не требовала бы наличия в интернете (в данный момент) сервера, которому пользователь полностью доверяет, и на котором можно хранить секрет, и не требовала хранения какого-то достаточно объемного (не вмещающегося в человеческую память) секрета при пользователе, довольно сложно. Хэшированный пароль с солью - это секрет. Его нельзя делать публично доступным, как это было в юниксах 1970 года - словарные атаки на современном железе весьма эффективны. В принципе, можно попробовать распространять вместе с RSS-фидом блога что-нибудь симметрично-зашифрованное с помощью PBKDF2 или scrypt. Тогда серверный софт несущий любую копию данного блога сможет аутентифицировать его владельца.
Тут возникает, правда, вопрос, а достаточно ли доверяет пользователь серверу, на который он пришёл комментировать, чтобы вводить там пароль, дающий доступ ко всем копиям его блога? Собственно одна из причин распространения протоколов вроде OpenID и OAuth заключается в том, что свой пароль пихать куда попало не следует.