Комментарии 90
То есть для каждого сайта нужно помнить 3 параметра - количество блоков, зерно и мнемоническую фразу ? Не уверен что это лучше, чем использовать длинный пароль, соответствующий новым рекомендациям NIST
Как по мне, менеджеры паролей (использую KeePass) хороши тем что в них я могу хранить не только сами пароли, но и имена "откуда они" к ним. Через год я не помню, есть у меня регистрация в "магазин рога и копыта" и под каким ником. А еще ключи SSH, описания, вложения, никнеймы, TimeOTP
А вы уверены, что там нет закладок? Или что в очередном обновлении они не добавятся по "политическим мотивам"?
Если нужно хранить такой объем - можно самому написать криптоконтейнер по тому же принципу.
Если нужно хранить такой объем - можно самому написать криптоконтейнер по тому же принципу.
С таким подходом проще взять фиксированную кодовую базу и самостоятельно провести аудит. Времени уйдет не меньше написания велосипеда.
На описанный скрипт у меня ушло где-то полчаса времени на все. Про криптоконтейнер - надо подумать, возможно тоже сделаю. Это всяко будет меньше времени чем на аудит, ибо реализация будет такой же "палка-веревка".
консольной утилитой не очень удобно будет пользоваться
Почему? Консоль всегда под рукой.
Особенно на телефоне, да...
Менеджеры паролей подкупают удобством.
Пару лет назад я бы и не подумал что у меня будет куплен один из них.
Но они автоматически предлагают записать, автоматически предлагают вставить один из 10 логинов/паролей именно для этого сайта, автоматически предлагают обновить пароль при изменении, удобство на телефоне - вообще сказка.
Если всё-же есть страх за какие-то суперважные пароли, в заметки менеджера паролей можно внести параметры этой консольной утилиты, и останется помнить только соль для пароля, то есть сверхсуперсекретные пароли можно хранить в менеджере паролей, получается, просто иным способом.
Во вторых это Open source а значит ты как пользователь можешь, а для параноиков должен, провести свой независимый аудит кода. Код должен быть более или менее читаемым, для понимания того что он делает, а значит закладки с отправкой данных должны быть видны. Ну а стойкость алгоритмов шифрования порой даже эксперты оценить не берутся.
В третьих не стоит бездумно ставить любые обновления, без проверки того что в эти обновления включено. Особенно если уже проведён аудит всего кода, то дополнительно проверить внесённые изменения не составит большого туда. И в случае любых обнаруженных проблем, как минимум сообщить о них сообществу, как максимум сделать форк и контролировать изменения самому.
Штука в том, что аудит кода, это задача для неспециалиста, коим я являюсь, штука довольно сложная.
Самая простая проверка: фиксировать весь исходящий трафик за какой-то промежуток активного использования ПО.
В идеале он должен отсутствовать.
В KeePassXC запросы могут появиться только при вызове определенных функций пользователя (загрузка значков и частичной проверки хешей через haveibeenpwned.com).
база хранится локально, это файл сохранность которого ложится на плечи пользователя.
Сохранность файла, тем более зашифрованного и ещё неизвестного формата, это большая проблема.
Я придумывал свою систему хранения паролей именно из за этого. Сделал так, чтобы все пароли хранились в MFT. Учитывая то, что эта MFT дублируется дважды в разделе с NTFS и не фрагментируется. Плюс, у меня CRC для каждого пароля.
Меня уже всё это один раз крупно спасло. Я вытащил флешку без программного извлечения и у меня флешка стала нечитаемой. Восстанавливал через HEX-редактор, чтобы не затереть данные окончательно какой нибудь кривой прогой. Правда, MFT долго искал, я не знаю где хранится её адрес.
Запретите keepass доступ в интернет (он ему не нужен) и пользуйтесь спокойно даже с закладками.
А чем плох bitwarden на своём сервере? Это реально вопрос. Наткнулся на него буквально 3 дня назад, раздумываю. Может есть какой-то изначальный косяк, который перекрывает все плюхи?
У меня нет своего сервера.
Использую дома vaultwarden, сервер на rust для bitwarden, есть докер для него. Не нужна email регистрация в bitwarden.
Все ок. Проблем не испытываю.
Можно инструктаж как его поставить?
Тоже самое. До этого был Keepass с синхронизацией через webdav но keepass под linux и macos нет (в нормальном виде да еще и с синхронизацией), еще пробовал SafeInCloud но его тоже нет под linux. vaultwarden конечно не так крут как keepass но со своими фишками + возможность вебморды.
А вы уверены, что там нет закладок?А Вы уверенны, что закладок нет в браузере (или в другом софте, куда Вы собираетесь вводить пароль)? Если следовать Вашей логике, то самому надо писать не только менеджер паролей, а и весь софт, работающий с чувствительной информацией.
Можно взять Bitwarden, развернуть на своём сервере и ограничить ему доступ, чтоб исключить утечку данных.
Цель нигде ничего не хранить разбивается о потребность хранить мнемонические фразы с сидом.
Вы по сути добавили один дополнительный шаг - хэширование, но ведь точно также можно использовать и любой менеджер паролей. Только вместо того, чтобы копировать из него пароль напрямую в браузер, закидывать пароль в вашу программу и получать хэш.
А хранить их можно в голове. Смысл мнемоники - в легком запоминании.
Например, у меня сейчас в KeePass 301 запись. Некоторые создавались чуть ли не 10 лет назад. Как для такого количества запомнить все мнемоники?
Это да, проблема. У меня их штук 25 - их я могу запомнить.
А вот когда пароли генерятся по мнемонической фразе или каким-то другим параметрам, приходится эту фразу как-то запоминать. Уникальных фраз не напридумываешься, поэтому люди обычно вырабатывают некую универсальную схему и следуют ей. Например, можно везде использовать одну и ту же фразу, просто добавить в нее имя ресурса: «лошадьсоскрепкойдляхабра».
Устойчивость этой схемы довольно низкая. Стороннему наблюдателю достаточно один раз увидеть фразу и понять принцип ее составления — и все. У него есть доступ ко всем ресурсам, где использовалась эта фраза.
Вот поэтому я и использую сложные мнемонические схемы. И тренировка для мозга заодно. Бьют, обычно по самому слабому месту - по голове.
Схема хорошо работает для вас — т.к. вы используете сложные мнемонические схемы и вообще в курсе, какие у вашей схемы ограничения.
Но возьмем обычного ленивого пользователя. Без суровой дисциплины с его стороны то, что вы предлагаете, будет довольно хлипкой защитой. Еще и неудобной.
Такой пользователь будет и пароли везде одинаковые использовать. Тут, на Хабре, таких меньшинство.
Я этой схемой пользуюсь уже несколько лет. На Хабре решил выложить, чтобы мне более опытные люди указали в чем слабые места.
Такой пользователь будет и пароли везде одинаковые использовать.
Это если нет менеджеров паролей.
Если менеджер паролей таки есть (а их уже придумано множество), то все сразу меняется: пользователю ничто не мешает для каждого ресурса использовать свой уникальный пароль.
Кстати, накалякать свой менеджер паролей не так уж и сложно. Не за полчасика, конечно, но за пару дней — вполне. Зато будет свой, гарантированно без закладок.
В случае одного или двух, край пяти - такое сработает.
Но когда речь заходит за десятки и при том не часто используемые, то через год-два в голове останутся хорошо еси обрывки.
как Вы считаете, что более криптостойкое, пароль вида "этотпарольдлясайтаяндекс" или пароль, сгенеренный Вашей утилитой вида "8s(e[2&" ?
если речь идет не о хранении паролей, а об их генерации по ключевой фразе, то сильно проще придумать себе правило (правила) формирования паролей из "имени-собаки-фамилии-матери-задом-наперед-соли-из-доменного-имени"
пароли всегда разные, правило формирования может включать заглавные/строчные, прямой/обратный порядок букв и т.п.
8 лет назад делал нечто похожее на Java: указывается код алгоритма (тоже хеш-функции), максимальная длина пароля, зерно-число и какая-то строка, предполагал, что это будет что-то хитрое типа "username@example.com"
В итоге не пользовался, потому что если логины разные, то их надо как-то хранить... Копировать имя из одного места, "обрабатывать" для генератора пароля, копировать пароль - это, конечно, не сложно, но автозаполнение браузера намного быстрее и удобнее. С тех пор только заменил родное хранилище браузера на менеджер паролей.
Удобство и безопасность - это антонимы.
Но это не значит, что неудобство — это безопасность. :)
Неудобно вам сделать удалось. Но насколько ваша схема безопасна?
Допустим, мы знаем, что Вася использует ваш скрипт, и знаем его мнемоническую фразу для некого сайта. Задача: подобрать пароль к сайту Х.
Что-то мне подсказывает, что количество вариантов для перебора будет сильно меньше, чем при тупом брутфорсе.
Ну если вызнаете фразу, то можно также знать и пароль. В чем разница?
Поясню: у пароля и у мнемонической фразы разные цели. Цель пароля — чтоб не подобрали (т.е. он максимально рандомный и, соответственно, труднозапоминаемый). Цель мнемонической фразы — чтоб ее полегче запомнить. И вот тут люди склонны запоминать не набор разных фраз (своя для каждого ресурса), а придумывают некую схему генерации таких фраз. Что и понятно: если бы человек легко запоминал рандомные уникальные фразы, то почему бы ему сразу пароли не запоминать?
Так слаб человек, не спорю. Но лично у меня нет такой проблемы. Тут цепочку мнемоники, которая есть у меня в голове, не будучи мной подобрать нереально.
лошадь со скрепкой — лошсоскр — kjicjcrh
Это короткий пароль. На 64 символа вы так не сделаете.
Собственно, это одна из рекомендаций по созданию сильных паролей. Например, Avast такое рекомендует (раздел «The revised passphrase method»).
Это, конечно, так, но при почти такой же (недоказанной криптоаналитиками) безопасности можно получить на порядок больше удобства, если, например, шифровать файл с паролями с помощью стандартного AES-256 (на Python, с помощью OpenSSL, или вовсе создавать запароленный 7Zip-архив) - тогда достаточно запомнить всего одну мнемонику и безопасно хранить любые тексты в любом виде, а не только абстрактные пароли. KeePass примерно так и работает, кстати. Да, появится проблема синхронизации файла, но пока он зашифрован - его хоть на PasteBin можно выкладывать.
А если вы боитесь, что ваш файл кто-то расшифрует... Уж поверьте, если кто-то научится расшифровывать AES-256 на практике - у всего мира будет гораздо больше проблем, чем лично у вас
Не всегда.
pass + browserpass
Если есть цель "ничего не хранить", но есть желание помнить какой-то мнемонический ключ для каждого сайта и совершать некие оккультные манипуляции каждый раз, когда хочется залогиниться в магазин, то можно пользоваться "парольными картами".
Ее можно потерять, нужно руками водить пароль т.д.
Можно несколько копий сделать и хранить в разных местах. Ручной ввод тоже можно обойти, создав копию этой карты в виде текстового файла. Правда тут встаёт вопрос безопасности хранения пароля в оперативной памяти, хотя я мало беспокоюсь о таких вещах. В этом вопросе я прибегаю к дуализму МОССАД/неМОССАД и если уж кто-то читает мои пароли из RAM, то пора сушить сухари.
https://www.opennet.ru/man.shtml?topic=otp-md5&category=1&russian=1 – примерно то же, что вы сделали, но стандартное и на линуксах вроде вообще есть из коробки. Бонус – может выдавать пароль в виде пяти слов, лично мне запомнить на минуту и вбить проще, чем кучу мусора. Я когда-то пользовался для нескольких ресурсов, поставив подсказки пароля вида "example.com 100 пароль".
Но вообще менеджеры с хранением (с шифрованием на стороне клиента, чтобы совсем уж дурную утечку исключить) поудобнее. Хотя бы из-за того, что на некоторых сайтах свои требования к паролям ("Ваш пароль должен содержать цифры, буквы, завязку, развитие, кульминацию и неожиданный финал"), да и при необходимости менять пароль конкретного сайта проще (ну и менять мастер-пароль в принципе возможно – хотя при утечке это так себе утешение).
Про утечку и речь. У меня и утекать-то нечему. А если дело дойдет до паяльника, то тут уже ничто не поможет.
В смысле – нечему? Утёк мастер-пароль (троян на вашей машине, к примеру) – утекли все пароли, алгоритм-то известен.
В случае "классического" пм с шифрованием на клиенте – должен утечь не только мастер-пароль (опять же только с вашей машины), но и база с зашифрованными паролями (либо тоже с вашей машины, либо из места хранения). Ближайший аналог: представьте себе вашу систему, но seed и что там ещё хранится не локально, а где-то.
У варианта без хранилища другой плюс: вы не потеряете свои пароли, если не будет доступа к хранилищу.
Сделал скрипт на питоне, который генерирует пароль по псевдослучайному алгоритму. на вход подаётся: user name, service name, pin code. На выходе - пароль. Пин код хранится только у меня в голове)
Скрипт завернул в брайтон в виде простейшей веб странички, и положил в телефон. Генератор паролей всегда с собой) Ну или на гитхабе, от него пароль пришлось выучить наизусть)
Ну тут или использовать один логин для всего, что не секьюрно, либо запоминать, как минимум, десятки логинов, что тоже, в условиях сотен сервисов, не очень реально.
Ну у меня примерно то же самое.
Есть готовое похожее расширение для браузера (для хрома и edge тоже есть): https://addons.mozilla.org/ru/firefox/addon/masterpassword-firefox/
Да, я уверен, что я не один такой умный и до меня это придумали. Но у меня была цель сделать самому.
немного потерялся - не понял почему тогда просто не использовать пароль который генерирует тот же firefox из коробки? зачем какое-то непроверенное расширение?
хотя слышал, что к менеджеру паролей firefox были вопросы, но вроде проблемы пофиксили. Недавно завезли синхронизацию и автозаполнение в android
С тем же успехом в качестве пароля можно использовать мнемоническую фразу+число. Потому что взятие от нее хеша повышает стойкость только пока этим методом никто не пользуется. Если мы представим что этот метод вдруг стал известным и популярным - просто для подбора паролей начнут использовать не только словарь распостраненных фраз, но и хеши от элементов этого словаря и тогда стойкость будет обеспечиваться только стойкостью исходной фразы(+числа).
Ну хорошо, один плюс у взятия хеша есть - если мнемоники имеют вид "<имя сайта> лошадьсоскрепкой" и список паролей одного из сайтов утечет, то если паролем было "<имя сайта> лошадьсоскрепкой" - придется беспокоится о том что кто угодно может увидеть этот пароль и понять каков пароль к остальным сайтам. А если брать хеш такой проблемы не будет. Но нормальный менеджер паролей (для параноиков - написать свой \ собрать из исходников предварительно проверив код) все равно надежнее.
Мне всегда казалось, что менеджер нужен именно для хранения паролей, а не для запоминания их пользователем. Некоторые системы вообще требуют смену пароля через пару месяцев. У меня уже голова пухнет от запоминания паролей, так как придуманный универсальный приходится сменить, где-то вбил не в том регистре... сменить, политика безопасности не разрешает использовать существующий ранее, и тд...
Облачное хранение! Пароли, которые вы никогда не забудете и не потеряете!
Вам надо только помнить один свой пароль! Говорили они.
Реальность: 1password перестаёт принимать оплату и создавать новые аккаунты в России (а могли бы и заблокировать если могли бы).
Но это лирика.
Если серьёзно - то вы изобретаете HMAC. Всё уже придумано, до нас :)
Логичное продолжение солёных хешей. В качестве части соли ведь можно использовать название сайта, в который собираетесь входить.
То есть соль будет включать: 1.фиксированную парольную фразу, привязанную к сервису "генерации" паролей, 2. парольную фразу, которую будете вводить для разблокировки/активации вашей системы генерации паролей, 3. название сайта, где пароль потребуется.
HMAC ещё включает двойное хеширование и "расширение" коротких ключей заполняющими байтами... H((PASS1 XOR PAD1) APPEND H((PASS2 XOR PAD2) APPEND DATA))
PAD1 и PAD2 кроме наложения на пароли ещё и "расширяют" их длину. Если приглядеться к формуле, это фактически солёные хеши: Хеш(Соль+данные).
HMAC применяют для относительно быстрого "подписания" данных. Для паролей - просто повторяют хеширование много-много раз, чтобы практически полностью исключить брутфорс. Так, например, работает парольная защита в криптоконтейнерах PFX/P12. Количество повторов - десятки-сотни тысяч раз. Вас же не будет напрягать, если ваш i7 ноутбук после ввода пароля выдаст результат не сразу, а через 2-3 секунды? А для брутфорсера это будет принципиально.
H(соль+H(соль+H(соль+.....H(соль+данные))).. Количество таких циклов легко посчитать экспериментально - просто запустите на "рабочей" машине расчёт таких вложенных хешей - и остановите, когда время ожидания вас удовлетворит.
Только не надо забывать, что может быть и такой вариант, когда вместо i7 ноутбука через несколько лет у вас будет слабенький arm из проекта "OLPC: 100$ PC for Africa Child". И там расчёт такого количества хешей займёт уже... пару минут...
Идея не хранить пароли мне понравилась - но ожидал другую реализацию. Данная реализация мне совсем не понравилась. Подумаю на досуге над своей
А вот есть такое простое расширение для Gnome: https://extensions.gnome.org/extension/825/password-calculator/ Делает, похоже, именно это?
У менеджеров паролей есть преимущество, которое нужно в быту чаще, чем гипотетическая угроза угона keepass - они не будут подставлять пароли если домен не совпадает, что заставит вас задуматься почему на paypaI.com не подставился пароль, посмотреть сертификат и обнаружить заглавную i на конце.
Ну а ещё если ваша схема будет скомпрометирована раз, то все, приехали.
Лично у меня пароли бьются на две группы - пару сервисов с уникальным длинным паролем который я запомнил и переодически тренируют и хранилка паролей для остального, но в остальном старательно избегаю привязки карты и всего такого, что может оказаться важным.
Правда с отказоустойчивой цепочкой восстановления доступа в случае чего да, пришлось повозиться, но это больше про бэкапы и доступ к ним удаленно.
Тут уже достаточно накидали доводов, почему менеджер паролей выигрывает у предложенной схемы. Добавлю ещё одну. Менеджер паролей - это ещё и элемент Вашего цифрового завещания. Если мне завтра упадёт на голову кирпич - то моя супруга знает, где найти мастер-пароль и, соответственно, получить доступ ко всем остальным 843 паролям, которые у меня в self-hosted Bitwarden'е лежат. Конечно, не все из них ей понадобятся, но довольно многие. А многие понадобятся другим людям, которым придётся дальше тянуть на себе ту IT-инфраструктуру, которую я администрировал.
Очередной полностью ненужный неработоспособный неудобный велосипед, который пытается заменить безопасность видимостью безопасности.
Есть совершенно открытый, бесплатный, локальный, кроссплатформенный KeePassXC, консольную версию которого параноики могут запускать в совершенно изолированном контексте (да и не консольную тоже, тут уж кому как больше нравится усложнять себе жизнь). Его тащат в десятки дистрибутивов и проверяет антивирями, файрволами, всякими virustotal овердофига людей. Он решает проблемы паролей на раз и без всяких извращений. KeePass уже сам по себе стандарт в мире защиты, поэтому его же использует, например, JetBrains для хранения кредов в своих продуктах. До кучи KeePassXC умеет в TOTP, всякие хардверные штуки, прятать в себя SSH-ключи (в т.ч. есть интеграция с ssh-agent). Есть плагины для пользования в компании (KeeShare, в т.ч. для NextCloud). Есть интеграция в браузер. Синхронизировать можно любым удобным инструментом. Если вы не доверяете облаку - можно файл-ключ не ложить в облако и тогда даже если пароль как-то умыкнут (например встроенный в форточку OneDrive и синк буфера обмена уедут тварищу майору с подачи MS) - всё равно не расшифруют ничего.
И для пущей переносимости KeePassDroid на телефоне.
Запомнил один нормальный пароль, сгенерил файл-ключ и ВСЁ. Не нужно дурить вот этими костылями себе голову и обманывать себя и окружающих. Куда более прошаренные в защите ребята уже не раз нагрелись на такой "безопасности".
Для остальных есть аппаратные менеджеры паролей.
И вопрос даже не чем такие алгоритмы лучше, чем традиционные менеджеры, а где это уместнее. Может быть там, где базы в виде файлов хранить негде.
Первое, существует некоторая зависимость каждой парольной фразы друг от друга. Второе - известный алгоритм (для совместимости это обязательно). И, конечно же, количество вариаций мастер пароля ограничено. Мы можем предсказать будущие пароли, вынудив пользователя алгоритма сменить мастер. И заодно все пароли, генерируемые от него.
То есть нужно веское обоснование применения таких алгоритмов, потому что недостатков много. А вообще идея мне нравится. Алгоритм подходит для отсева предсказуемых паролей.
Мне понравилась идея: нельзя украсть то, чего нет. Этот подход надо использовать для действительно важных паролей, тогда не будет проблем с необходимостью запоминания +100500 фраз. Поставил бы лайк, но недостаточно кармы. Спасибо за идею и реализацию.
Алгоритм Billemont, вот про который было написано, решает ещё проблему фишинга. Хотя, если сайт переезжает, начинаются проблемы.
Менеджер паролей без хранения