Пароли из мастер-пароля
Пример: http://habrahabr.ru/post/149934/
Суть такова: вводится мастер-пароль и домен, а из них hmac-ом генерируется пароль для ресурса.
Что вы думаете о такой системе?
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
комментариев: 11558 документов: 1036 редакций: 4118
О PBKDF2 автор не слышал, но в комментариях его уже вроде послали в верном направлении. Но соли всё-таки нет, что неудивительно для странички с js.
Самой идее применительно к веб-сайтам лет семь. ЕМНИП, тогда была предложена кем-то из Принстонского CITP, причём наряду с расширением для Firefox в качестве proof-of-concept, что в принципе более кошерно с точки зрения прозрачного для пользователя применения.
комментариев: 101 документов: 0 редакций: 3
Что еще можете сказать, если заменить простой хеш на медленный?
Что мне в голову приходит: как, например, менять пароль на одном ресурсе – менять мастер-пароль и пароли на всех ресурсах?
Реален ли брут мастер-пароля?
комментариев: 11558 документов: 1036 редакций: 4118
Вот потому расширение для браузера — более Ъ-подход: есть возможность, по крайней мере, сохранить соль как несекретный параметр в локальном хранилище (и в плане UI всё более корректно).
Этого можно избежать, если схема двухуровневая — изменяемый мастер-пароль используется для шифрования статичного ключа, который далее и подаётся на вход KDF-функции наряду с доменом. Но такая модернизация тянет за собой потребность в RNG и возможности сохранять состояние.
Разумеется. И в отсутствие соли радужные таблицы передают Вам пламенный привет. Если сохранять состояние принципиально не хочется / не можется, то в качестве полумеры можно пустить на роль соли пользовательский логин для данного сайта, но тогда ему придётся вводить три параметра: мастер-пароль, домен и логин. Такое число параметров сводит на нет практичность схемы, но в отсутствие соли риск компрометации мастер-пароля становится вполне реален. (Кстати, отказ от использования логина вносит ещё одно ограничение: пользователь лимитирован единственной учётной записью на каждый сайт.)
И чем оно лучше шифрованного хранилища паролей?
Как я понял, основной плюс решения в посте ТС – что не надо ничего хранить, кроме мастер пароля в голове. Если уж сохранять – не проще ли хранить полноценную базу? Заодно решаются проблемы смены пароля и мультиакка.
комментариев: 11558 документов: 1036 редакций: 4118
Я с ним не сравнивал, это ортогональные схемы. Решение, интегрированное в браузер (будь то обычный хранитель паролей или такая же схема с KDF и доменными паролями), имеет преимуществом прозрачность для пользователя — достаточно ввести мастер-пароль, дальше всё происходит автоматически: канонизация домена, подстановка пароля в поле password и т.д. Минус же, как подсказывает КО, в том, что оно интегрировано в браузер.
А у реализации ТС минусов, помимо исполнения в браузере и отсутствия автоматизации, ещё больше, в том числе и в плане безопасности.
На хабре пишут школьники и заказные рекламные статьи фирм.
Каждые полгода-квартал там "изобретают" очередной пасс-генератор.
Даже анализировать которые лень.