Хранение паролей в незащищенном месте
Есть у кого соображения как хранить удаленно базу данных паролей напр. на e-mail или удаленном сервере? В KeePass есть интересная фича – "Number of key transformation rounds" где можно установить значение "Delay" т.е. кол-во итераций хеширования как я понимаю. При экспорте базы можно устанавливать большое кол-во проходов, что на экспортной копии базы сведет атаки типа brute force на нет.
Например установив значение 9911238656, Core I7 считал 5 минут при 100% двух ядер для проверки одного пароля. Очень эффективная опция для хранителей паролей которые увы нет в Password Safe...
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 12 документов: 7 редакций: 4
Так вариант этого 20-ти значного пароля проверяется за доли секунды, как и 2 значного.
Максимально снизить вероятность получить пароль с помощью распределенных вычислений – brute force атак, Радужных таблиц и т.п в данном направлении.
Вот здесь удобная табличка оценки энтропии.
Ассиметричное шифрование это хорошо, но разве закрытый ключ правильно без passphrase оставлять?
Ничего не даст противнику. 128-битный ключ при условии, что алгоритм надёжен, нельзя вскрыть без квантового компьютера.
Мало поможет. Максимум снизит сложность на пару порядков, что недостаточно.
Радужные таблицы применяются когда известен хэш и не использовалась соль. К данному вопросу не имеет отношения.
комментариев: 9796 документов: 488 редакций: 5664
Опция эта PBKDF2 — стандартная и должна, по идее, в обязательном порядке использоваться во всех криптографических программах, в которых генерируется ключ из пароля. Хотя, не везде есть возможность менять дефолтные значения.
Возможность эта не настолько эффективна как кажется. С вашим запредельным числом итераций вы внесли всего около тридцати бит "фиктивной" вычислительной энтропии. Это скромный результат. Сравните по вышеприведённым ссылкам, насколько для достижения аналогичного результата потребовалось бы увеличить пароль.
Альтернативный нестандартизированный вариант — scrypt — размен с упором не на количество операций, а на требования к памяти. Если для одной машины несколько мегабайт некритично, то при массированном распараллеливании, особенно на видеокартах (на которых из-за высокого быстродействия и параллелизации просчитывают радужные таблицы, генерируют биткоины), это ставит противника в трудное положение.
Тоже верно.
Интересно, он где-то уже используется? Судя по рекламе на слайдах, он в сотни раз замедляет перебор по сравнению с PBKDF2. По вашей ссылке на вики тоже очень рекламируется:
А что можно сказать про bcrypt в сравнении с PBKDF2? Кстати, в OpenBSD не bcrypt ли используется для хранения паролей в /etc/master.passwd и для их vnconfig? Вообще, было бы интересно увидеть список какие KDF используются в разных Unix'ах. Что-то известно про применение scrypt для софта в Linux?
Посмотрел на NetBSD. В cgd там-таки pbkdf2, но в /etc/master.passwd всё тухло. Лучшее, что есть — blowfish+раунды. И, вообще, что значит «blowfish как hash-функция»? Поглядел в /etc/passwd.conf, который автоматически создаётся при инсталляции и выборе самых безопасных опций:
При этом в OpenBSD аналогичный дефолт — «blowfish,6». В статье про bcrypt говорится, что его сделал «The OpenBSD Project» — это оно и есть в опциях с blowfish? В предпоследней ссылке:
P.S.: А про сам проект http://www.tarsnap.com, куда ведут ваши ссылки, что можете сказать? Он чем-то лучше tahoe или совсем нераспределённый?
комментариев: 43 документов: 0 редакций: 7
есть мнение, что в данном случае на сервере должны быть не пароли, а хеш+соль.
комментариев: 43 документов: 0 редакций: 7
Блин, не понял идею в начале. Получается, что сложность пороля увеличивается, так как к нему добавляется число проходов, но при расшифровке даже зная пароль выполняется некоторый брутфорс в течении 5-10 минут. Кто, что думает, сравнимы ли по вычислительной сложности задачи вида пароль=X+Y и пароль=X + проходов=Y. Что-то мне кажется, что вторая задача не должна брутфорситься больше, чем первая.
Сама идея весьма интересна, только лучше её переформулировать в такую: пользователь вводит пароль(или подсовывает ключ), и к нему присовокупляется ещё, ну три-четыре символа из /dev/urandom. При расшифровке требуется кроме правильного пароля ещё немного брутфорса, но разумное время(допустим 10 минут). Ясно, что сложность взлома растёт, так как выросла энтропия пароля.
комментариев: 43 документов: 0 редакций: 7
Например: Можно генерить paramsfile и для своих целей, необязательно его использовать для того, что в man описано. Параметр iterations можете поменять руками, но не переусердствуйте. Если поставить раз в 10-100 больше, чем в норме, пароль будет проверяться минуту.
комментариев: 43 документов: 0 редакций: 7
о, спасибо, надо брать на вооружение
Вот ещё:
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 12 документов: 7 редакций: 4
Хочется хранить пароли удаленно. Иметь возможность открыть базу паролей имея только пароль. Но в таком случае усложить задачу атак перебором.
Господа а как на счет криптографических приложенияй способных не только менять кол-во итераций хеширования но и опционально выставлять другие параметры, например таких кол-во итераций шифра, размер блока и т.д..?