Я долго собирал информацию о том, как организовать свои аккаунты. Как сделать доступ к ним достаточно надёжным и стойким к утере девайсов.
Меня интересовало, как я могу залогиниться туда, где многофакторная авторизация через телефон, в случае потери телефона.
Или, как обезопасить себя от забывания мастер пароля от менеджера паролей? На моей практике я несколько раз забывал пин-код от банковской карты, состоящий из 4-ёх цифр, после ежедневного использования на протяжении многих месяцев. Мозг - странная штука.
В итоге, спустя месяцы изучения темы, я пришёл к следующему сетапу, который решил описать в виде мануала.
Потребуется запомнить только 2 мастер пароля. Остальное будет доступно в комбинации с мастер паролями. (идея взята из этой статьи)
Схема защиты устройств и бэкапов моего сетапа
Чтобы проверить работоспособность схемы, попробуйте вычеркивать разные узлы (что будет значить, что узел утерян или недоступен). Проверьте, имеете ли вы доступ к своим аккаунтам без этого узла?
Например, если поломается телефон на котором приложение 2FA, сможете ли вы залогиниться в почту?
Так же для проверки представьте, что какие-то данные скомпрометированы. Например, если пароль от netflix по вине netflix попадёт к злоумышленникам, какие данные они смогут получить?
А если утечёт один из ваших мастер-паролей?
Сколько я не тестировал эту схемку, мне кажется, всё будет хорошо до тех пор, пока не утекут оба ваших мастер-пароля.
Инструкция
1. Придумайте два мастер-пароля
В начале придумываем надёжный пароль длиной в 14 символов для парольного менеджера.
Затем придумываем надёжный пароль длиной в 14 символов для шифрования.
14 символов вполне достаточно, что бы не сильно париться со спец-символами в пароле, но их наличие не повредит.
Буквы в верхних и нижних регистрах и цифры рекомендую добавить обязательно, так как это не создаёт неудобств при вводе пароля.
2. Создайте бэкап мастер-паролей
На случай если мы случайно забудем пароли, стоит их записать на бумажку. Чтобы повысить безопасность этой бумажки, следует добавить ещё 1 слой защиты. (идея взята из этой статьи)
С помощью Banana Split делим нашу заметку с паролями по схеме Шамира на несколько кусков, печатаем их и обязательно от руки дописываем фразу для восстановления.
Прячем эти куски по отдельности в физическом мире на случай, если забудем пароль.
По умолчанию будет 3 куска. Для восстановления данных понадобятся любые 2. Если кто-то случайно найдёт 1, он не только не поймёт что это, но и не сможет получить данные.
Пример 1.
1 кусок дома в сейфе, 1 кусок под чехлом телефона, 1 кусок дома у родителей в фотоальбоме с вашими фотками.
Если вы утопите телефон в реке - всё ок.
Если на ваш дом упадёт метеорит - всё ок.
Если вы поссоритесь с родителями и они решат сжечь альбом с вашими фотками - всё ок.
Если злоумышленник попытается получить ваши пароли, будет сложно достать даже 1 кусок, не говоря о двух.
Пример 2.
Вы поехали в путешествие. 1 кусок кидаем в чемодан, 1 кусок в чехол смартфона, 1 кусок оставляем в сейфе в номере. Какая бы ситуация не произошла, скорее всего всё будет ок.
Примечание: Banana Split красивая, но скорее для параноиков. И ещё она не работает на телефоне. Более простой вариант, который работает везде и тоже сохраняется в виде html-файла - реализация от Иана Коулмана
3. Заводим парольный менеджер
Регистрируемся в Bitwarden с паролем для парольного менеджера.
Можно использовать и другой менеджер, но этот:
облачный, значит будет доступен везде
исходные коды открыты, значит есть возможность детально разобраться как он работает под капотом и стоит ли ему верить
есть платная версия, а значит есть доходы, на которые его будут поддерживать
немецкий, а европейцы сильно помешаны на конфиденциальности
сквозное шифрование базы, а значит, без мастер пароля данные не доступны никому
ресурсо-стойкое шифрование, а значит, брутфорс будет невозможным, или дорогим
4. Подготавливаем 2FA (многофакторная авторизация)
Устанавливаем на телефон Aegis Authenticator и защищаем его паролем для шифрования + биометрией для удобства.
Можно использовать и другой аутентификатор, но этот:
приложение блокируется паролем и биометрией, а значит, если ваш телефон попадёт не в те руки, им это ничего не даст
исходные коды открыты, значит есть возможность детально разобраться как он работает под капотом и стоит ли ему верить
нидерландский, а европейцы сильно помешаны на конфиденциальности
сквозное шифрование базы, а значит, без мастер пароля данные не доступны никому
5. Добавляем 2FA в Bitwarden
Защищаем парольный менеджер при помощи 2FA Aegis
6. Подготавливаем шифровальный инструмент
Открываем веб версию Picocrypt, сохраняем её (жмём Ctrl+U, затем Ctrl+A, затем Ctrl+C, потом открываем текстовый редактор, жмём Ctrl+V и Ctrl+S) и копируем на все наши устройства и во все облака.
Можно использовать и другой шифратор, но этот:
автономный и кросс-платформенный, а значит будет работать и на телефоне, и на планшете, и на маке, и на винде
открытые исходные коды, есть даже инструкция по сборке и zip архив с исходниками всех зависимостей
автор - школьник азиатского происхождения, который пока слишком молод, чтобы творить зло (хотя это скорее минус, но более удобных альтернатив я пока не нашёл. Самое близкое - hat.sh)
7. Создаём бэкап 2FA
Экспортируем Aegis в не зашифрованном виде и шифруем с помощью Picocrypt, который мы только что везде сохранили.
В Aegis есть шифрованный экспорт, но так мы привяжем себя к инфраструктуре aegis, и если она окажется недоступной (приложение исчезнет из маркета), у нас могут появиться проблемы.
На случай, если ваш телефон сломался, а вам надо куда-то залогиниться, и другого телефона, чтобы установить aegis нету, можно воспользоваться 2FAuth, что бы 2FA был доступен с любого устройства. Но это сложный self-hosted инструмент, для которого нужен свой сервер и понимание что вы делаете, и как защитить ваши данные на серверном уровне.
8. Создаём облако для бэкапов инструментов авторизаций
Регистрируемся на Inbox.eu с паролем для шифрования. (Осторожно! Реферальная ссылка!)
Переходим в раздел файлов и загружаем туда бэкап из предыдущего шага и инструмент для расшифровки.
Можно и любое другое облако, потому что содержимое будет зашифровано собственными силами и утечки не критичны.
9. Добавляем нотификации для обновления бэкапов
Регистрируемся в rememberthemilk (пароль генерируем и храним в bitwarden)
Настраиваем ежемесячную задачу для напоминания о бэкапе. Настраиваем оповещение по email на вашу почту, на которую приходят ежемесячные счета для оплаты коммуналки.
Теперь раз в месяц вместе с оплатой счетов мы будем создавать 2 бэкапа - 2FA Aegis и Bitwarden и шифровать их с помощью Picocrypt.
Шифрованные файлы и файл Picocrypt для расшифровки будем закидывать на все наши личные устройства, личные облака, специальное облако для бэкапа авторизаций, на наш смартфон и на флэшку, которую будем хранить в сейфе.
Можно и любой другой инструмент нотификаций, главное, чтобы он был привязан к вашим ежемесячным привычкам (подробнее в книге Атомные привычки).
10. Создаём бэкап парольного менеджера
Экспортируем не шифрованный бэкап Bitwarden и шифруем его при помощи Picocrypt паролем от парольного менеджера.
В Bitwarden есть шифрованный экспорт, но так мы привяжем себя к инфраструктуре Bitwarden, и если она окажется недоступной (сервер уйдёт в оффлайн), у нас могут появиться проблемы.
11. Проверяем, что всё сделали правильно
Пробуем восстановить мастер-пароли через куски QR-кодов
Пробуем дешифровать бэкап паролей из парольного менеджера
Пробуем дешифровать бэкап 2FA
Пробуем стереть все данные в Bitwarden и восстановить по бэкапу
Пробуем удалить Aegis, установить его снова и импортировать бэкап
Пробуем залогиниться на облако бекапов авторизаций и скачать бэкапы
В день счетов проверяем свой почтовый ящик на наличие нотификации об обновлении бэкапов
Если все шаги проверены успешно, можно двигаться дальше.
Если что-то зафейлилос, надо попробовать исправить, либо повторить все шаги с самого начала, создав новые аккаунты.
12. Мигрируем
Идём по списку всех наших аккаунтов (список можно составить из головы + сохранённые пароли в браузере + списки oauth google и facebook) и:
меняем пароль на новый сгенерированный через Bitwarden
сохраняем новый пароль и авторизационные данные в Bitwarden
удаляем пароль из браузера
добавляем двухфакторную авторизацию через Aegis
Дополнительно
Чтобы упростить себе жизнь, можно купить физический ключ доступа в качестве дополнения второго фактора к Bitwarden.
Таким ключом может быть Yubico Security Key
Можно и другой, но этот:
шведский, а европейцы сильно помешаны на конфиденциальности
разработан в партнёрстве с Google, т.е. имеет стандарт поддерживаемый крупным игроком
относительно не дорогой, т.е. альтернатив дешевле я не встречал
других почти нет и выбор крайне ограничен
И ещё:
Для большей степени защиты можно использовать пароль, который дописывать после пароля из менеджера паролей. (идея взята из этой статьи)
Например, ваш дополнительный кусок пароля - bob.
Если в менеджере паролей хранится Wj8R#ieL, то для регистрации и логина вы его копируете и дописываете bob, чтобы получилось Wj8R#ieLbob.
Таким образом, если данные вашего парольного менеджера утекут, злоумышленник всё равно не будет иметь полных паролей.
По сути, таким образом мы добавили ещё один фактор.
Заключение
В заключении хочу добавить, что не следует быть параноиком, стоит просто соблюдать "гигиену" при организации логинов и паролей.
Ваши данные нужны кому-то только, если там детская порнография, или чёрная бухгалтерия с уходом от миллионов налогов.
Для нормального человека "гигиена" при организации логинов и паролей нужна для того, чтобы хакеры от вашего имени не рассылали спам и не занимались фишингом. Им интересны не данные, а возможность действовать от вашего лица.
Если в моём сетапе есть дыры, или вы знаете более хорошие альтернативы моим инструментам, смело отписывайте в комментариях.
Комментарии (113)
Lelant0s
18.01.2024 05:54+4Мне осталось теперь найти соответствующие серьезности этого подхода секреты, которые я хочу сохранить.
SkywardFire
18.01.2024 05:54Я всё же думаю, здесь больше про возможность самому получить доступ к своим же данным в случае "вылетания" какого-либо звена...
Timon96
18.01.2024 05:54+6менеджер паролей в облаке, это слабое место. рано или поздно, под тяжестью разных причин, все что храниться в облаке будет доступно корпорациям (продадут поисковики)
aleksejs1 Автор
18.01.2024 05:54Bitwarden доступен, как self-hosted. Можео все данные храниь на своём сервере.
Но даже если его хостит ктр-то другой, данных у него всё равно нет.
Данные шифруются алгоритмом AES по 256 бинтому ключу, сгенерированному по алгоритму argon2id, настройки которого может менять сам пользователь. Расшифровка происходит исключительно на стороне клиента.
Можно накрутить так, что даже всех мощностей гугла, амазона и майкрософта не хватит, что бы расшифровать выша данные за тысячелетия.
StupidityIncarnate
18.01.2024 05:54А вот когда сделают домашние квантовые компьютеры!!
aleksejs1 Автор
18.01.2024 05:54+1Не уверен, что это поможет взломать хранилище паролей. Даже не уверен, что он поможет ускорить вычесление хэшей в argon2id. Но я про это мало что знаю
DROS
18.01.2024 05:54+4Всегда забавлял тот факт, что люди уверены, раз решение оупенсорсное и лежит на гите, значит все прозрачно. Откуда такая уверенность в том, что на чьем-то чужом сервере развернут тот же самый код, что и в репе? Кто мешает допилить "серверную" версию так, чтобы невозбранно читать чужие секреты (про репутацию речи не ведем)?
andreymal
18.01.2024 05:54+1Кто мешает допилить "серверную" версию
Шифрование мешает
kma21
18.01.2024 05:54откуда вы знаете, что на серверах bitwarden.com зашифрованы БД с паролями их клиентов? что они не хранятся плейнтекстом
andreymal
18.01.2024 05:54+1От используемого мной клиента, который я (предположим) собрал самостоятельно из проверенных исходников и который шлёт на сервер только зашифрованные данные без пароля
K0styan
18.01.2024 05:54+1Bitwarden заявляет, что шифрует базу на локальном устройстве, на сервер уходит уже зашифрованная. Открытые исходники клиента позволяют в этом убедиться.
aleksejs1 Автор
18.01.2024 05:54Я согласен, но акцент сделан на то, что можно посмотреть как система работает под капотом. Грубо говоря, что бы шифратор, который я порекомендовал не использовал md5 для хэширования. Даже когда в README написан какой-то алгоритм, узнать, по каким параметрам он работает можно только из сорсов.
Про bitwarden в данном случае согласен. Но эта бреш минимизируется двухвакторкой и дополнительными кусками паролей.
CaptainFlint
18.01.2024 05:54+1Если вы по коду клиентской версии видите, что всё шифрование производится локально и на сервер отправляются только зашифрованные данные, то уже не столь важно, как там устроена серверная сторона, ваши данные она не получит в любом случае (понятно, если шифрование надёжное и в клиенте нет незамеченных бэкдоров).
Впрочем, я не знаю, так ли оно устроено у Bitwarden'а или там всё-таки шифрует сервер; во втором случае, разумеется, уверенности быть не может. Лично я предпочитаю держать пароли в локальной базе (KeePass) и синхронизировать эту базу отдельной программой.
K0styan
18.01.2024 05:54Вот мне, кстати, всегда было интересно - на том же Dropbox наверняка лежат тыщи файлов .kbd/.kbdx, причём некоторые - годами. Будь я злодеем и заодно владельцем этого Dropbox-а, я бы каждый из них давно попытался пробрутфорсить)
CaptainFlint
18.01.2024 05:54Вот, к слову, да, этот фактор тоже часто упускают из виду, что данные, которые невозможно расшифровать сейчас, могут оказаться доступными для взлома когда-то потом (открытие новых алгоритмов или ранее незамеченных уязвимостей в шифровании, развитие вычислительных мощностей, квантовые компьютеры…). И я плохо представляю, как можно защититься от этого. То есть, понятно, что не стоит разбрасывать даже зашифрованные секретные данные по всем общедоступным местам, но если кто-то получит файл в результате взлома или кражи устройства, то дальше останется только надеяться, что к моменту возможности расшифровки злодей просто потеряет интерес (или файл).
Со своей стороны стараюсь всё-таки не пользоваться хранилищами типа Dropbox, предпочитаю пиринговые или self-hosted решения. Скажем, Syncthing довольно интересен, хотя и небеспроблемный.
kma21
18.01.2024 05:54для защиты от того, что кто-то сохранит копию БД с паролями и сможет взломать потом надо просто регулярно менять пароли (т.о. утёкшая копия БД с паролями станет не актуальной). если говорить про то, что БД лежит в недоверенном месте (чужое облако), то надо прст регулярно менять ещё и алгоритмы шифрования на современные и не подверженные уязвимостям.
CaptainFlint
18.01.2024 05:54-1Смена паролей, конечно, помогает, но когда в базе под две сотни записей, делать это становится несколько напряжно. Не говоря уж о том, что в базе можно хранить не только пароли, а ещё и другие данные, которые поменять сложно или вовсе невозможно (скажем, лицензионные ключи купленных программ; приватные ключи сертификатов, которые нежелательно терять даже после истечения сроков действия…).
inkelyad
18.01.2024 05:54когда в базе под две сотни записей, делать это становится несколько напряжно.
Вся куча делится на кусочки, равномерно распределяя на -тцать месяцев и настраиваем напоминалки в календаре - раздражает, но не сильно напряжно.
K0styan
18.01.2024 05:54Даже не то, что "могут потом" из-за алгоритмов или уязвимостей. Дропбокс в 2007 запустили. Какие-то файлы с паролями уже почти 17 лет как могут где-то уютно брутфорситься.
CaptainFlint
18.01.2024 05:54+1Ну, если алгоритм и длина пароля такие, что брутфорс занимает миллиард лет на современном оборудовании, то эти 17 лет погоды не сделают.
sim31r
18.01.2024 05:54За 17 лет затраты энергии будут миллионы $ стоить на брутфорс. Еще один ограничивающий фактор. Тем более мало кому интересны секреты 2007 года.
VADemon
18.01.2024 05:54Кто-нибудь, сохранивший по наивности свой wallet.dat от биткоина в году 11-ом и попавший в аварию. Как не вариант?
VADemon
18.01.2024 05:54https://github.com/bitwarden/clients/issues/5734
Наизамечательнейший интерфейс Хабра стер весь комментарий, потому что я нажал на другую кнопку ответить ниже. Ограничусь потенциальной атакой сославшись на dependency in npm repos.
Neusser
18.01.2024 05:54+1Вам нужно ввести куда-то пароль. Сколько действий для этого потребуется?
aleksejs1 Автор
18.01.2024 05:54В самом защищённом варианте:
Ctrl+Shift+L (для активации плагина bitwarden)
Ввести мастер пароль от bitwarden
Докоснуться до ключа yubico для авторизации в bitwarden
Дописать вторую часть пароля от аккаунта из головы
Докоснуться до ключа yubico для авторизации в аккаунт
В наиболее частом сценарии только:
Ctrl+Shift+L (для активации плагина bitwarden)
Ввести мастер пароль от bitwarden
Докоснуться до ключа yubico для авторизации в bitwarden
Tsimur_S
18.01.2024 05:54+7Докоснуться до
Я первый раз слышу такой оборот, это местный диалект, эрратив или какое-то старинное слово отсутствующее в словарях?
johnfound
18.01.2024 05:54+2Такое слово в русском похоже есть, и оно достаточно старое, правда в современном языке используется редко. Но возможно напоследок его используют чаще. Язык меняется.
В болгарском используется именно «аз докосвам, ти докосваш, той(тя, то) докосва».
unC0Rr
18.01.2024 05:54+2У меня вообще взрыв мозга теперь от использования слова "напоследок" не в смысле "под конец".
johnfound
18.01.2024 05:54+1Ха, ха, я тоже заметил, но время редактирования уже прошло. :D Это из ложных друзей переводчика. Означает «в последнее время» на болгарском. Просто в русском нет отдельное слово и мозг подбрасывает «синонимы»...
Lev3250
18.01.2024 05:54Автор из Латвии. Вполне возможно, что там принято так говорить
drdead
18.01.2024 05:54Ну, вот, я родом из Ростова-на-Дону, "под руку" (говорили в дискорде, пока статью читал) попался друг из МСК.
Для нас двоих это обычное разговорное слово, ничего странного в нём нет. Просторечье может быть?
VADemon
18.01.2024 05:54Интернет и СМИ стирают границы. Уж очень надо стараться, чтобы сохранить (заморозить) свой язык на прежнем уровне.
Kil1J0y
18.01.2024 05:54+2относительно не дорогой, т.е. альтернатив дешевле я не встречал
Rutoken MFA стандарт Fido2 U2F дешевле даже базовой версии yubico, сели смотреть 5/5с и тд с поддержкой openpgp то разница ещё выше, а ключей требуется все равно 2.
isden
18.01.2024 05:54Rutoken
Я пару раз уже было порывался прикупить, но каждый раз останавливало "а нет ли там закладок"?
Kil1J0y
18.01.2024 05:54По факту, закладки могут быть везде, intel me закладка? В ключах шифрования одобреные nist есть закладки?
Тут как бы rutoken ecp 2.0 flash 32g куплен не для того чтобы хранить пароли а для того что бы иметь "флешку" с защитой от записи, а сами пароли храните в контейнере с aes256 с увеличенным числом итераций (например veracrypt). А в качестве безопасного токена для удалённого доступа очень даже подходит даже не смотря что там могли заложить закладку , т.к. на нем не хранится в открытом виде конфиденциальной информации
Antas
18.01.2024 05:54+2В табличке надежности паролей меня всегда удивлял тот факт, что пароли, на подбор которых нужно 3 года и 69000 лет находятся в одной (оранжевой) группе риска. Особенно удивляет, что кому-то 690 веков кажется недостаточно долгим сроком для подбора.
Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Kil1J0y
18.01.2024 05:54+7Я пользуюсь хранилищем KeePass XC на телефоне и десктопах, хранилище само хранится в условном домашнем облаке доступ со всех устройств шифрование канала в наличии, в браузерах полный запрет на сохранение пароля, стоит интеграция с браузером для ввода паролей. Весьма удобно когда привыкнешь. Ageis для 2fa, рутокены mfa для fido2 авторизаций, ssh и тд. Рутокен эцп 2.0 flash для безопасной os без возможности изменения, и так же доступ по сертификатам к vpn, ssh и тд.
ris58h
18.01.2024 05:54стоит интеграция с браузером для ввода паролей
На Android и iOS тоже работает?
Kil1J0y
18.01.2024 05:54IOS не знаю, на android есть magikeyboard для KeePass(как бы его часть), она занимается автозаполнением при разблокированной базе
ris58h
18.01.2024 05:54Это ещё стороннюю клавиатуру ставить надо? Уффф.
kilometrix
18.01.2024 05:54+4В Android можно выбрать KeePass как autofill service по умолчанию, тогда вторая клавиатура не нужна.
Andrusha
18.01.2024 05:54Там есть системная служба автозаполнения, на деле выходит даже удобнее, чем на компьютере. Для iOS пользуюсь Strongbox, он правда стоит прилично, но это его единственный минус.
johnfound
18.01.2024 05:54+7Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Факт, но дело в том, что это только прикидочные значения. 24 года запросто могут превратится в 1 год и меньше, если кто-то решит что это важно для него. Ну или если резко подешевеют вычислительные мощности.
muxa_ru
18.01.2024 05:54Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Вот не факт, ситуации разные бывают.
WASD1
18.01.2024 05:54Учтите, что подбор паролей параллелится почти идеально.
Это значит, что условная RTX 4090 в 100 раз производительнее CPU.
Т.е. поставив одну 4090 мы 24 года рассчётов превращаем в 4 месяца.
Что будет если поставить несколько - считайте сами.sim31r
18.01.2024 05:54Если нужно расшифровать rar архив длиной в гигабайт созданному в режиме solid, скорее всего не получится ускорить процесс видеокартой. Так как нужно пробегать по всему файлу до конца каждый раз.
WASD1
18.01.2024 05:54Вы считаете, что пример со вскрытием гигабайтного rar - хороший (близкий к репрезентативному) пример в даном случае?
VADemon
18.01.2024 05:54Откуда такие данные? Там наверняка ключ зашит в header и только его надо расшифровать паролем. У hashcat есть брутфорсилка.
inkelyad
18.01.2024 05:54Ключ надо проверить.
Если для проверки нужно расшифровать гигабайт, распаковать его и сосчитать контрольную сумму от получившегося - то быстро подбирать вряд ли получится.
VADemon
18.01.2024 05:54https://www.doyler.net/security-not-included/crack-rar-files-hashcat
Тут правда rar3, но сначала выдирается хэш пароля и только по нему брутфорсится.
inkelyad
18.01.2024 05:54Дальше по ссылкам:
/* Skip solid files (first file is never solid) * We could probably add support for this */ if (file_hdr_head_flags & 0x10) { fprintf(stderr, "! Solid, can't handle (currently)\n"); jtr_fseek64(fp, file_hdr_pack_size, SEEK_CUR); goto next_file_header; }Так что оно сделает с полностью solid архивом, как предлагалось - непонятно.
inkelyad
18.01.2024 05:54<после гугления>
Возражение отменяется - судя по всему так таки есть возможность проверить ключ, не расшифровывая каждый раз весь файл.
aleksejs1 Автор
18.01.2024 05:54В случае с argon2id - вычисление хэша пароля зависит не только от производительности CPU, но и от RAM
ogost
18.01.2024 05:54+3Как всё переусложнено.
Берём GNU pass.
Добавляем плагины для автоввода и OTP.
Добавляем все пароли и коды восстановления и прочие ваши секреты.
Добавляем всё это дело в гит репозиторий. Remote для этого репозитория можно сделать хоть какой, хоть на гитхабе, хоть селф-хостед, хоть bare поверх ssh.
Берём мобильный клиент pass и синхронизируем с гит репозиторием. Он тоже умеет всё вышеперечисленное.
Плюсы такого решения:
Очевидно селф хостед со всеми вытекающими
Открытые исходники
Синхронизация на любое количество и любой вид устройств
Минусы такого решения:
Для добавления новых устройств необходимо секурно передать gpg-ключи на целевое устройство, что в случае с мобильником может быть неудобно.
aleksejs1 Автор
18.01.2024 05:54Да... плхоже такая схема в плане безопасности не худа.
Мне в этом не хваьило бы веб-клиента, на случай если используется чужое устройство.
Но, мне нравится. Обязательно поразмышляю над таким вариантом
DaneSoul
18.01.2024 05:54Для добавления новых устройств необходимо секурно передать gpg-ключи на
целевое устройство, что в случае с мобильником может быть неудобно.Передача файла ключа через USB-подключение телефона не достаточно безопасна?
mibori
18.01.2024 05:54репохостинг будет знать какими сервисами вы пользуетесь (если вы, конечно, не зашифруете репозиторий)
ogost
18.01.2024 05:54У меня свой сервачок на линухе, репо - обычный git bare. Смысл в том, что в случае с гитом у вас множество вариантов. Кроме того, структуру папок и название файлов придумываете вы сами, тут уж насколько фантазии хватит.
zaelcovsky
18.01.2024 05:54Добавляем всё это дело в гит репозиторий. Remote для этого репозитория можно сделать хоть какой, хоть на гитхабе, хоть селф-хостед, хоть bare поверх ssh.
А в каком виде будут хранится пароли в репо на гитхабе?
KonstantinTokar
18.01.2024 05:54+2Немного критики и рацпредложение.
В один прекрасный момент онлайн версия Bitwarden будет взломана, всё что делается на стороне клиента будет в открытом виде у хакера, и все мастер пароли утекут (Как регулярно происходит с другими подобными парольными менеджерами). Можно и сэлфхостить, но проблемы этого всем понятны.
То есть для условной вражеской разведки способ получения пароля - в наиболее частом сценарии - надо как то взломать/подделать сайт, заставить ввести на нём мастер пароль (например поставить человека в жёсткие временные рамки с отвлекающими факторами, или просто напоить и банально записать на камеру пароль), потом физически отнять yubico и всё. Почти та же схема, как для разблокировки телефона заблокированного отпечатком пальца, сотрудничество клиента необязательно. То есть все хитрости становятся бессмысленными при серьёзном подходе, а при несерьёзном - keepass достаточно.
3 (10 - 100) лет подбора в эпоху развития искусственного интеллекта, когда доступность систем с десятками тысяч высокопроизводительных серверов стало реальностью, выглядит не очень хорошо - на системе из 10000 серверов 100 лет работы превращается в 12 часов, а с учётом nvidia ускорителей в один час или в одну минуту или ещё быстрее.
Можно использовать немного другую схему генерации пароля - не слова или случайные символы, а несколько первых символов из слов какого нибудь стишка, который придумывается самостоятельно и который можно запоминать даже используя какой то открытый текст с ассоциациями, которые постороннему непонятны. Это позволяет получить пароли любой разумной длины (и прокачать свои стихотворческие скилы).
falcon4fun
18.01.2024 05:54+10несколько первых символов из слов какого нибудь стишка
Сорок тысяч обезьян в жопу сунули банан.
gunitroo
18.01.2024 05:54+6Ну спасибо, теперь менять пароли ????
falcon4fun
18.01.2024 05:54+1На то самое слово во множественном числе, которое так не склоняется? :D Я вас раскусил.
А вообще - классика. Прочитал пару абзацев, аж олдскулы свело. Но мне в основном третья книга нравится и первая.
gmtd
18.01.2024 05:54-1Хреновый алгоритм
Человек забывает "bob", и всё, накопленное непосильным трудом и лежащее на криптоадресах, идет коту под хвост...
MarvinD
18.01.2024 05:54+6За Banana Split и схему Шамира спасибо, но имхо, это единственное любопытное в статье (и то, тому, кто про это не знал).
Статья в целом:
а) сценарий шпионского фильма
б) реклама баунти-программы на inbox.eu (?euRefId=68337). Все ссылки нормальные, но эта с "пасхалкой". Написали бы хоть в скобочках.
в) просто крайне неудобная схема. Пароль для хранения пароля для хранения пароля для хранения паролей... Если все так серьезно, то даже само использование последовательности из нескольких онлайн сайтов и сервисов (пусть и javascript, пусть и opensource) уже так себе идея. Я предлагать свои варианты не буду, это вкусовщина. Но во всех таких приколах первое о чем надо думать - о том, насколько все это нужно. Чтобы что хранить? От кого? От жены - смех. От литовских полицаев на границе - ну позвольте, вы сами все покажете, иначе в страну не пустят или задержут, пока не скажете :) Ну и так далее.
Извините, имхо, но это перебор в третьей степени. Но за Шамира спасибо :)aleksejs1 Автор
18.01.2024 05:54б) реклама баунти-программы на inbox.eu
Извиняюсь. Добавил пометку в скобочках :)
в) просто крайне неудобная схема
Вся схема сводится к тому, что надо использовать парольный менеджер, защищённый 2FA. Всё остальное - это бэкапы. Шифруем, прячем, поддерживаем. В идеале никогда не пользуемся. Но в случае чего - они есть.
за Шамира спасибо :)
Кстати, схема Шамира не единственная, о других можно почитать тут: https://habr.com/ru/articles/783866/
titbit
18.01.2024 05:54+3Схема сильно переусложнена. Отказы бывают не единичные, а системные, например когда нет связи в вашей схеме надо вычеркнуть не один компонент, а сразу 3, и это вполне обычная ситуация. Защищать пароли паролями - странно, только число слоев растет, а общая надежность падает. В схеме вообще нет никакой гибкости, секреты не делятся по их ценности и их контролируемости.
Aquahawk
18.01.2024 05:54Мне кажется что используемая мной схема и и надёжнее и проще, когда я её построил я понял насколько раньше сложно жилось, и как теперь круто. Я даже думал написать статью об этом, но потом понял что security through obscurity, несмотря на критику, также имеет место быть, и публично демонстрировать поверхность атаки на себя смысла не вижу.
Дам такой совет, изучите различные системы, прочтите их руководства и очень внимательно все возможные их настройки, внезапно есть системы которые можно настройками настроить значительно лучше чем они предлагают из коробки. Не факт что вы сделаете также, как у меня, но ваша личная система, при условии что вы не допустите критических ошибок, настроенная неконвенциональным образом, уже будет радикально отделять вас от всех остальных, с точки зрения уязвимости ваших аккаунтов.
polearnik
18.01.2024 05:54-1как вы оцениваете свою стойкость? сдадите все секреты еще на стадии доставании паяльника или уже на стадии разогрева его на столе?
Aquahawk
18.01.2024 05:54+1Тут вроде не от этого защищаются. И от паяльника тоже существуют некоторые меры защиты. Да не абсолютные, как и всё в этом мире, но они есть, и даже у меня. Я не понимаю вашего пассажа. Вы предлагаете не управлять сотнями паролей защищённо? Вы считаете что любая защита информации не имеет смысла, т.к. факапы и взломы случаются? Переформулируйте вопросы в утверждение и тогда, возможно, вам ответят.
K0styan
18.01.2024 05:54Двухфакторка с аппаратным ключом и пассатижами под рукой может оказаться защищённой даже от паяльника. Главное - убедить, что вот эта сломанная "флэшка" - это и был ключ, и без него ловить нечего...
Но тогда придётся жить без бэкапа.
johnfound
18.01.2024 05:54+2может оказаться защищённой даже от паяльника
Ну-у-у-у, я бы не стал злить людей с паяльником... Единственная реальная защита от паяльника, это отрицаемое шифрование. В смысле, когда даешь хоть что-то, достаточное чтобы тебе поверили. А то, в конце концов тебе поверят, но тебе от этого легче не будет.
K0styan
18.01.2024 05:54Так-то вы правы. Но в контексте базы паролей - это понадобится полноценная вторая цифровая личность.
StrategGo
18.01.2024 05:54Выглядит надёжно. Но всегда есть альтернатива. Один пароль на все случаи жизни и для всех сервисов. Дальше познаём дзен и отказываемся от суеты бренного мира. Если даже взломают, и похитят все наши нехитрые секреты, это никак не повредит нашей душе. Зато свобода головы от кучи паролей и сервисов по их хранению освободит много пространства для настоящей жизни без страха.... Да, знаю. В службе безопасности с таким подходом мне не работать)))
Semy
18.01.2024 05:54Это странный подход. Регистрироваться приходится там, где подход к безопасности не известен. Может там пароли открытым текстом в БД хранятся. Когда-то я использовал специальный пароль, когда регистрировался в самых трешовых местах. Через несколько лет обнаружил его в словаре для брутфорса (ожидаемо). Если бы сейчас это произошло, то я мог бы определить сайт, с которого была утечка (уникальные пароли в менеджере).
MountainGoat
18.01.2024 05:54+4Экие ужасы.
Все пароли храню в KeePassXC. Скрипт бэкапит на файлопомойку в другой комнате и на телефон. Один-два раза в год ещё пишу зашифрованную БД на флешку, кладу её в презерватив и прячу на руинах заброшенной свинофермы. Это не шутка, просто я там каждый день хожу.
SquareRootOfZero
18.01.2024 05:54+1У меня просто база KeePass лежит в Dropbox, как только что-то в ней меняется - она автоматически синхронизируется средствами Dropbox, в т. ч. и на смартфон. При этом никакой привязки ни к чьим-то надёжным опенсорсным облачным технологиям, ни даже к онлайну в целом нет - база есть локально что на компе, что на смартфоне, а дропбокс, если захочу, я в раз поменяю на какой-нибудь ещё другой бокс. Один мастер-пароль к этой базе как-то все эти годы помню.
gunitroo
18.01.2024 05:54+1Так и есть, самый плюс такого подхода, что не жалко Dropbox аккаунт, он как расходник, даже если потеряю телефон, вещи, документы, всегда могу в любом интернет кафе разблокировать базу с помощью keeweb.
SquareRootOfZero
18.01.2024 05:54Не понял этого захода. Почему "не жалко Dropbox аккаунт, он как расходник"? У меня этот аккаунт живёт года с 2008, что ли, используется для всякого, не только для паролей. Если я потеряю телефон, компьютер(ы) и пр. "флэшки" с базой KeePass, а пароль к Dropbox не вспомню - то всё, пароли пропадут.
gunitroo
18.01.2024 05:54У меня Dropbox только для этого kdbx файлика, не жалко в том смысле, что если я буду вводить его в небезопасных местах и устройствах, для доступа через keeweb.
Из этого Dropbox папка /Apps/KeeWeb/ синхронизируется с основным облаком автоматически, т.е. kdbx на Dropbox, основном облаке, телефоне, планшете и компьютере (еще раз в месяц в первое число по cron'у kdbx бэкапится на mega, но то уже параноя).
SquareRootOfZero
18.01.2024 05:54В смысле, пароль к аккаунту Dropbox в небезопасном месте скрадут, но не жалко, а пароль к kdbx тоже скрадут (место-то всё то же, и всё такое же небезопасное?), но тоже не жалко? Или как?
gunitroo
18.01.2024 05:54Вы правы, в небезопасных местах лучше не вводить никакие пароли.
Расходник Dropbox из-за того, чтобы показать непривзятость к какому-то единому серверу хранения файла парольного менеджера.
SquareRootOfZero
18.01.2024 05:54Для небезопасных мест, теоретически, существуют одноразовые пароли, но это совсем другая история. Схему, как на небезопасном компьютере безопасно посмотреть свой пароль, придумать можно, только зачем - ты ж не будешь его на этом небезопасном там же и вводить, пуская всю безопасность прахом, а если рядом есть безопасный, куда вводить пароль - так там же его и посмотреть можно.
killyself
18.01.2024 05:54Некоторое время назад придумал простую схему пароля - беру первые 3 буквы в названии сервиса или сайта, первая буква идет заглавной, вторая строчной а третья превращается в символ который сверху от нее в разделе спецов. Затем добавляем название сервиса и повторяем для длины второй раз 3-символьный код. Запомнить элементарно, хранить не нужно, уровень безопасности - только если специально следить или как то получить несколько паролей для анализа (хотя кому я сдался). Пример пароля - habr.com = Ha^habrHa^ (нет, это не мой настоящий пароль).
K0styan
18.01.2024 05:54+1Думаю, почти все через подобные конструкторы проходили. Я отказался после того, как сначала алгоритм оказался неудобен для одного из сервисов, а позже я стал путать, в каком сервисе используется старый алгоритм, а в каком - новый.
Хуже того: пара сервисов объявили об утечке и заставили сменить пароль на новый, другой. Пришлось модернизировать алгоритм ещё раз, что путаницы добавило.
SquareRootOfZero
18.01.2024 05:54+1Тут была уже минимум пара постов про парольные менеджеры, которые ничего не хранят, а детерминистически генерируют пароль к любому сервису по URL-у этого сервиса и мастер-паролю. Проблемы с ними, впрочем, все те же, плюс добавляется необходимость где-то держать и каждый раз запускать этот менеджер, в отличие от достаточно простого мнемонического правила, позволяющего пароль в уме генерить.
lisisty
18.01.2024 05:54Много кто через подобное проходит(я тоже). А потом, по каким либо обстоятельствам, надо сменить пароль и опаньки, появляется Ha^habrHa^1 или 97 или "ваш пароль может содержать только символы которые мы разрешаем" и появляется Ha@habrHa@1. А потом, блять, какая же версия схемы используется на этом сайте, v1 или v4)
Semy
18.01.2024 05:54Не понял про спецсимволы. В большинстве клавиатур клавиши сдвинуты по отношению друг к другу. Не некоторых друг над другом. Легко ошибиться. Могут быть экзотические клавиатуры. Иногда надо набирать с телефона. Вариантов не попасть в нужный символ масса.
Fodin
18.01.2024 05:54Помню один мастер-пароль и файл KeePass держу на Яндекс.Диске. Парольной базой пользуюсь на Винде, Макоси и Андроиде. Для совсем не ответственных и одноразовых регистраций использую пару-тройку старых паролей, которые въелись в память.
zabanen2
18.01.2024 05:54несколько kbdx файлов в облаке. несколько потому, что разные назначения, допустим, банки - отдельно, открываются редко.
feelamee
Интересно, а вы храните детскую порнографию или уходите от налогов?))
А теперь без шуток.
Насколько безопасно создавать ключевые фразы вместо случайных символов для паролей или мастер пароля?
Кстати, мне кажется раскрыв эту схему вы сняли один фактор безопасности) ну да ладно, у вас ещё много в запасе
aleksejs1 Автор
С точки зрения брутфорса парольные фразы надёжнее. Слов больше, чем букв.
Но вот с точки зрения социального взлома, когда злоумышленник смотрит на то, как вы вводите пароль, понять, что вы пишите слова, и тем более запомнить их с первого раза - на мой взгляд в разы проще, чем случайный набор символов.
Если речь о менеджере паролей - аналогично, т.к. не всегда вы вводите пароль на том устройстве, на котором менеджер. Бывает, вы смотрите на него в телефоне и вводите в компьютере. Одного корокого взгляда злоумышленника на фразу будет достаточно, что бы запомнить.
Раскрытие схемы - это как опен сорс :) найти дыры проще, зато в комментариях на эти дыры успеют указать раньше, и укрепят систему.
П.С. если бы была детская порнография или проблемы с налоговой нету ;)
feelamee
Тогда вопрос. А если в фразе есть смысл? То есть она является вполне обычным предложением. Это сильно ухудшает безопасность?
Я имею ввиду - насколько "конь пробежал милю за два часа" хуже, чем "конь ингредиент страница красивый наклейка"?
inkelyad
С точки зрения перебора - если известно, что цель использует осмысленную фразу, то имеет смысл начинать перебор именно с таких.
Мое личное мнение - парольная фраза должна быть грамматически правильной, потому что так легче запомнить. Но одновременно быть бессмысленной - для повышения сложности перевода. Вида "Провод с голубыми зубами пел золотоносную дорогу."
И да, давно хочу генератор таких, чтобы гарантировал нужное количество энтропии.
sim31r
По сути вы перешли от букв к иероглифам, для иллюстрации, как-бы приводим пароль в обычный вид, ваша фраза на китайском "藍牙鐵絲唱響金路". Пространство комбинаций действительно больше, так как слов-иероглифов больше, чем букв и пароль в целом сложнее получается.
inkelyad
Посмотрел в онлайновых переводчиках. Не, никакого Bluetooth я не имел в виду. То что так получилось - это демонстрация того, что человек весьма паршиво случайные фразы придумывает. Вечно ассоциации лезут. Потому и хочу генератор.
K0styan
Именно так. По сути такую фразу можно рассматривать как относительно короткий пароль, всего из 6-7 знаков, но выбранных из многотысячного алфавита.
А если использовать архаизмы и жаргонизмы, то алфавит ещё сильнее разрастётся.
inkelyad
Просто случайны набор слов (как в примере "конь ингредиент страница красивый наклейка"?) - тоже можно так рассматривать.
Вот только такой набор тоже порядком трудно запомнить. Нужное количество бит приводит либо к длинной последовательности слов (8192 популярных слов - это 13 бит на слово), либо словарь пополняется словами, которые уже трудно как вообще вспомнить, так и вспомнить, как оно пишется.
Отсюда и желание грамматической правильности фразы.
Gugic
Можно еще добавить энтропии заменяя некоторые буквы спецсимволами
Aizz
Странно, что вам еще не ответили комиксом из XKCD. https://xkcd.com/936/
Вообще говоря, это хорошо видно по табличке со скоростью взлома пароля. Достаточно добавить всего 1 короткое слово в мастер-фразу состоящую только из букв, чтобы достигнуть той же сложности, что предоставляет длинный сложнозапоминаемый пароль в 13 символов со спецсимволами, цифрами и буквами
Disel0k
скорее https://xkcd.com/538/
VADemon
Расчет энтропии в этом комиксе завязан полностью на алгоритм (случай: алгоритм известен). Обсуждали тут. Не знаю, насколько это применимо к практике.