Как стать автором
Обновить

Надежные пароли будут надежно забыты. Часть 2. Распределенные системы наносят ответный удар

Время на прочтение 5 мин
Количество просмотров 2.7K
Информационная безопасность *Криптография *Распределённые системы *Криптовалюты
Кейс

Прочитать первую часть трилогии можно здесь.

Как мы надежно храним надежные пароли.

Это был конец декабря 2021 года. Мы ехали через Техас и только что благополучно переночевали в El Paso. Низкий тебе поклон, Голливуд, за прекрасные фильмы, такие как "Sicario", после которых у нас тряслись коленки, когда мы въезжали в этот прекрасный город. Продолжаем движение по направлению к Boca Chica, чтобы посмотреть на Starbase (оно того стоит, поверьте). На улице жара +30 и солнечно, приятная летняя погода. В фоне отгоняю от себя мысли о том, что тут творится летом с температурой и людьми. О чем можно думать в этот момент, кроме как о космосе, о будущем и о распределенных системах? Шучу, много о чем можно думать, а не об этих гиковских заморочках :)

В то же время, имея некоторое количество финансов на своем Bitcoin-кошельке, я знал, что люди делятся на две части: те, кто хранит seed-фразу (читай: пароль) на бумажке в шкафу, и те, у кого больше нет Bitcoin'ов. Ни к той, ни к другой категории не хотелось себя причислять, надо было что-то с этим делать. Отступление: в первой части описаны некоторые аспекты и сложности управления секретной информацией, будь то пароль или seed-фраза - не суть важно, проблема остается одна и та же всегда.

Минутка обучения: «Мастер‑пароль» — это особый пароль, это «папа‑пароль». Например:

  • Пароль ко всем паролям — если мы говорим о менеджере паролей.

  • Пароль от квартиры, где лежат деньги лежат (то есть, например, seed‑фраза, если мы говорим о криптокошельках).

Далее мы будем в основном думать над проблемой мастер‑пароля, потому что он особенный. Обычные пароли, которые лежат внутри менеджера паролей, нас не интересуют: с ними всё ясно и, по большому счету, нет никаких проблем.

Возвращаемся к первой проблеме управления паролями. Предположим, мы с помощью менеджера паролей решили проблему хранения обычных паролей. Но какими бы инструментами мы ни пользовались, что бы мы ни делали, всегда есть самый последний мастер пароль, который надо как‑то где‑то хранить, и нет известных широкой публике (мне точно неизвестны) инструментов для надежного хранения мастер пароля, чтобы для этого не понадобился другой мастер пароль.

Хотелось бы например сохранить мастер‑пароль в менеджере паролей, но чтобы получить доступ внутрь менеджера паролей нам нужен мастер пароль, классическая ситуация называемая сatch-22 — a difficult situation from which there is no escape because it involves mutually conflicting or dependent conditions.

И тут, конечно, вы можете сказать: «Подожди‑ка, всё уже давно изобретено, мастер‑пароль не нужен, ты просто не умеешь гуглить». А я отвечу: «Не торопитесь, мы только начинаем».

Диструшка comes to the rescue.

Я начал думать над вариантами, как можно было бы сохранить мастер‑пароль надежно. Все варианты всегда сводились к единой точке — мастер‑паролю, и эта точка всегда была point of failure, потому что, собственно, это одна точка в единственном экземпляре.

А вот подход, который работал хорошо в любой ситуации (если отбросить вопрос небезопасного хранения пароля), это банальное копирование. Например, если у меня есть пароль на бумажке, я записываю его на второй бумажке, кладу в банковскую ячейку, и вероятность потерять мастер пароль уменьшается многократно. Ну, в общем‑то, это настолько банальная вещь и прописная истина, что о ней можно было бы, наверное, и не упоминать, но мне важно показать все шаги развития идеи.

Какое фундаментальное улучшение мы получили в этом случае? Мы получили отказоустойчивость к частичным потерям или сбоям единичных узлов — утрата одной бумажки с мастер паролем не является проблемой, если у нас есть 10 штук в разных местах! А это значит, что мы уже вступаем на территорию распределенных систем, где всё ясно и понятно: CAP‑теорема и все, что мы так любим. Нам только остается красиво и безопасно реплицировать мастер‑пароль между разными устройствами пользователя, и дело в шляпе.

Оффтоп: кто заметили тонкий момент — тому печеньку. Когда мы, люди не можем что‑то запомнить, мы делегируем это внешнему носителю. То есть, знание пароля — это факт «знания секрета», а владение бумажкой с паролем — это «факт владения» секретом! Мы постоянно пользуемся этим трюком даже не замечая этого.

Комната в которой много дверей

Владея несколькими устройствами и имея копии мастер‑пароля на каждом из них, мы получаем в распоряжение могучую силу. Мы можем позволить себе не заморачиваться на запоминании пароля, а позволить магии распределенной системы работать на нас. Потеря одного устройства не будет критичной для нас, и мы сохраняем доступ. Аналогия с комнатой, в которой много дверей, очень хорошо работает в данном случае — потеря одного ключа не лишает нас доступа внутрь комнаты, всегда можно воспользоваться другой дверью.

One ring to rule them all

В нашем случае ровно наоброт: All devices to rule one master password.

Давайте уже переходим к самому интересному. Итак, предположим, мы скопировали мастер‑пароль на все устройства. Какая самая главная проблема здесь возникает? Если одно из устройств будет украдено или потеряно, злоумышленник может получить полный доступ к мастер‑паролю жертвы и, соответственно, ко всем ее паролям, поскольку база данных с паролями хранится на устройстве или в облаке.

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

Но как организовать такую схему? Ведь в нашей схеме нет никаких сотовых операторов или Google Authenticator, которые могут нам обеспечить двухфакторную аутентификацию. А что, если разделить мастер‑пароль на несколько частей и хранить каждую часть на каждом устройстве отдельно? Так сказать лайф‑хак от Волан Дэ Морта (он разделил душу на 7 частей и распихал по разным артифактам). Тогда чтобы на каком‑то устройстве получить мастер пароль, нужно запросить оставшиеся части с других устройств (помните о «факте владения»?). Если получится это сделать, то мы решим проблему. Я думаю вы уже догадались к чему я веду, что является секретным соусом и главным элементом в моем рассказе. Встречайте героя дня: Shamir Secret Sharing Scheme. Эта схема позволит нам разделить пароль с помощью математической магии, части которого мы и сохраним на всех устройствах. Имея одну часть нельзя ничего узнать о самом пароле, получить даже частичную информацию о нем. Это свойство называется perfect secrecy. В нашей схеме одно устройство запрашивает недостающие части с других устройств, и когда эти устройства разрешают операцию и пересылают свои части мастер пароля, устройство может восстановить мастер пароль и открыть им зашифрованную базу данных.

Кстати, поиграться cо схемой Шамира (и да, буква S в алгоритме RSA это тоже Шамир) можно здесь  — кнопочки Split и Recover. Изначально я написал эту веб страничку разделения секрета, чтобы посмотреть насколько удобно будет пользоваться простейшей версией с ручным хранением частей пароля в виде QR кодов.

В linux также есть консольная утилита.

Мы вплотную подошли к заключительной части, которая объеденит все что мы обсуждали в одну систему, и конечно же нам не хватает пары последних компонентов, но об этом в следующей статье.

Теги:
Хабы:
Всего голосов 6: ↑5 и ↓1 +4
Комментарии 26
Комментарии Комментарии 26

Публикации