https://www.whonix.org/wiki/Passwords

Запоминать не надо. Все пароли и учётные записи я храню в криптоконтейнере, к которому осуществляется доступ по мастер паролю + usb токену.

прогресс ушёл далеко вперёд...

https://www.keepassx.org/

Ну да, чуть более геморройно, чем ctrl-c/ctrl-v, всего лишь.

Или может ты с КЛАВИАТУРЫ такое способен ввести без ошибок?!

Ну работодателю не выгодно. Работодателю выгодно

1. наладить у себя инфраструктуру для построения базы. Чтобы он сам решал, что в неё попадёт. Если это можно сделать на обычном ноутбуке, то выбор очевиден.

2. если он хочет вас поддержать, кинуть вам денег можно, проведя это как услугу по профессиональной настройке инфраструктуры на аппаратуре клиента посредством удаленного SSH-доступа.

Гм, по #3 у меня:

- make update_pot update_po ничего не делают (хотя будто должны);
- xgettext -o po/passwdqc.pot --join-existing *.c лишь дату
  в pot-файлике обновляет, но не добавившиеся строки;
- с -a ругается уже на не-ASCII в passwdqc_filter.c:151.

Отправил почтой патч с добавлением новых строк вручную -- давно не брал в руки gettext, оказывается.  Принимать ли без починки обвязки -- смотрите сами.

> (они связаны с добавлением поддержки русскоязычных сообщений в 1.4.0+,
> которая пришла из ALT и я хочу чтобы и далее поддерживалась ALT'ом).

Резонно.

Пару лет - это если у вас вообще только один пароль от всего.

Кажется, что вещи разные, но на самом деле, зная, что устойчивость парольная начинается от Estimated Brute-force Time (Classical Computing) размером ~26,405,295,715,806,668,059,525,829,264 x age Universe, то можно сразу выработать такой подход - использовать спец. утилиту и генерировать как минимум ~194 Bits of Entropy.

Что касается passwdqc, то да - это скорее комплексное решение, но, при этом, таковое решение некоторые могут посчитать избыточным, если, чисто аналитически, мы знаем, что для генерации устойчивого пароля нам требуется около/свыше 200-х бит энтропии. То есть мы можем не тратить кучу времени на все эти фильтры, бд и прочие танцы с бубнами.

То есть всё это можно трактовать с разных точек зрения. На практике ситуации разные. Да, согласен, иногда нужны и комплексные решения.

Одним словом: путаница.

Путаница в том что такое энтропия. Это свойство распределения случайной величины, а не одного ее значения.

Путаница в отношении энтропии к сложности подбора пароля. Энтропия по Шеннону подходит для такой оценки только когда распределение равномерное, что для придумываемых пользователем фраз не соблюдается. Будет правильно сказать, например, что пароль, выданный pwqgen соответствует распределению с энтропией 47 бит по Шеннону и обеспечивает соответствующий уровень защиты от подбора (пока он не оказался как-либо скомпрометирован). Но будет ошибочно сказать что в "be or not to be that is the question" сколько-то бит энтропии, не зная как именно эта фраза была выбрана (какие еще были возможны варианты и с какой вероятностью они могли быть выбраны). "132.8 бит" получены в каком-то предположении об этом, которое в данном случае, вероятно, ошибочно. Также, ошибочно считать что эти биты, сколько бы их ни было, обеспечивают защиту от подбора. Например, если мы с вероятностью 1/2 выбираем пароль 123456 (энтропия которого ноль, так как других вариантов не было), а с вероятностью 1/2 запускаем идеальный генератор паролей с высокой энтропией, то итоговый поток паролей (половина которых - 123456) имеет высокую энтропию, но каждый второй пароль подбирается с первой попытки.

Путаница в моделях угроз. Для типичных паролей к веб-сайтам и т.п. важнее всего их уникальность, а не то удастся ли их подобрать из хеша после утечки. Конечно, всё равно используя менеджер паролей можно кодировать туда и 300 бит, но хватит и гораздо меньшего. А реально сложными должны быть только парольные фразы, используемые для шифрования чего-либо (в том числе "мастер-фраза для парольных менеджеров", это верно), а не лишь для контроля доступа.

Возможно, путаница в (подразумеваемом) назначении passwdqc. Оно в первую очередь в снижении доли и скорости успешного подбора паролей в масштабе организации. При этом успешный подбор паролей без доступа к их хешам (то есть попытки подсоединиться по сети) удается практически исключить, а с доступом к хешам (в случае их утечки) снизить и замедлить в разы или на порядки (в зависимости от типа и настроек хешей и настроек passwdqc). Для конечного пользователя же наиболее полезна утилита pwqgen (и аналогичная выдача случайных фраз в pam_passwdqc и программах под Windows), а также, в случае применения passwdqc в организации или на системе, выдача описания требований к паролям (в pam_passwdqc) и причины отказа пропустить конкретный пароль (в pam_passwdqc, libpasswdqc и программах).