Comments 184
Интересно, а вы храните детскую порнографию или уходите от налогов?))
А теперь без шуток.
Насколько безопасно создавать ключевые фразы вместо случайных символов для паролей или мастер пароля?
Кстати, мне кажется раскрыв эту схему вы сняли один фактор безопасности) ну да ладно, у вас ещё много в запасе
С точки зрения брутфорса парольные фразы надёжнее. Слов больше, чем букв.
Но вот с точки зрения социального взлома, когда злоумышленник смотрит на то, как вы вводите пароль, понять, что вы пишите слова, и тем более запомнить их с первого раза - на мой взгляд в разы проще, чем случайный набор символов.
Если речь о менеджере паролей - аналогично, т.к. не всегда вы вводите пароль на том устройстве, на котором менеджер. Бывает, вы смотрите на него в телефоне и вводите в компьютере. Одного корокого взгляда злоумышленника на фразу будет достаточно, что бы запомнить.
Раскрытие схемы - это как опен сорс :) найти дыры проще, зато в комментариях на эти дыры успеют указать раньше, и укрепят систему.
П.С. если бы была детская порнография или проблемы с налоговой нету ;)
Тогда вопрос. А если в фразе есть смысл? То есть она является вполне обычным предложением. Это сильно ухудшает безопасность?
Я имею ввиду - насколько "конь пробежал милю за два часа" хуже, чем "конь ингредиент страница красивый наклейка"?
А если в фразе есть смысл? То есть она является вполне обычным предложением. Это сильно ухудшает безопасность?
С точки зрения перебора - если известно, что цель использует осмысленную фразу, то имеет смысл начинать перебор именно с таких.
Мое личное мнение - парольная фраза должна быть грамматически правильной, потому что так легче запомнить. Но одновременно быть бессмысленной - для повышения сложности перевода. Вида "Провод с голубыми зубами пел золотоносную дорогу."
И да, давно хочу генератор таких, чтобы гарантировал нужное количество энтропии.
По сути вы перешли от букв к иероглифам, для иллюстрации, как-бы приводим пароль в обычный вид, ваша фраза на китайском "藍牙鐵絲唱響金路". Пространство комбинаций действительно больше, так как слов-иероглифов больше, чем букв и пароль в целом сложнее получается.
Посмотрел в онлайновых переводчиках. Не, никакого Bluetooth я не имел в виду. То что так получилось - это демонстрация того, что человек весьма паршиво случайные фразы придумывает. Вечно ассоциации лезут. Потому и хочу генератор.
Именно так. По сути такую фразу можно рассматривать как относительно короткий пароль, всего из 6-7 знаков, но выбранных из многотысячного алфавита.
А если использовать архаизмы и жаргонизмы, то алфавит ещё сильнее разрастётся.
Просто случайны набор слов (как в примере "конь ингредиент страница красивый наклейка"?) - тоже можно так рассматривать.
Вот только такой набор тоже порядком трудно запомнить. Нужное количество бит приводит либо к длинной последовательности слов (8192 популярных слов - это 13 бит на слово), либо словарь пополняется словами, которые уже трудно как вообще вспомнить, так и вспомнить, как оно пишется.
Отсюда и желание грамматической правильности фразы.
Можно еще добавить энтропии заменяя некоторые буквы спецсимволами
Тут мы уходим в тонкости словообразования) Никто не мешает (в русском языке!) докидать окончаний и предлогов так, чтобы слова грамматически согласовывались. При этом словарь для перебора только возрастёт: там придётся держать не только дефолтные формы, а ещё и склонения-спряжения.
При этом словарь для перебора только возрастёт
Но немного упрощается перебор. Если мы знаем, что фраза поставлена грамматически правильно - то 'река желтый' можно смотреть потом, а сразу начинать с 'река желтая'.
Можно делать рифмованные фразы для лучшего запоминания.
ТралиВали-ТинкиВинки-ЧерриБерри
ТиллиВилли-МерриФерри-ТораБора и т.п.
Запоминается легко, перебирать долго и сложно, сами фразы бессмысленные, но легко ассоциируемые с чем-то знакомым.
Это до тех пор, пака фраз мало. Чуть больше - начинают путаться в том числе и между собой. И, рифмованность - тоже должна помогать перебору. И проблема с воспроизводимостью вида "в этом ТиллиВилли где одна 'л' а где две?"
А их и не нужно много. Это фраза для мастер-пароля, которую вводишь один раз для анлока парольного менеджера.
И, рифмованность - тоже должна помогать перебору.
Это нужно знать, что пароль рифмованный. Да и поможет не сильно, учитывая количество потенциально рифмованных слов.
И проблема с воспроизводимостью вида "в этом ТиллиВилли где одна 'л' а где две?
Практика показывает, что после нескольких повторений запоминается хорошо. Главное - заставлять себя регулярно вводить этот самый мастер пароль, тренируя мышечную память. Ну, и даже если забыли точное написание - вариантов не так много, можно и подобрать правильный, если рифма хорошая.
И проблема с воспроизводимостью вида "в этом ТиллиВилли где одна 'л' а где две?"
К слову, это ж просто пример. Можно брать рифмованные пары с более однозначной орфографией, без двойных/одинарных букв.
АбраКадабра-АськиМасяськи-АхалайМахалай
Держите пример:
Vipnet Password Generator
Может генерить разные варианты, там есть даже португальский:
42Cdt;LtdbGjvfGhjiErkj
42 Свежевыбритые Девицы Поманили Прошлого Уклониста
47LiloProzVvinStalDire
47 Lilovyh Prozaikov Vvinchivayut Stal'nogo Direktora
80IgneBachAddlFrivTele
80 Igneous Bachelors Addle a Frivolous Telegraphist
Парольную фразу заметно легче запомнить, чем "42Cdt;LtdbGjvfGhjiErkj".
Да, фраза получается более предсказуемая - как минимум набор спецсимволов ограничен теми, что на месте русских букв на клавиатуре, но при этом длина фразы компенсирует.
Еще есть фактор, что словарь в генераторе довольно ограниченный, но это компенсируется головой - посмотрел на сгенерённый пароль и рассказал немного другую историю:
"24 Загорелых Культуриста Загоняли Унылого Комика"
Еще легче запомнить фразу, построенную на основе стиха. Ритм и рифму мозг запоминает на 100500% легче. Не знаю, насколько страдает устойчивость к брутфорсу, но случайно выданный мозгом год назад стих намертво отпечатался в памяти, и мне кажется, суперкомпьютер скорее сопьется и уедет в Питер (порядок может варьироваться), чем подберет ее. Собственно, строка:
"Буженина из енота довела нас до икоты"
P.S. Осуждаю нецелевое использование енотов, берегите природу
Склонение имён существительных сильно усложнит перебор (даже с учётом того, что символов там будет меньше). Если вас пытаются взломать перебором слов, то начнут с именительного падежа.
Вероятность повторения осмысленных фраз выше, тк они придумываются человеком, к значит и выше попасть после утечки чужого пароля.
Странно, что вам еще не ответили комиксом из XKCD. https://xkcd.com/936/
Вообще говоря, это хорошо видно по табличке со скоростью взлома пароля. Достаточно добавить всего 1 короткое слово в мастер-фразу состоящую только из букв, чтобы достигнуть той же сложности, что предоставляет длинный сложнозапоминаемый пароль в 13 символов со спецсимволами, цифрами и буквами
скорее https://xkcd.com/538/
Расчет энтропии в этом комиксе завязан полностью на алгоритм (случай: алгоритм известен). Обсуждали тут. Не знаю, насколько это применимо к практике.
Мне осталось теперь найти соответствующие серьезности этого подхода секреты, которые я хочу сохранить.
менеджер паролей в облаке, это слабое место. рано или поздно, под тяжестью разных причин, все что храниться в облаке будет доступно корпорациям (продадут поисковики)
Bitwarden доступен, как self-hosted. Можео все данные храниь на своём сервере.
Но даже если его хостит ктр-то другой, данных у него всё равно нет.
Данные шифруются алгоритмом AES по 256 бинтому ключу, сгенерированному по алгоритму argon2id, настройки которого может менять сам пользователь. Расшифровка происходит исключительно на стороне клиента.
Можно накрутить так, что даже всех мощностей гугла, амазона и майкрософта не хватит, что бы расшифровать выша данные за тысячелетия.
А вот когда сделают домашние квантовые компьютеры!!
Всегда забавлял тот факт, что люди уверены, раз решение оупенсорсное и лежит на гите, значит все прозрачно. Откуда такая уверенность в том, что на чьем-то чужом сервере развернут тот же самый код, что и в репе? Кто мешает допилить "серверную" версию так, чтобы невозбранно читать чужие секреты (про репутацию речи не ведем)?
Кто мешает допилить "серверную" версию
Шифрование мешает
откуда вы знаете, что на серверах bitwarden.com зашифрованы БД с паролями их клиентов? что они не хранятся плейнтекстом
От используемого мной клиента, который я (предположим) собрал самостоятельно из проверенных исходников и который шлёт на сервер только зашифрованные данные без пароля
Вы провели полный аудит исходного кода клиента и компилятора?
Проблема текущих технологий в том, что слишком много звеньев находятся не под контролем.
Я — нет. Но вам всем в этой ветке пытаются донести мысль, что такой аудит провести теоретически можно, потому что исходники клиента доступны (или можно даже попытаться написать свой клиент с нуля, почему бы и нет)
Сервер в данном случае не имеет никакого значения, потому что он получает только зашифрованные данные, и самое страшное, что он может попытаться сделать, это брутфорс
Bitwarden заявляет, что шифрует базу на локальном устройстве, на сервер уходит уже зашифрованная. Открытые исходники клиента позволяют в этом убедиться.
При условии, что вы лично собираете клиент из исходников, а также контролируете все зависимости.
Это максимально строгий вариант. Есть второй по строгости, не сильно уступающий:
Кто-то, кому я доверяю, собрал клиент и опубликовал подтверждение совпадения бинарников.
И есть третий:
Любой может собрать клиент и опубликовать обвинение, если обнаружит критичное расхождение.
Он нестрогий ни разу, между вторым и третьим - пропасть. Но он создаёт риски для автора ПО. Я со своей стороны могу положиться на то, что автор не захочет срабатывания рисков. Это уже делает ПО более надёжным, чем чисто проприетарное.
Кто-то, кому я доверяю, собрал клиент и опубликовал подтверждение совпадения бинарников.
И этот кто-то все так же должен проверять исходники клиента и зависимостей. Иначе просто "доверять" нет смысла.
Любой может собрать клиент и опубликовать обвинение, если обнаружит критичное расхождение.
Как обнаружит расхождение? Deterministic builds? С этим все немного печально в сабжевом случае.
Я со своей стороны могу положиться на то, что автор не захочет срабатывания рисков.
Или делает так, чтобы минимизировать возможность спалиться. Плюс, учитывая что сабжевый клиент постоянно онлайн с их сервисами, может быть всякое.
На самый крайний случай всегда можно сказать "нас взломали", и практически ничего не будет. Ластпасс, например, сколько процентов клиентов потерял?
Я согласен, но акцент сделан на то, что можно посмотреть как система работает под капотом. Грубо говоря, что бы шифратор, который я порекомендовал не использовал md5 для хэширования. Даже когда в README написан какой-то алгоритм, узнать, по каким параметрам он работает можно только из сорсов.
Про bitwarden в данном случае согласен. Но эта бреш минимизируется двухвакторкой и дополнительными кусками паролей.
Если вы по коду клиентской версии видите, что всё шифрование производится локально и на сервер отправляются только зашифрованные данные, то уже не столь важно, как там устроена серверная сторона, ваши данные она не получит в любом случае (понятно, если шифрование надёжное и в клиенте нет незамеченных бэкдоров).
Впрочем, я не знаю, так ли оно устроено у Bitwarden'а или там всё-таки шифрует сервер; во втором случае, разумеется, уверенности быть не может. Лично я предпочитаю держать пароли в локальной базе (KeePass) и синхронизировать эту базу отдельной программой.
Вот мне, кстати, всегда было интересно - на том же Dropbox наверняка лежат тыщи файлов .kbd/.kbdx, причём некоторые - годами. Будь я злодеем и заодно владельцем этого Dropbox-а, я бы каждый из них давно попытался пробрутфорсить)
Вот, к слову, да, этот фактор тоже часто упускают из виду, что данные, которые невозможно расшифровать сейчас, могут оказаться доступными для взлома когда-то потом (открытие новых алгоритмов или ранее незамеченных уязвимостей в шифровании, развитие вычислительных мощностей, квантовые компьютеры…). И я плохо представляю, как можно защититься от этого. То есть, понятно, что не стоит разбрасывать даже зашифрованные секретные данные по всем общедоступным местам, но если кто-то получит файл в результате взлома или кражи устройства, то дальше останется только надеяться, что к моменту возможности расшифровки злодей просто потеряет интерес (или файл).
Со своей стороны стараюсь всё-таки не пользоваться хранилищами типа Dropbox, предпочитаю пиринговые или self-hosted решения. Скажем, Syncthing довольно интересен, хотя и небеспроблемный.
для защиты от того, что кто-то сохранит копию БД с паролями и сможет взломать потом надо просто регулярно менять пароли (т.о. утёкшая копия БД с паролями станет не актуальной). если говорить про то, что БД лежит в недоверенном месте (чужое облако), то надо прст регулярно менять ещё и алгоритмы шифрования на современные и не подверженные уязвимостям.
Смена паролей, конечно, помогает, но когда в базе под две сотни записей, делать это становится несколько напряжно. Не говоря уж о том, что в базе можно хранить не только пароли, а ещё и другие данные, которые поменять сложно или вовсе невозможно (скажем, лицензионные ключи купленных программ; приватные ключи сертификатов, которые нежелательно терять даже после истечения сроков действия…).
Даже не то, что "могут потом" из-за алгоритмов или уязвимостей. Дропбокс в 2007 запустили. Какие-то файлы с паролями уже почти 17 лет как могут где-то уютно брутфорситься.
Ну, если алгоритм и длина пароля такие, что брутфорс занимает миллиард лет на современном оборудовании, то эти 17 лет погоды не сделают.
За 17 лет затраты энергии будут миллионы $ стоить на брутфорс. Еще один ограничивающий фактор. Тем более мало кому интересны секреты 2007 года.
Кто-нибудь, сохранивший по наивности свой wallet.dat от биткоина в году 11-ом и попавший в аварию. Как не вариант?
Если перебор займет 15 лет и миллионы $ на энергию, то можно прогореть на проекте, так как курс биткоина не стабилен. Все могут перейти на Эфир, Dodgecoin и подобное. Или криптовалюты могут запретить, как это было с Либерти Резерв. Взломав кошелек можно не получить средств, которые покроют затраты.
Можно же и не хранить эти файлы с явным расширением .kdb? Сигнатуры же там нет, я полагаю, соответственно и ваш файл с названием binary.dat не будет очевидной целью атак.
https://github.com/bitwarden/clients/issues/5734
Наизамечательнейший интерфейс Хабра стер весь комментарий, потому что я нажал на другую кнопку ответить ниже. Ограничусь потенциальной атакой сославшись на dependency in npm repos.
Для тех кто хочет заселфхостить себе парольный менеджер есть ещё более крутой вариант: Vaultwarden - альтернативная, более легковесная, простая, понятная и минималистичная реализация сервера Bitwarden, на Rust
менеджер паролей в облаке, это слабое место. рано или поздно, под тяжестью разных причин, все что храниться в облаке будет доступно корпорациям (продадут поисковики)
Даже если кто-то скопирует шифрованную базу ваших паролей, без мастер-пароля это более чем бесполезно.
Вам нужно ввести куда-то пароль. Сколько действий для этого потребуется?
В самом защищённом варианте:
Ctrl+Shift+L (для активации плагина bitwarden)
Ввести мастер пароль от bitwarden
Докоснуться до ключа yubico для авторизации в bitwarden
Дописать вторую часть пароля от аккаунта из головы
Докоснуться до ключа yubico для авторизации в аккаунт
В наиболее частом сценарии только:
Ctrl+Shift+L (для активации плагина bitwarden)
Ввести мастер пароль от bitwarden
Докоснуться до ключа yubico для авторизации в bitwarden
Докоснуться до
Я первый раз слышу такой оборот, это местный диалект, эрратив или какое-то старинное слово отсутствующее в словарях?
Такое слово в русском похоже есть, и оно достаточно старое, правда в современном языке используется редко. Но возможно напоследок его используют чаще. Язык меняется.
В болгарском используется именно «аз докосвам, ти докосваш, той(тя, то) докосва».
Автор из Латвии. Вполне возможно, что там принято так говорить
относительно не дорогой, т.е. альтернатив дешевле я не встречал
Rutoken MFA стандарт Fido2 U2F дешевле даже базовой версии yubico, сели смотреть 5/5с и тд с поддержкой openpgp то разница ещё выше, а ключей требуется все равно 2.
Спасибо! Действительно достойная альтернатива.
Rutoken
Я пару раз уже было порывался прикупить, но каждый раз останавливало "а нет ли там закладок"?
По факту, закладки могут быть везде, intel me закладка? В ключах шифрования одобреные nist есть закладки?
Тут как бы rutoken ecp 2.0 flash 32g куплен не для того чтобы хранить пароли а для того что бы иметь "флешку" с защитой от записи, а сами пароли храните в контейнере с aes256 с увеличенным числом итераций (например veracrypt). А в качестве безопасного токена для удалённого доступа очень даже подходит даже не смотря что там могли заложить закладку , т.к. на нем не хранится в открытом виде конфиденциальной информации
Гораздо более интересный вопрос - а нет ли у товарища майора "мастер-ключа"?
В случае с тем же yubikey на заокеанского господина майора в принципе пофиг.
MFA построен на стандарте fido2, а это шифрование не одобренное товарищем, открою секрет, любой токен с неизвлекаемыми ключами можно взломать, вам потребуется лазер и электронный микроскоп, было бы желание взломать, вас взломают, а сами же пароли я храню в контейнере aes256, и любую важную информацию так же, с правдоподобным отрицанием, а токены это защита не от товарища майора, а от хакеров, если товарищ возьмётся за вас, вы сами ему все расскажете покажете, паяльник ни кто не отменял.
Я не думаю, что вы мне что-то новое расскажете. Я, скажем так, немного в теме.
любой токен с неизвлекаемыми ключами можно взломать, вам потребуется лазер и электронный микроскоп
Это не так. Вернее, не совсем так. Можно посмотреть состояние прожигаемых перемычек или общую схемотехнику. Состояние ячеек флэшки вы не посмотрите. Горячая пробирка выглядит точно так же как и холодная (ц)
а от хакеров
Если мастер-ключ существует, и у кого-то есть, то рано или поздно он появится в продаже для "заинтересованных лиц". В некоторых случаях эти "кто-то" могут явно ускорить появление подобных вещей у "заинтересованных лиц".
Дополню для шифрования критической информации дополнительно шифруется открытым ключем ed25519
А не подменили ли вам ваш hardware key, пока он ехал к вам почтой?
В табличке надежности паролей меня всегда удивлял тот факт, что пароли, на подбор которых нужно 3 года и 69000 лет находятся в одной (оранжевой) группе риска. Особенно удивляет, что кому-то 690 веков кажется недостаточно долгим сроком для подбора.
Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Я пользуюсь хранилищем KeePass XC на телефоне и десктопах, хранилище само хранится в условном домашнем облаке доступ со всех устройств шифрование канала в наличии, в браузерах полный запрет на сохранение пароля, стоит интеграция с браузером для ввода паролей. Весьма удобно когда привыкнешь. Ageis для 2fa, рутокены mfa для fido2 авторизаций, ssh и тд. Рутокен эцп 2.0 flash для безопасной os без возможности изменения, и так же доступ по сертификатам к vpn, ssh и тд.
стоит интеграция с браузером для ввода паролей
На Android и iOS тоже работает?
IOS не знаю, на android есть magikeyboard для KeePass(как бы его часть), она занимается автозаполнением при разблокированной базе
Это ещё стороннюю клавиатуру ставить надо? Уффф.
В Android можно выбрать KeePass как autofill service по умолчанию, тогда вторая клавиатура не нужна.
А как это настроить для браузера в телефоне? Только через встроенную клавиатуру Keepass?
Как только для браузера - не знаю. Знаю, как настраивается на уровне всей системы Android: Settings - additional settings - languages & input - additional keyboard settings - autofill service
А как это, собственно, работает? В смысле - как этот autofill сервис понимает, кому можно отдавать запомненное содержимое, а кому нет?
А то ведь, насколько я понимаю, попросить 'заполни мне тут поля' может не только браузер, но и что-нибудь зловредное?
У вас в базе данных KeePass для каждой записи должна быть связка юзернэйм - пароль - сайт. Autofill service видит, на каком сайте или в каком приложении вы сейчас, предлагает разблокировать базу и тем самым вбить данные в поля. Правильное название сайта в безопасном формате (со /на конце) в запись вбиваете вы сами заранее, либо сами дополняете связку юзернейм-пароль сайтом, когда Keepass предлагает это сделать. Можно выбрать запись из базы и вручную, если сайт для записи не прописан.
Autofill service видит, на каком сайте или в каком приложении вы сейчас, предлагает разблокировать базу и тем самым вбить данные в поля.
Так он же на сам просто так догадывается, а ему приложение сообщает. Что произойдет, если какой-то зловред то же самое сообщит? "Я тут нахожусь на google.com. Пожалуйста, предложи пользователю заполнить..." после чего пара неудачных кликов (зловред постарается разместить поля так, чтобы пальцы сами попадали куда не надо) - и вставленный пароль достаются зловреду и он их хозяину отправляет.
Поля на сайте \ в приложении заполняются автоматически, но лишь после того, как вы сами разблокировали базу и разрешили заполнение. На фишинговых сайтах я пробовал, и форму заполнить не прдлагает, потому что адрес сайта в браузере и адрес сайта в базе отличаются. Хотя, конечно, 100%-ой "защиты от дурака" нет, как и в любом другом парольном хранилище, но это проблема уже прослойки между стулом и клавиатурой.
Она идёт вместе с KeePass это его модуль
Там есть системная служба автозаполнения, на деле выходит даже удобнее, чем на компьютере. Для iOS пользуюсь Strongbox, он правда стоит прилично, но это его единственный минус.
А что думаете по поводу 1password?
Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Факт, но дело в том, что это только прикидочные значения. 24 года запросто могут превратится в 1 год и меньше, если кто-то решит что это важно для него. Ну или если резко подешевеют вычислительные мощности.
Мне кажется, что пароль, на подбор которого нужно 24 года, уже вполне себе надежный.
Вот не факт, ситуации разные бывают.
Учтите, что подбор паролей параллелится почти идеально.
Это значит, что условная RTX 4090 в 100 раз производительнее CPU.
Т.е. поставив одну 4090 мы 24 года рассчётов превращаем в 4 месяца.
Что будет если поставить несколько - считайте сами.
Если нужно расшифровать rar архив длиной в гигабайт созданному в режиме solid, скорее всего не получится ускорить процесс видеокартой. Так как нужно пробегать по всему файлу до конца каждый раз.
Вы считаете, что пример со вскрытием гигабайтного rar - хороший (близкий к репрезентативному) пример в даном случае?
Откуда такие данные? Там наверняка ключ зашит в header и только его надо расшифровать паролем. У hashcat есть брутфорсилка.
Ключ надо проверить.
Если для проверки нужно расшифровать гигабайт, распаковать его и сосчитать контрольную сумму от получившегося - то быстро подбирать вряд ли получится.
https://www.doyler.net/security-not-included/crack-rar-files-hashcat
Тут правда rar3, но сначала выдирается хэш пароля и только по нему брутфорсится.
Дальше по ссылкам:
/* 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 архивом, как предлагалось - непонятно.
<после гугления>
Возражение отменяется - судя по всему так таки есть возможность проверить ключ, не расшифровывая каждый раз весь файл.
В случае с argon2id - вычисление хэша пароля зависит не только от производительности CPU, но и от RAM
TOTP (2FA) не зависит от подключения к серверу и вычисляется по формуле. KeePassXC и Aegis выдают один TOTP независимо.
Пароль можно использовать в одно слово, потому что подобрать файл-секрет 1МБ сложно. В Инете полно файлов с хешами, которые не изменятся уже никогда по историческим причинам.
Синхрон в облака и Syncthing обеспечат доступность базы.
Как всё переусложнено.
Берём GNU pass.
Добавляем плагины для автоввода и OTP.
Добавляем все пароли и коды восстановления и прочие ваши секреты.
Добавляем всё это дело в гит репозиторий. Remote для этого репозитория можно сделать хоть какой, хоть на гитхабе, хоть селф-хостед, хоть bare поверх ssh.
Берём мобильный клиент pass и синхронизируем с гит репозиторием. Он тоже умеет всё вышеперечисленное.
Плюсы такого решения:
Очевидно селф хостед со всеми вытекающими
Открытые исходники
Синхронизация на любое количество и любой вид устройств
Минусы такого решения:
Для добавления новых устройств необходимо секурно передать gpg-ключи на целевое устройство, что в случае с мобильником может быть неудобно.
Да... плхоже такая схема в плане безопасности не худа.
Мне в этом не хваьило бы веб-клиента, на случай если используется чужое устройство.
Но, мне нравится. Обязательно поразмышляю над таким вариантом
Считаю любые web доступные хранилища паролей уязвимыми.
Для добавления новых устройств необходимо секурно передать gpg-ключи на
целевое устройство, что в случае с мобильником может быть неудобно.
Передача файла ключа через USB-подключение телефона не достаточно безопасна?
репохостинг будет знать какими сервисами вы пользуетесь (если вы, конечно, не зашифруете репозиторий)
У меня свой сервачок на линухе, репо - обычный git bare. Смысл в том, что в случае с гитом у вас множество вариантов. Кроме того, структуру папок и название файлов придумываете вы сами, тут уж насколько фантазии хватит.
С чего бы это он будет знать? БД зашифрована.
У pass нет БД, есть отдельные файлы, которые раскладываются по директориям. Удобства ради многие используют структуру /private/email/gmail.com, /private/email/proton.com и в таком духе, в таком случае репохостер будет знать какими сервисами вы пользуетесь. К pass есть куча разных плагинов и гуи, позволяющие, например, при выборе /private/email/gmail.com автоматически отрыть gmail.com и заполнить все поля, включая при необходимости OTP.
Но по скольку это всего лишь директории с файлами, названия файлов необязательно должны совпадать с названиями сервисов.
По сути pass - баш скрипт, при желании приделать шифрованную БД не составит труда. Возможно такой форк/плагин уже имеется, я фиг знает.
Добавляем всё это дело в гит репозиторий. Remote для этого репозитория можно сделать хоть какой, хоть на гитхабе, хоть селф-хостед, хоть bare поверх ssh.
А в каком виде будут хранится пароли в репо на гитхабе?
Немного критики и рацпредложение.
В один прекрасный момент онлайн версия Bitwarden будет взломана, всё что делается на стороне клиента будет в открытом виде у хакера, и все мастер пароли утекут (Как регулярно происходит с другими подобными парольными менеджерами). Можно и сэлфхостить, но проблемы этого всем понятны.
То есть для условной вражеской разведки способ получения пароля - в наиболее частом сценарии - надо как то взломать/подделать сайт, заставить ввести на нём мастер пароль (например поставить человека в жёсткие временные рамки с отвлекающими факторами, или просто напоить и банально записать на камеру пароль), потом физически отнять yubico и всё. Почти та же схема, как для разблокировки телефона заблокированного отпечатком пальца, сотрудничество клиента необязательно. То есть все хитрости становятся бессмысленными при серьёзном подходе, а при несерьёзном - keepass достаточно.
3 (10 - 100) лет подбора в эпоху развития искусственного интеллекта, когда доступность систем с десятками тысяч высокопроизводительных серверов стало реальностью, выглядит не очень хорошо - на системе из 10000 серверов 100 лет работы превращается в 12 часов, а с учётом nvidia ускорителей в один час или в одну минуту или ещё быстрее.
Можно использовать немного другую схему генерации пароля - не слова или случайные символы, а несколько первых символов из слов какого нибудь стишка, который придумывается самостоятельно и который можно запоминать даже используя какой то открытый текст с ассоциациями, которые постороннему непонятны. Это позволяет получить пароли любой разумной длины (и прокачать свои стихотворческие скилы).
несколько первых символов из слов какого нибудь стишка
Сорок тысяч обезьян в жопу сунули банан.
3 (10 - 100) лет подбора в эпоху развития искусственного интеллекта, когда доступность систем с десятками тысяч высокопроизводительных серверов стало реальностью, выглядит не очень хорошо - на системе из 10000 серверов 100 лет работы превращается в 12 часов, а с учётом nvidia ускорителей в один час или в одну минуту или ещё быстрее.
Главное чтобы затраты не превышали стоимость искомого.
То есть для условной вражеской разведки способ получения пароля - в наиболее частом сценарии - надо как то взломать/подделать сайт, заставить ввести на нём мастер пароль (например поставить человека в жёсткие временные рамки с отвлекающими факторами, или просто напоить и банально записать на камеру пароль)
Проще уж тогда как в том комиксе от XKCD. Накачать наркотой и бить, пока не скажет пароль.
Хреновый алгоритм
Человек забывает "bob", и всё, накопленное непосильным трудом и лежащее на криптоадресах, идет коту под хвост...
За Banana Split и схему Шамира спасибо, но имхо, это единственное любопытное в статье (и то, тому, кто про это не знал).
Статья в целом:
а) сценарий шпионского фильма
б) реклама баунти-программы на inbox.eu (?euRefId=68337). Все ссылки нормальные, но эта с "пасхалкой". Написали бы хоть в скобочках.
в) просто крайне неудобная схема. Пароль для хранения пароля для хранения пароля для хранения паролей... Если все так серьезно, то даже само использование последовательности из нескольких онлайн сайтов и сервисов (пусть и javascript, пусть и opensource) уже так себе идея. Я предлагать свои варианты не буду, это вкусовщина. Но во всех таких приколах первое о чем надо думать - о том, насколько все это нужно. Чтобы что хранить? От кого? От жены - смех. От литовских полицаев на границе - ну позвольте, вы сами все покажете, иначе в страну не пустят или задержут, пока не скажете :) Ну и так далее.
Извините, имхо, но это перебор в третьей степени. Но за Шамира спасибо :)
б) реклама баунти-программы на inbox.eu
Извиняюсь. Добавил пометку в скобочках :)
в) просто крайне неудобная схема
Вся схема сводится к тому, что надо использовать парольный менеджер, защищённый 2FA. Всё остальное - это бэкапы. Шифруем, прячем, поддерживаем. В идеале никогда не пользуемся. Но в случае чего - они есть.
за Шамира спасибо :)
Кстати, схема Шамира не единственная, о других можно почитать тут: https://habr.com/ru/articles/783866/
Схема сильно переусложнена. Отказы бывают не единичные, а системные, например когда нет связи в вашей схеме надо вычеркнуть не один компонент, а сразу 3, и это вполне обычная ситуация. Защищать пароли паролями - странно, только число слоев растет, а общая надежность падает. В схеме вообще нет никакой гибкости, секреты не делятся по их ценности и их контролируемости.
А как бы вы посоветовали делать? Интересуюсь исключительно с практическими целями.
Так, как тут многократно описали ниже: KeePass, база на нескольких устройствах, синхронизируемых через публичное облако типа Dropbox, iCloud, Google Drive либо собственное типа Nextсloud. Достаточно помнить всего один мастер-пароль для базы.
У меня есть несколько паролей по уровням важности того что он защищает. То есть, я использую одинаковые пароли для разных ресурсов :) Но есть ньюанс. Пароль хэшируется вместе с именем ресурса чтобы получить то, что я уже ввожу в качестве пароля. Для хэширования у меня есть простенькая вэбстраничка доступная как в сети, так и локально, на всякий пожарный.
Мне кажется что используемая мной схема и и надёжнее и проще, когда я её построил я понял насколько раньше сложно жилось, и как теперь круто. Я даже думал написать статью об этом, но потом понял что security through obscurity, несмотря на критику, также имеет место быть, и публично демонстрировать поверхность атаки на себя смысла не вижу.
Дам такой совет, изучите различные системы, прочтите их руководства и очень внимательно все возможные их настройки, внезапно есть системы которые можно настройками настроить значительно лучше чем они предлагают из коробки. Не факт что вы сделаете также, как у меня, но ваша личная система, при условии что вы не допустите критических ошибок, настроенная неконвенциональным образом, уже будет радикально отделять вас от всех остальных, с точки зрения уязвимости ваших аккаунтов.
как вы оцениваете свою стойкость? сдадите все секреты еще на стадии доставании паяльника или уже на стадии разогрева его на столе?
Тут вроде не от этого защищаются. И от паяльника тоже существуют некоторые меры защиты. Да не абсолютные, как и всё в этом мире, но они есть, и даже у меня. Я не понимаю вашего пассажа. Вы предлагаете не управлять сотнями паролей защищённо? Вы считаете что любая защита информации не имеет смысла, т.к. факапы и взломы случаются? Переформулируйте вопросы в утверждение и тогда, возможно, вам ответят.
Двухфакторка с аппаратным ключом и пассатижами под рукой может оказаться защищённой даже от паяльника. Главное - убедить, что вот эта сломанная "флэшка" - это и был ключ, и без него ловить нечего...
Но тогда придётся жить без бэкапа.
может оказаться защищённой даже от паяльника
Ну-у-у-у, я бы не стал злить людей с паяльником... Единственная реальная защита от паяльника, это отрицаемое шифрование. В смысле, когда даешь хоть что-то, достаточное чтобы тебе поверили. А то, в конце концов тебе поверят, но тебе от этого легче не будет.
И с хорошо пропаяной попой.
Выглядит надёжно. Но всегда есть альтернатива. Один пароль на все случаи жизни и для всех сервисов. Дальше познаём дзен и отказываемся от суеты бренного мира. Если даже взломают, и похитят все наши нехитрые секреты, это никак не повредит нашей душе. Зато свобода головы от кучи паролей и сервисов по их хранению освободит много пространства для настоящей жизни без страха.... Да, знаю. В службе безопасности с таким подходом мне не работать)))
А банки, Госуслуги, риск получить за один день кредитов на 10 миллионов?
Это странный подход. Регистрироваться приходится там, где подход к безопасности не известен. Может там пароли открытым текстом в БД хранятся. Когда-то я использовал специальный пароль, когда регистрировался в самых трешовых местах. Через несколько лет обнаружил его в словаре для брутфорса (ожидаемо). Если бы сейчас это произошло, то я мог бы определить сайт, с которого была утечка (уникальные пароли в менеджере).
Экие ужасы.
Все пароли храню в KeePassXC. Скрипт бэкапит на файлопомойку в другой комнате и на телефон. Один-два раза в год ещё пишу зашифрованную БД на флешку, кладу её в презерватив и прячу на руинах заброшенной свинофермы. Это не шутка, просто я там каждый день хожу.
У меня просто база KeePass лежит в Dropbox, как только что-то в ней меняется - она автоматически синхронизируется средствами Dropbox, в т. ч. и на смартфон. При этом никакой привязки ни к чьим-то надёжным опенсорсным облачным технологиям, ни даже к онлайну в целом нет - база есть локально что на компе, что на смартфоне, а дропбокс, если захочу, я в раз поменяю на какой-нибудь ещё другой бокс. Один мастер-пароль к этой базе как-то все эти годы помню.
Так и есть, самый плюс такого подхода, что не жалко Dropbox аккаунт, он как расходник, даже если потеряю телефон, вещи, документы, всегда могу в любом интернет кафе разблокировать базу с помощью keeweb.
Не понял этого захода. Почему "не жалко Dropbox аккаунт, он как расходник"? У меня этот аккаунт живёт года с 2008, что ли, используется для всякого, не только для паролей. Если я потеряю телефон, компьютер(ы) и пр. "флэшки" с базой KeePass, а пароль к Dropbox не вспомню - то всё, пароли пропадут.
У меня Dropbox только для этого kdbx файлика, не жалко в том смысле, что если я буду вводить его в небезопасных местах и устройствах, для доступа через keeweb.
Из этого Dropbox папка /Apps/KeeWeb/ синхронизируется с основным облаком автоматически, т.е. kdbx на Dropbox, основном облаке, телефоне, планшете и компьютере (еще раз в месяц в первое число по cron'у kdbx бэкапится на mega, но то уже параноя).
В смысле, пароль к аккаунту Dropbox в небезопасном месте скрадут, но не жалко, а пароль к kdbx тоже скрадут (место-то всё то же, и всё такое же небезопасное?), но тоже не жалко? Или как?
Вы правы, в небезопасных местах лучше не вводить никакие пароли.
Расходник Dropbox из-за того, чтобы показать непривзятость к какому-то единому серверу хранения файла парольного менеджера.
Для небезопасных мест, теоретически, существуют одноразовые пароли, но это совсем другая история. Схему, как на небезопасном компьютере безопасно посмотреть свой пароль, придумать можно, только зачем - ты ж не будешь его на этом небезопасном там же и вводить, пуская всю безопасность прахом, а если рядом есть безопасный, куда вводить пароль - так там же его и посмотреть можно.
Как-то понадобилось срочно перебронировать билеты в отпуске. Роуминг сломался, я в отеле в глуши, единственный вариант - публичный комп в холле отеля (с WiFi там тоже сложно было)
Разрулил локальной базой KeePass на смартфоне. Да: смотрел пароль безопасно, а вводил на небезопасном устройстве. Но только один, от сайта авиакомпании, что в моменте приемлемо было.
Некоторое время назад придумал простую схему пароля - беру первые 3 буквы в названии сервиса или сайта, первая буква идет заглавной, вторая строчной а третья превращается в символ который сверху от нее в разделе спецов. Затем добавляем название сервиса и повторяем для длины второй раз 3-символьный код. Запомнить элементарно, хранить не нужно, уровень безопасности - только если специально следить или как то получить несколько паролей для анализа (хотя кому я сдался). Пример пароля - habr.com = Ha^habrHa^ (нет, это не мой настоящий пароль).
Думаю, почти все через подобные конструкторы проходили. Я отказался после того, как сначала алгоритм оказался неудобен для одного из сервисов, а позже я стал путать, в каком сервисе используется старый алгоритм, а в каком - новый.
Хуже того: пара сервисов объявили об утечке и заставили сменить пароль на новый, другой. Пришлось модернизировать алгоритм ещё раз, что путаницы добавило.
Тут была уже минимум пара постов про парольные менеджеры, которые ничего не хранят, а детерминистически генерируют пароль к любому сервису по URL-у этого сервиса и мастер-паролю. Проблемы с ними, впрочем, все те же, плюс добавляется необходимость где-то держать и каждый раз запускать этот менеджер, в отличие от достаточно простого мнемонического правила, позволяющего пароль в уме генерить.
Много кто через подобное проходит(я тоже). А потом, по каким либо обстоятельствам, надо сменить пароль и опаньки, появляется Ha^habrHa^1 или 97 или "ваш пароль может содержать только символы которые мы разрешаем" и появляется Ha@habrHa@1. А потом, блять, какая же версия схемы используется на этом сайте, v1 или v4)
Попробовал вспомнить свои выжившие пароли, созданные по подобной схеме.
В одном после 5 что ли смен схема изменилась до неузнаваемости (остался только ....habr.... посередине), но самое смешное - сервис переименовался, так что и habr уже неактуально.
Другой до сих пор живёт как есть - но уже на другом сервисе, на который я переехал с исходного)
Не понял про спецсимволы. В большинстве клавиатур клавиши сдвинуты по отношению друг к другу. Не некоторых друг над другом. Легко ошибиться. Могут быть экзотические клавиатуры. Иногда надо набирать с телефона. Вариантов не попасть в нужный символ масса.
Я изобретал ̶в̶е̶л̶о̶с̶и̶п̶е̶д̶ генератор паролей похожим образом, на основе адреса сайта, но по ряду причин отказался от принципа "Security through obscurity" (спойлер: прочитал у авторитетных источников, что это плохая практика :)
Но попыток не оставил, вот что получилось на данный момент:
Составная фраза для генерации пароля онлайн. Да, свои недостатки в использовании интернета и сторонних сервисов, но их тысячи, найденный мной меняется на другой без ущерба для функционала. (Или пишется свой, благо с использованием chatgpt даже не нужно уметь в программирование, надо лишь уметь сформулировать запрос)
Фраза состоит из следующих частей:
Мастер-пароль. Его надо помнить (записать/хранить в труднодоступном месте, все как обычно)
Адрес сайта или сервиса
Дата изменения пароля.
Пример. Мастер-пароль (тссс!, никому, это секрет) - Password123
Сайт habr.com, дата - today
Фраза получается "Password1 habr.com 19.01.24". Несекретную часть ("habr.com 19.01.24") можно записать хоть в текстовый файл на рабочий стол, из нее ̶т̶о̶в̶а̶р̶и̶щ̶ ̶м̶а̶й̶о̶р̶ злоумышленник поймет лишь то, что (возможно) на некоем сайте вы такого-то числа меняли пароль. Хотя, не все сайты одинаково полезны..
По адресу https://hash.online-convert.com/sha256-generator вставляем фразу, жмем "Start->"
https://i.imgur.com/Ggcp4OO.png
Что удобно, данный сервис сразу выдает не только HEX-строку, но и кодирует её в Base64, копируем 14 символов, это и будет новый пароль:
https://i.imgur.com/oB5GQLR.png
Опять же повторюсь, нет никакой необходимости пользоваться именно данным сайтом, можно получить HEX-строку на одном, а кодировать в Base64 на другом.
В чем я вижу плюсы данного подхода?
Полученные пароли выглядят достаточно рандомно (конечно, не совсем, так как hex->base64 ограничивает варианты)
Список адресов, с датами изменений паролей, не представляет особой ценности без мастер-пароля
Смена даты или мастер-пароля (даже 1 символа) меняет весь генерируемый пароль целиком.
Не придумал ))
Возможно, эту идею еще как-то можно еще развить для удобства и безопасности. Всем добра!
Очень круто. Решает проблему версионинга. А сам файлик можно организовать в виде обманки, как например личный файл лога, или дневника формата твиттера с ложными записями, то даже не будет возникать мысли, что файлик как-то связан с авторизацией.
Единственной проблемой будет, не раскрыть свой метод, когда пароль надо извлеч из хранилища и использовать для входа, когда рядом стоят люди и смотрят тебе в экран.
Смотрите, то есть вам приходится:
а) запоминать мастер-пароль;
б) использовать некоторое ПО - а значит, позаботиться о его доступности везде, где вам понадобится ввод пароля (а это необязательно веб);
в) держать так же доступной некую базу.
То есть в принципе набор артефактов что в вашей методике, что при использовании типового менеджера паролей - одинаковый. Да, не надо переживать за бэкдоры в коде менеджера и за то, что база попадёт в руки негодяя-брутфорсера, но в плане удобства разница минимальна.
Для использования:
древний, немного устаревший (на PBKDF2 немного косятся) CryptoPass
более новый (использует bcrypt) Password Generator (PFA)
Помню один мастер-пароль и файл KeePass держу на Яндекс.Диске. Парольной базой пользуюсь на Винде, Макоси и Андроиде. Для совсем не ответственных и одноразовых регистраций использую пару-тройку старых паролей, которые въелись в память.
несколько kbdx файлов в облаке. несколько потому, что разные назначения, допустим, банки - отдельно, открываются редко.
"Это немецкое/шведское/японское, а значит хорошее" такой себе аргумент. Но, если что, Bitwarden он американский, а не немецкий.
"Это немецкое/шведское/японское, а значит хорошее" такой себе аргумент
Да, не значит, что хорошее. Просто это определённые менталитеты и ценности, которые вероятно присутствуют у разработчиков. Но вообще да, это звучит, как бабушкин аргумент.
Bitwarden он американский, а не немецкий
Огромное спасибо! Поправил в публикации.
KeeWeb на компе и Syncthing для локальной синхронизации между всеми устройствами
Если на ваш дом упадёт метеорит — всё ок.
Интересная точка зрения.
Могу сказать, что пришел для себя к интересной мысли. У меня есть некая комбинация цифр (несколько разновидностей) которые я никогда не забуду в принципе. И я дополняю ее спец и не только символами спереди и сзади. Которые тоже в свою очередь, для меня легко запомнить.
С такой техникой я только могу забыть какой конкретно пароль из нескольких для какого сайта \сервиса использовать. Но легко лечится перебором всех.
Возможно вы скажете, что узнав мою комбинацию(и) цифр далее можно подобрать брутом остальное? Возможно, но брут будет не быстрым, да и он сейчас не в почете. Пароль быстрее украдут готовый.
Про бумажки Пример 2 как доедет до номера отеля? Рядом с бумажкой в чехле телефона или рядом с бумажкой в чемодане?
А вы знакомы с методом терморектального криптоанализа узнавания паролей? Мне кажется все ваши способы легко вскрываются этим методом. Ну кроме юбико
В статье описан не способ противостоять терморектальному криптоанализу, а стойкий к потере устройств и паролей метод хранения шифрованных данных. Потерять телефон или ноут с мастер-паролем и не смочь после этого залогиниться в свою учетку с двухфакторкой - гораздо более реальный риск, чем стать жертвой криптоанализа в исполнении Джека Бауэра и других аналогичных товарищей.
Кажется, что если можно запомнить 2 пароля, то можно и придумать формулу для получения пароля, в которой эти 2 исходных будут солью - так вообще можно будет обойтись без менеджера/хранилища и налету его «собирать в голове»
Насчет схемы Шамира, понравилась утилитка https://github.com/jesseduffield/horcrux - действительно своего рода крестраж
пффф или как хороню пароли я: paroli.7z шифрованый aes-256
Как содержать пароли. Мой сетап