Как bcrypt лучше подходит для будущего, чем увеличение количества итераций SHA?

Выполнение многих итераций с помощью хеш-функции имеет несколько тонкостей, потому что должна быть задействована какая-то «засолка», и потому что существующие хеш-функции не такие «случайные», как можно было бы надеяться; поэтому нужно соблюдать осторожность, и в этом случае вы получите PBKDF2. PBKDF2 был разработан для получения ключей, что не совсем то же самое, что и хэширование паролей, но оказалось, что и в этом он неплохо справляется.

bcrypt имеет (небольшое) преимущество перед PBKDF2-with-SHA-1 в том, что bcrypt получен из Blowfish блочный шифр. Смысл множества итераций в том, чтобы сделать обработку пароля медленной и, в частности, медленной для злоумышленника. Мы допускаем, что эта функция работает медленно для нормальных, честных систем, потому что она препятствует тщательному подбору пароля. Но злоумышленник может использовать оборудование, которое не использует обычная система, например. программируемый графический процессор, который значительно ускоряет вычисления, которые хорошо подходят для такого оборудования. Blowfish и bcrypt используют таблицы поиска в оперативной памяти (таблицы, которые модифицируются во время обработки); с такими таблицами легко работать на ЦП общего назначения, но они довольно громоздки на ГП; таким образом, bcrypt несколько препятствует совершенствованию обработки злоумышленником с помощью графического процессора. Это бонус, который делает bcrypt более предпочтительным для хранения паролей, чем PBKDF2.

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

Ваш вариант немного недоработан. Вы не сказали, как вы объединяете пароль и соль в свою схему хеширования. Выполнение этого неправильным образом может привести к уязвимостям. Преимущество bcrypt (и других стандартных KDF) заключается в том, что это хорошо определено.

Если вы посмотрите на PBKDF2 в обычном режиме HMAC-SHA1, он очень похож на то, что вы предлагаете.

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

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

bcrypt является хорошим эмпирическим правилом, потому что он правильно понимает несколько вещей (например, соль), которые вам пришлось бы явно реализовать, если бы вы использовали другую функцию.

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

Вот почему PBKDF2 — ваш друг. Это подробно описано в RFC 2898. PBKDF2 также ориентирован на будущее, поскольку не зависит от конкретного алгоритма хеширования. Например, можно заменить MD5 на SHA3, когда SHA3 будет завершен NIST.

Кроме того, небольшая зацепка на перспективу. Bcrypt будет работать, если парольная фраза, которую вы защищаете, «от 8 до 56 символов». Важный момент, о котором следует помнить, если по какой-то причине в будущем вам потребуются более длинные парольные фразы.

Я считаю, что «адаптивность» не имеет ничего общего с фактическим шифрованием, но вместо этого bcrypt является адаптивным хэшем: со временем его можно делать все медленнее и медленнее, чтобы он оставался устойчивым к конкретным атакам методом грубой силы против хэша и соли.

(Частично цитата из http://en.wikipedia.org/wiki/Bcrypt)