Существуют ли какие-либо медленные алгоритмы хэширования Javascript, такие как bcrypt?

Я не говорю о серверном node.js.

Я хочу использовать алгоритм медленного хеширования для ключа на стороне клиента моего сайта. Я нашел реализации SHA-256, которые кажутся надежными. Я также нашел этот вопрос, который привел к OP создание собственной библиотеки.

Тем не менее, я не уверен, должен ли я просто делать несколько раундов хэширования SHA или доверять части этого кода, поскольку я не эксперт по безопасности, и, похоже, у него нет большого количества последователей, только 36 человек. .

Что лучше выбрать в этом случае? Я (в основном) не могу изменить методы, когда что-то выбираю.

Мне нужен алгоритм медленного хеширования (не шифрования), и я бы предпочел, чтобы он создавал короткую строку. Например, медленный 60-символьный bcrypt против быстрого 70-символьного SHA-256.


javascript bcrypt hash sha
person Xeoncross    schedule 07.11.2012    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

Я перечислю их в порядке теоретической безопасности:

  • PBKDF2 разработан RSA на основе SHA и является алгоритмом, рекомендованным NIST. Есть пара реализации, которые можно использовать в браузере.

    Примечание для пользователей Node. Модуль crypto Node имеет встроенную функцию PBKDF2< /а>. Используйте это.

  • bcrypt, основанный на Blowfish, немного более безопасен, чем PBKDF2. Он был относительно хорошо протестирован и проверен на безопасность, но не имеет одобрения каких-либо органов по стандартизации, если это важно для вас. Здесь приведена общая реализация JS.

    Примечание для пользователей Node: используйте node.bcrypt, который выполняет вычислительно затратные вещи в отдельном потоке.

  • Наконец, scrypt — безусловно, самый теоретически безопасный (самый медленный) KDF. К сожалению, алгоритм очень новый, поэтому он не прошел тщательного изучения и тестирования криптографическим сообществом. Однако он на пути к тому, чтобы стать стандартом IETF.

    Поскольку алгоритм настолько новый, ему трудно найти реализацию. Мне удалось найти только этот недоделанный. Хотя преимущества безопасности очень многообещающие, я бы не рекомендовал scrypt, пока и сам алгоритм, и его реализации не будут проверены на безопасность.

Как эти три на самом деле сравнить? В документе по шифрованию есть сравнение:

таблица сравнения алгоритмов

На самом деле, даже PBKDF2 делает взлом единственного 8-символьного пароля непомерно дорогим для всех, кроме правительства.

person josh3736    schedule 07.11.2012

arrow_upward
0
arrow_downward

Вы всегда можете игнорировать последние 10 символов быстрого SHA-256. Или xor первые 10 символов, которые нужно включить.

SHA имеет переменное количество раундов. Два раунда SHA должны быть несколько обратимыми. У меня смутное представление о том, что 20 патронов считаются "безопасными". 30 раундов должны быть «очень безопасными», а 50 раундов практически не улучшают безопасность.

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

Если только строка, создающая хэш, не очень маленькая или не написана на стикере на чьем-то мониторе.

person Aki Suihkonen    schedule 07.11.2012
comment
Да, я мог бы, но я бы не хотел. В любом случае, мой вопрос о том, как лучше всего медленно вычислять хэш с помощью Javascript. - person Xeoncross; 07.11.2012
comment
Чтобы уменьшить количество вычислений в секунду. Например, кто-то может пропустить вычисление Javascript и вместо этого использовать свой графический процессор для вычисления миллионов хэшей SHA2 в секунду. stackoverflow.com/q/6791126/99923 - person Xeoncross; 07.11.2012
comment
@Xeoncross: ответ Аки дает вескую причину, по которой вам не нужна нужна медлительность. Вообще. - person Deestan; 07.11.2012
comment
@Deestan, когда я комментировал, было написано только первое предложение. - person Xeoncross; 07.11.2012
comment
@AkiSuihkonen, проблема не в том, чтобы взломать хэш, проблема в том, что я не хочу, чтобы хэши вычислялись быстро. Учитывая ввод, даже SHA-1 был бы нерушим * для того, что я делаю, но это слишком быстро. - person Xeoncross; 07.11.2012
comment
@Xeoncross, ах, так оно и есть. Я отказываюсь от любого реального или задуманного презрения и желаю вам приятного дня. - person Deestan; 07.11.2012