P2P блоггерская сеть: Система аутентификации
Возвращаемся к уже подзабытой теме p2p блоггерской сети.

Сегодня — о проблеме аутентификации. Она уже обсуждалась в контексте проблемы роутинга, но чуть позже выяснилось, что проблема надёжной доставки пакетов разрешима и без аутентификации, а только лишь заменой DHT-метрики на криптографически необратимую.

Но аутентификация всё равно необходима для контроля авторства постов и комментариев. Как же её проводить, с учётом того, что сеть децентрализованная и authentication authority не может существовать в принципе?
...В действительности, существует простой вариант. Но не очень удобный для юзеров. Но надёжный. И идеально подходящий для P2P. Я о нём не писал раньше, т.к. считал, что удобство прежде всего, а криптографическая надёжность - на втором месте. Но в последнее время в ЖЖ участились случаи взлома аккаунтов, которые меня переубедили. Вот несколько недавних:
1. doctor_liza@lj (подтверждение СУП)
2. Взлом блогов w_i_s_e@lj
Итак, драфт аутентификационного протокола.
1) При создании нового аккаунта юзер выбирает себе имя (никнейм). Проводится DHT-поиск, чтобы убедиться, что никнейм ещё не занят.
2) Далее клиентское ПО генерит пару RSA-ключей: открытый и закрытый. Разрядность: 4096 бит. Открытые ключи не должны повторяться, поэтому ГПСЧ для алгоритма генерации RSA-ключей инициализируется GUID-ом, а дальнейшие биты получаются в результате применения хэш-алгоритма whirlpool к паре предыдущий блок + порядковый номер блока.
3) Сообщения (посты) распространяются по P2P сети в виде файлов формата XML, в котором, кроме текста сообщения в формате XHTML 1.0 Strict, есть: дата опубликования в UTC, никнейм автора (используемый для DHT-индексирования постов одного автора), открытый ключ автора, аватарка и электронная цифровая подпись, заверяющая все остальные поля.
4) Каждый узел сети, пропуская через себя этот XML-файл, обязан убедиться, что:
- цифровая подпись под постом соответствует остальным полям и открытому ключу
- DHT-поиск самой ранней записи по никнейму автора даёт запись с тем же самым открытым ключом, что и в проходящем XML-файле.
Если хоть одно из этих требований не выполнено, узел должен отказаться распространять этот файл (сделать вид, что он об этом файле ничего не знает).
5) Узел, создавший XML файл, тоже проводит вторую проверку, но в случае её провала уведомляет пользователя и предлагает ему создать другой аккаунт или восстановить другой ключ из бэкапа.

Пара ключей - это то, что заменяет пароль. Они хранятся в отдельном файле, размером в пару килобайт, и который можно перенести на другую инсталляцию P2P клиента, и продолжить работу. Правда, на бумажку его не запишешь, а если даже напечатать на принтере (примерно страничка получится), то быстро и без ошибок не введёшь. Хотя можно предусмотреть и такую возможность, разбивая каждую строчку на группы по 5 символов (как в серийном номере Винды), а в конце каждой строчки в скобках указывая контрольную сумму (которая наборщиком сверяется с той, что отображается на экране).

Длинный ключ, конечно, неудобен, по сравнению с коротким паролем. Но практика ЖЖ показала недостаточную надёжность системы аутентификации, основанной на коротком пароле.

источник-waqur@lj

читать полный текст со всеми комментариями