Всем привет!
Хочу поделиться с народом своей идеей по поводу безопасного хранения паролей. Сторонние менеджеры паролей мне всегда не нравились. Хранение сокровенного у чужого дяди – идея ну очень так себе. Можно сколько угодно клясться, что все надежно, что утечки маловероятны и т.д. Но одна утечка – и все что нажито непосильным трудом погибнет.
Поэтому, я, руководствуясь принципом «хочешь, чтобы было сделано хорошо – сделай сам», решил создать свое решение этой проблемы.
Задачи стояли следующие:
Я программист не настоящий, так что алгоритм должен быть простым в реализации.
Он должен быть кроссплатформенным: Android/Linux/Windows.
Пароли в принципе не должны храниться нигде и ни в каком виде – это и есть изюминка моей идеи.
Если кто-то получит доступ к исходным кодам – это ничего ему дать не должно. Собственно, поэтому я и решил поделиться с народом своей идеей.
Идея заключалась в следующем. Хэш чего угодно представляет собой последовательность шестнадцатеричных цифр. Эту последовательность можно разбить на блоки по две, переводим в десятичный вид, получаем остаток по модулю длины алфавита и получаем номера символов в алфавите. Для сайта нужно помнить лишь мнемонический идентификатор из хэшируемой фразы и числа для формирования алфавита.
Алгоритм заворачивается в скрипт на питоне. Интерпретаторов под Android/Linux/Windows – вагон и маленькая тележка. Далее привожу код с пояснениями.
Импортируем нужные библиотеки:
import hashlib
from textwrap import wrap
import randomПодключаем список алгоритмов хэширования. Длина хэша у них разная, сделано это для сайтов с ограничением сверху по длине пароля.
algs = ['md5', 'sha1', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512']Алфавит разбиваем на три куска. Отдельно цифробуквенный, отдельно знаки препинания, и отдельно пробел, решетка звездочка и обратный слэш. Третий блок почему-то кое-где запрещен в паролях, например на госуслугах.
abc_blocks = ['0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz', '!"$%&\'()+,-./:;<=>?@[]^_{|}~`', ' #*\\']
abc = ''Принимаем на входе количество блоков. По умолчанию берем все три блока.
И задаем зерно для рандома. Это вышеупомянутое число из мнемонического идентификатора.
abc_colvo = int(input("Количество блоков (3): ") or 3)
s = int(input("Зерно для рандома: "))Склеиваем блоки алфавита и перемешиваем его.
for i in range(abc_colvo):
abc += abc_blocks[i]
abc = list(abc)
random.seed(s)
random.shuffle(abc)
abc = ''.join(abc)Далее вводим фразу.
memory_phrase = input('Ключевая фраза: ')
memory_phrase = bytes(memory_phrase, encoding = 'utf-8')Запускается вычисление паролей.
print()
print('-----------------------------')
for alg in algs:
hash_key = getattr(hashlib, alg)(memory_phrase).hexdigest()
password = [hash_key[x:x+2] for x in range(0, len(hash_key), 2)]
password = list(map(lambda x: int(x, 16) % len(abc), password))
password = list(abc[x] for x in password)
password = ''.join(password)
print(alg + ':', len(password), 'chars')
print()
print(password)
print()
for block in wrap(''.join(password), 4):
print(block + ' ', end = '')
print()
print('-----------------------------')И вуаля – вот ваши возможные пароли для сайта.
Разбивка по 4 символа нужна на тот редкий случай, если придется вводить все это с клавиатуры. Так визуально проще его читать.
Комментарии (88)
vvovas
05.04.2022 08:30+3Цель нигде ничего не хранить разбивается о потребность хранить мнемонические фразы с сидом.
Вы по сути добавили один дополнительный шаг - хэширование, но ведь точно также можно использовать и любой менеджер паролей. Только вместо того, чтобы копировать из него пароль напрямую в браузер, закидывать пароль в вашу программу и получать хэш.
kraamis Автор
05.04.2022 08:36А хранить их можно в голове. Смысл мнемоники - в легком запоминании.
mavir
05.04.2022 09:13+2Например, у меня сейчас в KeePass 301 запись. Некоторые создавались чуть ли не 10 лет назад. Как для такого количества запомнить все мнемоники?
kraamis Автор
05.04.2022 09:35Это да, проблема. У меня их штук 25 - их я могу запомнить.
berez
05.04.2022 09:58+2Одна из радостей хранилки паролей — в том, что новые пароли добавляются легко и их не надо держать в голове. В результате можно для каждого ресурса использовать уникальный рандомный пароль.
А вот когда пароли генерятся по мнемонической фразе или каким-то другим параметрам, приходится эту фразу как-то запоминать. Уникальных фраз не напридумываешься, поэтому люди обычно вырабатывают некую универсальную схему и следуют ей. Например, можно везде использовать одну и ту же фразу, просто добавить в нее имя ресурса: «лошадьсоскрепкойдляхабра».
Устойчивость этой схемы довольно низкая. Стороннему наблюдателю достаточно один раз увидеть фразу и понять принцип ее составления — и все. У него есть доступ ко всем ресурсам, где использовалась эта фраза.kraamis Автор
05.04.2022 10:02Вот поэтому я и использую сложные мнемонические схемы. И тренировка для мозга заодно. Бьют, обычно по самому слабому месту - по голове.
berez
05.04.2022 10:26Вот именно.
Схема хорошо работает для вас — т.к. вы используете сложные мнемонические схемы и вообще в курсе, какие у вашей схемы ограничения.
Но возьмем обычного ленивого пользователя. Без суровой дисциплины с его стороны то, что вы предлагаете, будет довольно хлипкой защитой. Еще и неудобной.kraamis Автор
05.04.2022 10:31Такой пользователь будет и пароли везде одинаковые использовать. Тут, на Хабре, таких меньшинство.
Я этой схемой пользуюсь уже несколько лет. На Хабре решил выложить, чтобы мне более опытные люди указали в чем слабые места.
berez
05.04.2022 10:47+1Такой пользователь будет и пароли везде одинаковые использовать.
Это если нет менеджеров паролей.
Если менеджер паролей таки есть (а их уже придумано множество), то все сразу меняется: пользователю ничто не мешает для каждого ресурса использовать свой уникальный пароль.
Кстати, накалякать свой менеджер паролей не так уж и сложно. Не за полчасика, конечно, но за пару дней — вполне. Зато будет свой, гарантированно без закладок.
polearnik
05.04.2022 11:18+2но с кучей уязвимостей который вскроет даже обезьяна. криптография не та область в которой нужны велосипеды
ClearAirTurbulence
06.04.2022 11:20Мозг - странная ненадёжная штука, и доверять ему хранение важной информации - так себе идея. В нужный момент можно банально не вспомнить всю или часть необходимой информации, и для этого даже не нужны какие-то очевидные проблемы.
Когда мне было лет 15, в один прекрасный день я не смог вспомнить, как будет "вишня" по-английски. И не мог вспомнить это где-то пару часов. Потом коррекция ошибок сработала, и слово вспомнилось.
После такой наглядной демонстрации потенциальных глюков мозга хранить в нем пароли или схемы их получения мне как-то не хочется.
man55
05.04.2022 12:41как Вы считаете, что более криптостойкое, пароль вида "этотпарольдлясайтаяндекс" или пароль, сгенеренный Вашей утилитой вида "8s(e[2&" ?
если речь идет не о хранении паролей, а об их генерации по ключевой фразе, то сильно проще придумать себе правило (правила) формирования паролей из "имени-собаки-фамилии-матери-задом-наперед-соли-из-доменного-имени"
пароли всегда разные, правило формирования может включать заглавные/строчные, прямой/обратный порядок букв и т.п.
DirectoriX
05.04.2022 08:368 лет назад делал нечто похожее на Java: указывается код алгоритма (тоже хеш-функции), максимальная длина пароля, зерно-число и какая-то строка, предполагал, что это будет что-то хитрое типа "username@example.com"
В итоге не пользовался, потому что если логины разные, то их надо как-то хранить... Копировать имя из одного места, "обрабатывать" для генератора пароля, копировать пароль - это, конечно, не сложно, но автозаполнение браузера намного быстрее и удобнее. С тех пор только заменил родное хранилище браузера на менеджер паролей.
kraamis Автор
05.04.2022 09:02+1Удобство и безопасность - это антонимы.
berez
05.04.2022 09:39+4Все так.
Но это не значит, что неудобство — это безопасность. :)
Неудобно вам сделать удалось. Но насколько ваша схема безопасна?
Допустим, мы знаем, что Вася использует ваш скрипт, и знаем его мнемоническую фразу для некого сайта. Задача: подобрать пароль к сайту Х.
Что-то мне подсказывает, что количество вариантов для перебора будет сильно меньше, чем при тупом брутфорсе.kraamis Автор
05.04.2022 09:43Ну если вызнаете фразу, то можно также знать и пароль. В чем разница?
berez
05.04.2022 10:12Разница в том, что знание Васиного пароля для сайта А не дает нам информации о пароле для сайта Б (ну, если Вася не совсем обалдуй, конечно). А вот знание мнемонической фразы может дать ключ вообще ко всей схеме создания паролей.
Поясню: у пароля и у мнемонической фразы разные цели. Цель пароля — чтоб не подобрали (т.е. он максимально рандомный и, соответственно, труднозапоминаемый). Цель мнемонической фразы — чтоб ее полегче запомнить. И вот тут люди склонны запоминать не набор разных фраз (своя для каждого ресурса), а придумывают некую схему генерации таких фраз. Что и понятно: если бы человек легко запоминал рандомные уникальные фразы, то почему бы ему сразу пароли не запоминать?kraamis Автор
05.04.2022 10:20Так слаб человек, не спорю. Но лично у меня нет такой проблемы. Тут цепочку мнемоники, которая есть у меня в голове, не будучи мной подобрать нереально.
berez
05.04.2022 10:30+1Ну так а смысл тогда городить огород с хэшированием? Генерируем мнемоническую фразу для ресурса, берем первые две-три буквы от каждого слова и вбиваем их в качестве пароля:
лошадь со скрепкой — лошсоскр — kjicjcrhkraamis Автор
05.04.2022 10:32Это короткий пароль. На 64 символа вы так не сделаете.
berez
05.04.2022 10:57На 64 символа можно всю мнемоническую фразу написать.
Собственно, это одна из рекомендаций по созданию сильных паролей. Например, Avast такое рекомендует (раздел «The revised passphrase method»).
DirectoriX
05.04.2022 09:56Это, конечно, так, но при почти такой же (недоказанной криптоаналитиками) безопасности можно получить на порядок больше удобства, если, например, шифровать файл с паролями с помощью стандартного AES-256 (на Python, с помощью OpenSSL, или вовсе создавать запароленный 7Zip-архив) - тогда достаточно запомнить всего одну мнемонику и безопасно хранить любые тексты в любом виде, а не только абстрактные пароли. KeePass примерно так и работает, кстати. Да, появится проблема синхронизации файла, но пока он зашифрован - его хоть на PasteBin можно выкладывать.
А если вы боитесь, что ваш файл кто-то расшифрует... Уж поверьте, если кто-то научится расшифровывать AES-256 на практике - у всего мира будет гораздо больше проблем, чем лично у вас
Admaer
05.04.2022 08:58+1Если есть цель "ничего не хранить", но есть желание помнить какой-то мнемонический ключ для каждого сайта и совершать некие оккультные манипуляции каждый раз, когда хочется залогиниться в магазин, то можно пользоваться "парольными картами".
kraamis Автор
05.04.2022 09:03Ее можно потерять, нужно руками водить пароль т.д.
Admaer
05.04.2022 09:14Можно несколько копий сделать и хранить в разных местах. Ручной ввод тоже можно обойти, создав копию этой карты в виде текстового файла. Правда тут встаёт вопрос безопасности хранения пароля в оперативной памяти, хотя я мало беспокоюсь о таких вещах. В этом вопросе я прибегаю к дуализму МОССАД/неМОССАД и если уж кто-то читает мои пароли из RAM, то пора сушить сухари.
kraamis Автор
05.04.2022 09:37И копировать по одному символу? Тут ошибиться как нефиг делать. Я одно время этим развлекался, но потом понял что это число в шпионов поиграть.
aamonster
05.04.2022 09:15+1https://www.opennet.ru/man.shtml?topic=otp-md5&category=1&russian=1 – примерно то же, что вы сделали, но стандартное и на линуксах вроде вообще есть из коробки. Бонус – может выдавать пароль в виде пяти слов, лично мне запомнить на минуту и вбить проще, чем кучу мусора. Я когда-то пользовался для нескольких ресурсов, поставив подсказки пароля вида "example.com 100 пароль".
Но вообще менеджеры с хранением (с шифрованием на стороне клиента, чтобы совсем уж дурную утечку исключить) поудобнее. Хотя бы из-за того, что на некоторых сайтах свои требования к паролям ("Ваш пароль должен содержать цифры, буквы, завязку, развитие, кульминацию и неожиданный финал"), да и при необходимости менять пароль конкретного сайта проще (ну и менять мастер-пароль в принципе возможно – хотя при утечке это так себе утешение).kraamis Автор
05.04.2022 09:39-1Про утечку и речь. У меня и утекать-то нечему. А если дело дойдет до паяльника, то тут уже ничто не поможет.
aamonster
05.04.2022 10:01В смысле – нечему? Утёк мастер-пароль (троян на вашей машине, к примеру) – утекли все пароли, алгоритм-то известен.
В случае "классического" пм с шифрованием на клиенте – должен утечь не только мастер-пароль (опять же только с вашей машины), но и база с зашифрованными паролями (либо тоже с вашей машины, либо из места хранения). Ближайший аналог: представьте себе вашу систему, но seed и что там ещё хранится не локально, а где-то.
У варианта без хранилища другой плюс: вы не потеряете свои пароли, если не будет доступа к хранилищу.
kraamis Автор
05.04.2022 10:08-1Ну в принципе да. Но если на машине троян то и локальную базу слить можно. Но у себя я больше хозяин.
polearnik
05.04.2022 11:25думаете троян будет заточен именно под базу парольного менеджера и кто-то будет копатся в набранном тексте чтоб отыскать пароль? вы настолько круты и инетресны что у вас буедт таргетированная атака? боюсь тут ваш метод хранения паролей найменьшая ваша проблема
Vaitek
05.04.2022 09:34Сделал скрипт на питоне, который генерирует пароль по псевдослучайному алгоритму. на вход подаётся: user name, service name, pin code. На выходе - пароль. Пин код хранится только у меня в голове)
Скрипт завернул в брайтон в виде простейшей веб странички, и положил в телефон. Генератор паролей всегда с собой) Ну или на гитхабе, от него пароль пришлось выучить наизусть)
ash_lm
05.04.2022 09:40Ну тут или использовать один логин для всего, что не секьюрно, либо запоминать, как минимум, десятки логинов, что тоже, в условиях сотен сервисов, не очень реально.
Vaitek
05.04.2022 09:54Да, тут есть проблема, пока что реестр логинов хранится в голове. Но сервисы часто сами предсказывают. Логин в большинстве случаев это электронная почта, у меня выбор не велик)
xmcuz
05.04.2022 10:05Есть готовое похожее расширение для браузера (для хрома и edge тоже есть): https://addons.mozilla.org/ru/firefox/addon/masterpassword-firefox/
kraamis Автор
05.04.2022 10:21Да, я уверен, что я не один такой умный и до меня это придумали. Но у меня была цель сделать самому.
krylov_sn
05.04.2022 11:20немного потерялся - не понял почему тогда просто не использовать пароль который генерирует тот же firefox из коробки? зачем какое-то непроверенное расширение?
хотя слышал, что к менеджеру паролей firefox были вопросы, но вроде проблемы пофиксили. Недавно завезли синхронизацию и автозаполнение в android
kipar
05.04.2022 09:52С тем же успехом в качестве пароля можно использовать мнемоническую фразу+число. Потому что взятие от нее хеша повышает стойкость только пока этим методом никто не пользуется. Если мы представим что этот метод вдруг стал известным и популярным - просто для подбора паролей начнут использовать не только словарь распостраненных фраз, но и хеши от элементов этого словаря и тогда стойкость будет обеспечиваться только стойкостью исходной фразы(+числа).
Ну хорошо, один плюс у взятия хеша есть - если мнемоники имеют вид "<имя сайта> лошадьсоскрепкой" и список паролей одного из сайтов утечет, то если паролем было "<имя сайта> лошадьсоскрепкой" - придется беспокоится о том что кто угодно может увидеть этот пароль и понять каков пароль к остальным сайтам. А если брать хеш такой проблемы не будет. Но нормальный менеджер паролей (для параноиков - написать свой \ собрать из исходников предварительно проверив код) все равно надежнее.
akalend
05.04.2022 09:59Мне всегда казалось, что менеджер нужен именно для хранения паролей, а не для запоминания их пользователем. Некоторые системы вообще требуют смену пароля через пару месяцев. У меня уже голова пухнет от запоминания паролей, так как придуманный универсальный приходится сменить, где-то вбил не в том регистре... сменить, политика безопасности не разрешает использовать существующий ранее, и тд...
vGimly
05.04.2022 10:31+2Облачное хранение! Пароли, которые вы никогда не забудете и не потеряете!
Вам надо только помнить один свой пароль! Говорили они.Реальность: 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". И там расчёт такого количества хешей займёт уже... пару минут...
kraamis Автор
05.04.2022 10:34Понятно, что люди поумнее меня до таких вещей уже додумались. Но я-то дилетант-любитель.
vGimly
05.04.2022 11:00Вместо фиксированной соли для каждой итерации можно использовать генератор псевдослучайных чисел, который инициализируется солью. Например довольно легко реализующиеся AES + CBC/CFB/OFB :) Причём соль можно запихать и в IV, и в KEY и в DATA...
LordDarklight
05.04.2022 10:56Идея не хранить пароли мне понравилась - но ожидал другую реализацию. Данная реализация мне совсем не понравилась. Подумаю на досуге над своей
kraamis Автор
05.04.2022 11:11Если здесь выложите - с удовольствием почитаю.
LordDarklight
05.04.2022 12:00Правильные идеи выше vGimly уже изложил (ну и выше в коментах тоже обсуждали)
hiddenman
05.04.2022 12:47А вот есть такое простое расширение для Gnome: https://extensions.gnome.org/extension/825/password-calculator/ Делает, похоже, именно это?
kahi4
05.04.2022 13:11У менеджеров паролей есть преимущество, которое нужно в быту чаще, чем гипотетическая угроза угона keepass - они не будут подставлять пароли если домен не совпадает, что заставит вас задуматься почему на paypaI.com не подставился пароль, посмотреть сертификат и обнаружить заглавную i на конце.
Ну а ещё если ваша схема будет скомпрометирована раз, то все, приехали.
Лично у меня пароли бьются на две группы - пару сервисов с уникальным длинным паролем который я запомнил и переодически тренируют и хранилка паролей для остального, но в остальном старательно избегаю привязки карты и всего такого, что может оказаться важным.
Правда с отказоустойчивой цепочкой восстановления доступа в случае чего да, пришлось повозиться, но это больше про бэкапы и доступ к ним удаленно.
aborouhin
05.04.2022 15:35+1Тут уже достаточно накидали доводов, почему менеджер паролей выигрывает у предложенной схемы. Добавлю ещё одну. Менеджер паролей - это ещё и элемент Вашего цифрового завещания. Если мне завтра упадёт на голову кирпич - то моя супруга знает, где найти мастер-пароль и, соответственно, получить доступ ко всем остальным 843 паролям, которые у меня в self-hosted Bitwarden'е лежат. Конечно, не все из них ей понадобятся, но довольно многие. А многие понадобятся другим людям, которым придётся дальше тянуть на себе ту IT-инфраструктуру, которую я администрировал.
QuAzI
05.04.2022 15:56+1Очередной полностью ненужный неработоспособный неудобный велосипед, который пытается заменить безопасность видимостью безопасности.
Есть совершенно открытый, бесплатный, локальный, кроссплатформенный KeePassXC, консольную версию которого параноики могут запускать в совершенно изолированном контексте (да и не консольную тоже, тут уж кому как больше нравится усложнять себе жизнь). Его тащат в десятки дистрибутивов и проверяет антивирями, файрволами, всякими virustotal овердофига людей. Он решает проблемы паролей на раз и без всяких извращений. KeePass уже сам по себе стандарт в мире защиты, поэтому его же использует, например, JetBrains для хранения кредов в своих продуктах. До кучи KeePassXC умеет в TOTP, всякие хардверные штуки, прятать в себя SSH-ключи (в т.ч. есть интеграция с ssh-agent). Есть плагины для пользования в компании (KeeShare, в т.ч. для NextCloud). Есть интеграция в браузер. Синхронизировать можно любым удобным инструментом. Если вы не доверяете облаку - можно файл-ключ не ложить в облако и тогда даже если пароль как-то умыкнут (например встроенный в форточку OneDrive и синк буфера обмена уедут тварищу майору с подачи MS) - всё равно не расшифруют ничего.
И для пущей переносимости KeePassDroid на телефоне.
Запомнил один нормальный пароль, сгенерил файл-ключ и ВСЁ. Не нужно дурить вот этими костылями себе голову и обманывать себя и окружающих. Куда более прошаренные в защите ребята уже не раз нагрелись на такой "безопасности".
Для остальных есть аппаратные менеджеры паролей.
SquareRootOfZero
05.04.2022 16:48Не уверен, что правильно понял идею автора, потому что он как-то слишком внезапно перешёл от её объяснения к рассказу о том, какие библиотеки надо импортировать на Питоне. Но, вроде, тут уже несколько лет назад был пост с описанием подобной схемы: вместо хранения паролей каждый раз генерировать пароль из адреса ресурса, юзернейма и мастер-пароля. Понятно преимущество подобной схемы: не надо таскать с собой парольную базу, обновлять её и синхронизировать — даже если внезапно придётся сбежать в Африку в одних трусах и без гаджетов, всё равно любой из своих паролей заново сгенерируешь (а один мастер-пароль уж как-нибудь запомнишь, тем более его и для обычных парольных менеджеров надо помнить по-любому). С другой стороны, понятны и недостатки: надо либо использовать заодно везде один и тот же логин, либо помнить все логины, либо таки где-то хранить и таскать с собой хотя бы эту базу логинов — тем более, если у тебя по несколько аккаунтов на ресурсе. А менять такие пароли как? Только сменой мастер-пароля и сменой всех паролей сразу везде? А если ресурс сперва назывался habrahabr.com, потом habr.com, а то еще geektimes.com, или как там его? А если для доступа к ресурсу надо задать что-то ещё кроме пары «логин/пароль»?
xotta6bl4
07.04.2022 11:09Все уже придумано: https://en.wikipedia.org/wiki/Master_Password_(algorithm)
https://gitlab.com/spectre.app
NTDLL
07.04.2022 13:43И вопрос даже не чем такие алгоритмы лучше, чем традиционные менеджеры, а где это уместнее. Может быть там, где базы в виде файлов хранить негде.
Первое, существует некоторая зависимость каждой парольной фразы друг от друга. Второе - известный алгоритм (для совместимости это обязательно). И, конечно же, количество вариаций мастер пароля ограничено. Мы можем предсказать будущие пароли, вынудив пользователя алгоритма сменить мастер. И заодно все пароли, генерируемые от него.
То есть нужно веское обоснование применения таких алгоритмов, потому что недостатков много. А вообще идея мне нравится. Алгоритм подходит для отсева предсказуемых паролей.
FilimoniC
То есть для каждого сайта нужно помнить 3 параметра - количество блоков, зерно и мнемоническую фразу ? Не уверен что это лучше, чем использовать длинный пароль, соответствующий новым рекомендациям NIST
Как по мне, менеджеры паролей (использую KeePass) хороши тем что в них я могу хранить не только сами пароли, но и имена "откуда они" к ним. Через год я не помню, есть у меня регистрация в "магазин рога и копыта" и под каким ником. А еще ключи SSH, описания, вложения, никнеймы, TimeOTP
kraamis Автор
А вы уверены, что там нет закладок? Или что в очередном обновлении они не добавятся по "политическим мотивам"?
Если нужно хранить такой объем - можно самому написать криптоконтейнер по тому же принципу.
xmcuz
С таким подходом проще взять фиксированную кодовую базу и самостоятельно провести аудит. Времени уйдет не меньше написания велосипеда.
kraamis Автор
На описанный скрипт у меня ушло где-то полчаса времени на все. Про криптоконтейнер - надо подумать, возможно тоже сделаю. Это всяко будет меньше времени чем на аудит, ибо реализация будет такой же "палка-веревка".
pfffffffffffff
консольной утилитой не очень удобно будет пользоваться
kraamis Автор
Почему? Консоль всегда под рукой.
YaDr
Особенно на телефоне, да...
kraamis Автор
Termux
YaDr
Можно, конечно, жить без автодополнения - которое предоставляют всякие ластпассы и битвардены - но это крайне неудобно. Каждый раз открываем термукс, вспоминаем магические числа... Проще уж десяток-другой паролей помнить :-)
kraamis Автор
Ну в принципе да. Может конечно наиграюсь и брошу. Но за пару лет пока не надоело.
YaDr
На вкус и цвет. Спасибо за статью :-)
snaiper04ek
Менеджеры паролей подкупают удобством.
Пару лет назад я бы и не подумал что у меня будет куплен один из них.
Но они автоматически предлагают записать, автоматически предлагают вставить один из 10 логинов/паролей именно для этого сайта, автоматически предлагают обновить пароль при изменении, удобство на телефоне - вообще сказка.
Если всё-же есть страх за какие-то суперважные пароли, в заметки менеджера паролей можно внести параметры этой консольной утилиты, и останется помнить только соль для пароля, то есть сверхсуперсекретные пароли можно хранить в менеджере паролей, получается, просто иным способом.
mm3
Во первых в отличии от различных сервисов в KeePass база хранится локально, это файл сохранность которого ложится на плечи пользователя.
Во вторых это Open source а значит ты как пользователь можешь, а для параноиков должен, провести свой независимый аудит кода. Код должен быть более или менее читаемым, для понимания того что он делает, а значит закладки с отправкой данных должны быть видны. Ну а стойкость алгоритмов шифрования порой даже эксперты оценить не берутся.
В третьих не стоит бездумно ставить любые обновления, без проверки того что в эти обновления включено. Особенно если уже проведён аудит всего кода, то дополнительно проверить внесённые изменения не составит большого туда. И в случае любых обнаруженных проблем, как минимум сообщить о них сообществу, как максимум сделать форк и контролировать изменения самому.
kraamis Автор
Штука в том, что аудит кода, это задача для неспециалиста, коим я являюсь, штука довольно сложная.
xmcuz
Самая простая проверка: фиксировать весь исходящий трафик за какой-то промежуток активного использования ПО.
В идеале он должен отсутствовать.
В KeePassXC запросы могут появиться только при вызове определенных функций пользователя (загрузка значков и частичной проверки хешей через haveibeenpwned.com).
NTDLL
Сохранность файла, тем более зашифрованного и ещё неизвестного формата, это большая проблема.
Я придумывал свою систему хранения паролей именно из за этого. Сделал так, чтобы все пароли хранились в MFT. Учитывая то, что эта MFT дублируется дважды в разделе с NTFS и не фрагментируется. Плюс, у меня CRC для каждого пароля.
Меня уже всё это один раз крупно спасло. Я вытащил флешку без программного извлечения и у меня флешка стала нечитаемой. Восстанавливал через HEX-редактор, чтобы не затереть данные окончательно какой нибудь кривой прогой. Правда, MFT долго искал, я не знаю где хранится её адрес.
MonkAlex
Запретите keepass доступ в интернет (он ему не нужен) и пользуйтесь спокойно даже с закладками.
pfffffffffffff
Придет вирус и воспользуется закладкой)
Inine
А если при переносе базы забыть настроить правило?
А не может ли одна программа отправлять запросы, вызывая другую, например curl?
Tr_1986
А чем плох bitwarden на своём сервере? Это реально вопрос. Наткнулся на него буквально 3 дня назад, раздумываю. Может есть какой-то изначальный косяк, который перекрывает все плюхи?
kraamis Автор
У меня нет своего сервера.
Tr_1986
Даже NAS или VPS, RBi?
kraamis Автор
Нет. Как то не было необходимости в жизни.
Rim13
Использую дома vaultwarden, сервер на rust для bitwarden, есть докер для него. Не нужна email регистрация в bitwarden.
Все ок. Проблем не испытываю.
Anton_Kazantsev
Можно инструктаж как его поставить?
ASD2003ru
Тоже самое. До этого был Keepass с синхронизацией через webdav но keepass под linux и macos нет (в нормальном виде да еще и с синхронизацией), еще пробовал SafeInCloud но его тоже нет под linux. vaultwarden конечно не так крут как keepass но со своими фишками + возможность вебморды.
Serge78rus
kraamis Автор
Браузер-то я сам не напишу, к сожалению.
Serge78rus
В том то и дело, и даже аудит вряд ли проведете. А ведь ему Вы доверяете не только пароли, но и данные банковских карт, персональные данные, и т.д.
Buzzzzer
Можно взять Bitwarden, развернуть на своём сервере и ограничить ему доступ, чтоб исключить утечку данных.