Сложная система - не сложная, а просто так описана
В предыдущей статье, я описал свой сетап хранения авторотационных данных (паролей). Многие эксперты изучили её и дали свои комментарии, - о том, где могут быть проблемы, о том, что можно упростить, и о том, что можно делать по другому.
Но начнём мы с небольшого объяснения, почему система такая сложная. Вспомним суть:
Для логина на "не значимые" сайты (например в аккаунт очередного AI-продукта) мы используем уникальный пароль, который храним в программе хранения паролей (парольном менеджере)
Для логина на "более важные ресурсы" (например в аккаунт на github), мы используем уникальный пароль, который храним в парольном менеджере, плюс одноразовый пароль (TOTP - Time-based One-Time Password) который нам покажет специальное приложение на телефоне.
Вот и всё. Это вся суть повседневного использования всей системы. Но почему она тогда казалась такой сложной? Вероятно из-за дополнительных слоёв защиты от самого себя или любых непредвиденных факторов. А именно:
Защита от того, что мы потеряем телефон. Создание и хранение копии настроек приложения с одноразовыми паролями, что бы можно было его настроить на новом телефоне.
Защите от того, что менеджер паролей перестанет работать. Создание и хранение копии всех паролей в отдельном файлике.
Защита от того, что мы забудем главный пароль от менеджера паролей. Создание и хранение распечатанной копии главных паролей.
Поскольку эти меры предосторожности создают новую дыру в безопасности, нам приходится усложнять систему, и шифровать запасные копии:
Шифруем копию настроек TOTP (паролем от приложения одноразовых паролей)
Шифруем копию всех паролей из менеджера (паролем от парольного менеджера)
Режем копию паролей на листике на 3 части по схеме Шамира и прячем в разных местах.
В качестве парольного менеджера используем Bitwarden.
В качестве TOTP используем Aegis.
В качестве инструмента деления записки с паролями используем Bananasplit.
В качестве шифратора используем Picocrypt.
Почему нельзя использовать 1 пароль повсюду
Использовать один пароль везде - это очень популярная схема. Она удобна и естественна. Как только вы впервые в жизни сталкиваетесь с регистрацией, вы придумываете пароль. На второй регистрации вы не тратите время и используете уже придуманный пароль. И так далее.
Так длится до тех пор, пока один из сайтов не откажется принимать ваш пароль, сославшись на плохую сложность пароля. Дальше есть 2 варианта: вы придумываете более сложный пароль, либо вы модифицируете первый пароль, добавляя в него дополнительные цифры и символы.
У такого подхода есть 2 проблемы:
В какой-то момент вы начнёте путаться, где какая версия пароля: где просто пароль, где с цифрами, где с символами.
Рано или поздно, один из "незначимых" сайтов взломают хакеры и узнают ваш пароль. Это может быть какой-то старый форум, на котором вы по быстрому зарегистрировались, что бы всего 1 раз получить какую, то информацию. А в итоге хакер получит тот же пароль, который вы используете на своей почте.
Проблема хитрых алгоритмов вместо парольных менеджеров
Есть хитрый способ использовать везде разные пароли и всё помнить без менеджера паролей. Нужно просто придумать собственный алгоритм генерации паролей.
Например:
для пароля от google.com: goo-bob-com
для пароля от wikipedia.org: wik-bob-org
для пароля от habr.ru: hab-bob-ruДумаю суть понятна.Проблемы начинаются, когда:
вам надо сменить пароль на новый
twitter.com переименовался в x.com, а пароль x-bob-com слишком короткий для системы
какая-то система просит, что бы были цифры
какая-то система не поддерживает символ "-"Даже, если вы придумаете как решить все эти проблемы в самом начале, в процессе эксплуатации всплывут новые проблемы, которые заставят вас вводить версии и путаться, на каком ресурсе какая версия.А при раскрытии вашего алгоритма (если кто-то увидит ваш пароль и разгадает алгоритм генерации), вам придётся вспоминать все места, где вы зарегистрированы, идти туда и менять пароли на какой-то более новый алгоритм.
Были ещё варианты оборачивать эти пароли хэш функциями. Будь то обычный sha1 или более продвинутый само-писаный скрипт.
Не знаю, как у остальных, но мне часто приходится вводить пароли в присутствии других людей. Это может быть собрание, презентация или просто коллега подошёл к моему рабочему месту и попросил меня что-то посмотреть, а я оказался не авторизирован. Получается я при нём должен открыть sha1-генератор онлайн, вписать туда пароль в открытом виде (или пусть даже в закрытом), скопировать результат и вставить в поле с паролем? Вам не кажется, что стоящий рядом человек сразу поймёт вашу систему?
Что мы пытаемся защитить
Многие удивлялись, зачем вообще нужна такая "сложная" и надёжная система для простых людей. Что именно защищать? Ведь у обычного человека нет секретов, достойных такой надёжной системы.
С этим я соглашусь. У меня тоже нет ничего настолько ценного, что бы закрывать это настолько, что сам google со всеми его мощностями не сможет это открыть.
Но у меня, как и у каждого из вас есть кое-что другое. Это ваша личность.
Очень редко, когда кто-то пытается вас взломать ради получения секретов. Зато намного чаще это делают, чтобы:
Вести DDoS-атаки с вашего IP на мощностях вашего компьютера
Рассылать с вашего почтового ящика спам и фишинговые письма
Писать от вашего имени вашим контактам в мессенджерах с просьбой одолжить денег
Брать на ваше имя кредит
Покупать через ваш аккаунт с привязанной карточкой товары в интернете
Любая прочая преступная деятельность, которая будет скрывать реальную личность злодея вашим именем.
Веб менее надёжен, но более удобен
Многие сочли bitwarden менее надёжным, чем keypass.
Это парольные менеджеры. Разница в том, что база паролей от bitwarden хранится в облаке у дяди, а база от keypass находится локально на вашем устройстве без вмешательства третьих лиц.
В случае с keypass, пользователи закидывают копию базы на dropbox или аналогичное файловое хранилище третьего лица, для удобства доступности базы и автоматического резервного копирования.
Оба менеджера шифруют и расшифровывают хранилище паролей локально, по мере необходимости, и третья сторона не может видеть сами пароли.
Оба менеджера имеют открытый исходный код, и могут быть проверены на наличие дыр на стороне клиента.
В bitwarden нормальным кейсом использования может считаться web-клиент, который находится на серверах третьего лица. Из-за этого клиент может быть тихо подменён на тот, который подсмотрит ваши пароли. Тут keypass действительно оказывается в лидерах по безопасности. Зато bitwarden вырывается вперёд в плане удобства, - вам не надо устанавливать клиент, он всегда под рукой на любом устройстве мира.
Насколько вероятно, что bitwarden на своих серверах разместит поддельный клиент? Думаю, это возможно только в том случае, если вы храните секрет, который стоит дороже всей компании, когда сам bitwarden готов пожертвовать репутацией и угробить своё творение и свой бизнес ради вашего секрета. Так что, если вы не собираетесь хранить пароль от bitcoin кошелька с миллиардом долларов, спокойно можете использовать bitwarden.
Брутфорс вам не поможет
Ещё одна штука, которая смущает людей - это недоверие к алгоритмам хэширования или полное отсутствия понимание как это вообще работает.
В предыдущей статье я добавил таблицу надёжности паролей, сказав, что 14-символьный пароль будет достаточно надёжен. Спойлер - достаточно и 6 символов при правильной конфигурации алгоритма хеширования.
Давайте разберёмся как вообще работает шифрование файла.
Для этого применяется алгоритм симметричного блочного шифрования. Чаще всего это AES (Advanced Encryption Standard). Он шифрует блоки по ключу. Ключ - это не пароль и должен соответствовать требованиям алгоритма, например, должен быть определённой длины (например, ровно 256 бит). Этот алгоритм должен быть быстрым, иначе с зашифрованными данными будет сложно работать.
О том, насколько тяжело забрутфорсить 256-битный ключ описано в этом видео.
Поскольку держать в голове ключи не удобно, есть способ превратить пароль в ключ. Этот способ называется хэшированием.
На входе хэш-функция берёт пароль любой длины (будь то 1 символ, или 10-терабайтный рандомный файл) и на выходе даёт нам 256-битный (либо любой другой, если надо) ключ. (да, там возможны коллизии: возможно у 10-ТБ файла будет такой же хэш, как у какого-нибудь 50-символьного пароля, так что в 10-терабайтных паролях нет смысла).
Теперь вернёмся к таблице из предыдущей статьи. В ней приведён пример, когда система перебора может генерировать и проверять примерно по 500 миллиардов вариантов паролей за секунду. На мой взгляд это очень смелая мощность (я как-то раз пытался забрутфорсить пароль от zip-архива. При участии видеокарты, производительность была всего около миллиона переборов в секунду. В итоге так и не подобрал пароль).
Чуть ранее я заспойлерил, что даже 6 символов может быть достаточно. Секрет в хэш-функции. Существуют знаменитые MD5 и SHA1, которые действительно работают быстро, но считаются не надёжными.
В парольных менеджерах как минимум используется хэш-алгоритм PBKDF2. Скорость генерации ключей по этому алгоритму снижается до сотен в секунду (т.е. за секунду проверяется не 500 миллиардов паролей, а просто 500).
Но и тут многие заявят, что технологии развиваются, и сегодня - это 500, а завтра с новыми видеокартами станет 500 миллиардов.
Во-первых, давайте ещё раз спросим себя, а действительно ли наша база с паролями настолько ценная, что бы подключать к расшифровке целые дата-центры.
Во-вторых, если пароль будет из 14 символов, то в ближайшие лет 10 ни один дата-центр его не вычислит.
В-третьих, есть и другие хэш-алгоритмы. Например argon2id. Его фишка заключается в том, что для вычисления ключа ему нужно заданное количество оперативной памяти и потоков процессора. Попытавшись забрутфорсить эту функция на видеокартах, где 100500 ядер, вы упрётесь в RAM.
Получается, что с хорошей, сильно сконфигурированной хэш функцией брутфорс пароля из 6 символов может занимать примерно столько же ресурсов, сколько потребовалось бы для 14-символьного пароля с простейшей хэш функцией.
А сочетание хорошей хэш-функции с 14 символьным паролем теоретически даст нам спокойно спать до конца жизни.
Про квантовые компьютеры
Они вам тоже не помогут. Они хороши для поиска парного ключа ассиметричного шифрования (когда у вас на руках есть публичный ключ, и вы хотите вычислить приватный). Но квантовые вычисления совершенно бесполезны в симметричном шифровании, т.к. там идёт работа не с уравнением, а с алгоритмом.
Про паяльник
Не знаю почему, но часто сетап критиковали за то, что он не защитит от физических угроз для получения мастер-пароля.
Повторю: мы защищаем не биткойн-кошелёк с миллиардом денег, а собственную личность. Не думаю, что кто-либо будет использовать биту, что бы провести через ваш интернет банк круглую сумму для запутывания следов при отмывании денег, полученных с продажи процессоров Северной Корее. Наверное, гораздо проще для этих целей будет использование бутылки водки и случайного дворника из глубинки.
Кейлоггеры
Странно, но комментариев на этот очевидный и самый простой вид взлома практически не было.
Логировать все нажатые клавиши - это пожалуй самый простой способ получить мастер пароль от парольного менеджера. Более того, этот метод так же легко компрометирует "крестражные" пароли когда к скопированному из менеджера паролю мы дописываем кусочек из головы (например, bob). Наши аккаунты по прежнему остаются защищёнными двухфакторной авторизацией, но вот смысл "крестражных" паролей утерян.
Факт уязвимости моей системы перед кейлогерами заставил меня задуматься и пересмотреть метод доступа к парольному менеджеру:
Стараться не пользоваться парольным менеджером на незнакомых девайсах. Обычно под рукой телефон, и лучше смотреть пароль оттуда.
В некоторых случаях пользоваться функцией отправки. В bitwarden можно создать линк, проходя по которому можно прочитать важную информацию, например скопированный пароль. После открытия ссылки данные удаляются и повторно линк не работает. Тогда на опасных устройствах даже не придётся ничего вводить. Но логгинг за клипбордом тоже никто не отменял, по этому безопасности это не добавит (но добавить удобства, т.к. писать рандомный пароль со сложными символами с телефона - тяжёлое занятие)
Использовать пин-коды для разблокировки парольного менеджера на собственных девайсах. В случае с кейлогером, это может защитить саму базу паролей. В случае, если один из пин-кодов вылетит из головы, можно залогиниться паролем и задать новый пин. Если кто-то попытается подобрать пин, то в случае с bitwarden у него будет только 5 попыток, после чего уже потребуется мастер-пароль. Да, это может скомпрометировать пароль, но это не такое частое явление, и в идеале на вашем девайсе не должно быть шпионского ПО. Но в любом случае, эта прослойка добавляет хоть чуть-чуть дополнительной безопасности.
Беспарольная авторизация - WebAuthn
Ещё одна штука, которая практически не затрагивалась в комментариях - это беспарольная авторизация. И это странно. Штука форсируется гуглом и набирает популярность.
Решает проблему кейлогеров - вам не надо вводить пароль. Это как авторизация в ssh по ключу. В случае веба ключ может храниться либо на физическом девайсе (например yubikey), либо в самом парольном менеджере (не знаю, как другие, но в bitwarden такое есть).
К сожалению, на данный момент мало сайтов, поддерживающих именно беспарольную авторизацию. Чаще, тот же yubikey можно использовать только в роли 2FA, и только в качестве дополнительного 2FA, после того, как уже подключена TOTP 2FA.
Новые идеи
Кроме комментариев, которые дискутировали о моём сетапе, были так же и комментарии с описанием чужих сэтапов. Многие вещи мне понравились.
Keypass web
Никогда не изучал этот вопрос, но оказывается, у десятков популярных вариаций keepass есть и своя автономная html-версия, работающая в любом браузере локально и без интернета.
К моему сэтапу такое решение подошло бы идеально, т.к. там уже есть html-версии bananasplit и picocrypt.
С keeweb технологический зоопарк ограничился бы только html-файлами и Aegis 2FA. (исчезает отдельный парольный менеджер). При этом всё из коробки получается кроссплатформенное и портативное (не требующее установки).
Ещё бы заменить генератор TOTP на html-ный и вообще универсальный сет получился бы. Хотя могли бы возникнуть вопросы, а не потерялась ли многофакторность, если все яйца лежат в одной корзине под разными паролями, но это уже тема для отдельной дискуссии.
Git storage
В моём сэтапе, создание бэкапов - это периодический ручной процесс.
Если bitwarden заменить на парольный менеджер с локальной базой, то её резервное копирование можно реализовать через git. Бонус в том, что кроме self-hosted git сервера можно использовать облачные решения. Процесс синхронизации можно легко автоматизировать.
Альтернативно для синхронизации можно использовать syncthing, но в нём у вас скорее всего не будет доступа с web.
В любом случае, всё это актуально только с локальной базой паролей, так что мне придётся по старинке делать бэкапы в ручную.
