SATtva:
аписать пароли в файл и зашифровать его открытым ключом, закрытая часть которого лежит на Вашей машине? Да хоть даже закрыть базу случайным 20-значным паролем

SATtva:
Вы не привели модель угрозы

Так вариант этого 20-ти значного пароля проверяется за доли секунды

распределенных вычислений – brute force атак

Радужных таблиц

Опция эта PBKDF2^[link3] — стандартная и должна, по идее, в обязательном порядке использоваться во всех криптографических программах, в которых генерируется ключ из пароля. Хотя, не везде есть возможность менять дефолтные значения.

Возможность эта не настолько эффективна как кажется. С вашим запредельным числом итераций вы внесли всего около тридцати бит "фиктивной" вычислительной энтропии. Это скромный результат. Сравните по вышеприведённым ссылкам, насколько для достижения аналогичного результата потребовалось бы увеличить пароль.

Альтернативный нестандартизированный вариант — scrypt^[link4] — размен с упором не на количество операций, а на требования к памяти. Если для одной машины несколько мегабайт некритично, то при массированном распараллеливании, особенно на видеокартах (на которых из-за высокого быстродействия и параллелизации просчитывают радужные таблицы, генерируют биткоины), это ставит противника в трудное положение.

Радужных таблиц

Радужные таблицы применяются когда известен хэш и не использовалась соль. К данному вопросу не имеет отношения.

Тоже верно.

One weakness of PBKDF2 is that while its c parameter can be adjusted to make it take an arbitrarily large amount of computing time, it can be implemented with a small circuit and very little RAM, which makes brute-force attacks using ASICs or GPUs relatively cheap[15]. The bcrypt key derivation function requires a larger (but still fixed) amount of RAM and is slightly stronger against such attacks, while the more modern scrypt[15] key derivation function can use arbitrarily large amounts of memory and is much stronger.

default:
  localcipher = blowfish,7
  ypcipher = blowfish,7

the value can be between 4 and 31

default:
        localcipher = sha1
        ypcipher = old

The cipher to use for local passwords. Possible values are: «old», «newsalt,<rounds>», «md5», and «blowfish,<rounds>» where «old» means classic 56-bit DES (facepalm). For «newsalt» the value of rounds is a 24-bit integer with a minimum of 7250 rounds. For «blowfish» the value can be between 4 and 31. It specifies the base 2 logarithm of the number of rounds.

Есть у кого соображения как хранить удаленно базу данных паролей напр. на e-mail или удаленном сервере?

есть мнение, что в данном случае на сервере должны быть не пароли, а хеш+соль.

Ему ж не авторизовываться на сервере надо, а хранить бэкапы самих паролей, потому хэш+соль не подойдут.

Вам неочевидно, зачем применяются специальным образом сконструированные key derivation function, замедляющие перебор?

An example parameters file which uses PKCS#5 PBKDF2:

algorithm aes-cbc;
             iv-method encblkno1;
             keylength 128;
             verify_method none;
             keygen pkcs5_pbkdf2/sha1 {
                     iterations 39361;
                     salt AAAAgMoHiYonye6Kog \
                          dYJAobCHE=;
             };

Можно генерить paramsfile и для своих целей, необязательно его использовать для того, что в man описано. Параметр iterations можете поменять руками, но не переусердствуйте. Если поставить раз в 10-100 больше, чем в норме, пароль будет проверяться минуту.

о, спасибо, надо брать на вооружение

Хотя стандартных консольных тулзов для PKBDF2 вроде бы нет, есть примеры реализации на Perl'е

SATtva:
хранится на Вашей машине

На уровне простой опции не скажу, но примеры использования у авторов есть. Как и примеры цепочечного расшифрования контейнеров по одному паролю, у которых ключ-пароль связаны хэшем.

Если шифр не подразумевает такой возможности штатно, то вы рискуете изменив число раундов даже в сторону увеличения открыть путь к слайд-атаке или ещё какой неприятности. Или об итерациях какого шифра речь? Вроде разговор о хэше?

Или об итерациях какого шифра речь?

то вы рискуете изменив число раундов даже в сторону увеличения открыть путь к слайд-атаке или ещё какой неприятности

Хэши устойчивы к повторениям. Вероятность снижения энтропии в цепочке хэшей из-за коллизий и получения циклов пренебрежимо мала при любом мыслимом числе итераций.

unknown:
Нет, речь шла о раундах, а не полнораундовых итерациях, в шифровании, когда я не так понял вопрос.

Все верно, речь шла о раундах. Т.е. при увлечении итераций с напр 1 – 10 для получении конечного результата хеша приходится прогнать функцию 10 раз, не сделав этого никак не получится результат который используется в ключе... Таким образом атаки перебором все таки замедляются.

unknown:
С вашим запредельным числом итераций вы внесли всего около тридцати бит "фиктивной" вычислительной энтропии.

Как Вы оценили приблизительно кол-во бит? Ведь получить конечное значение хеша не зациклив его указанное число раз невозможно...

соображения как хранить удаленно базу данных паролей