Существуют ли какие-либо реализации JavaScript SHA-256, которые обычно считаются заслуживающими доверия?

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

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

Изменить, так как это часто встречается в комментариях: Да, мы снова делаем более строгий хеш на стороне сервера. Хеширование на стороне клиента - это не окончательный результат, который мы сохраняем в базе данных. Хеширование на стороне клиента происходит потому, что его запрашивает человек-клиент. Они не указали конкретную причину, почему, вероятно, они просто любят излишне.

УСТАРЕЛО: многие современные браузеры теперь имеют первоклассную поддержку криптографических операций. См . Ответ Виталия Зданевича ниже.

Stanford JS Crypto библиотека содержит реализацию SHA-256. Хотя криптография в JS на самом деле не так хорошо изучена, как другие платформы реализации, эта, по крайней мере, частично разработана и в определенной степени спонсируется Дэном Боне , который является хорошо зарекомендовавшим себя и пользующимся доверием именем в криптографии. , и означает, что над проектом осуществляет контроль кто-то, кто действительно знает, что делает. Проект также поддерживается NSF .

Однако стоит отметить ...
... что если вы хешируете пароль на стороне клиента перед его отправкой, то хеш-код является паролем , а исходный пароль становится неактуальным. Злоумышленнику нужно только перехватить хэш, чтобы выдать себя за пользователя, и если этот хеш хранится на сервере без изменений, то сервер хранит настоящий пароль (хеш) в виде обычного текста .

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

На https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest я нашел этот фрагмент, который использует внутренний модуль js:

async function sha256(message) {
    // encode as UTF-8
    const msgBuffer = new TextEncoder().encode(message);                    

    // hash the message
    const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);

    // convert ArrayBuffer to Array
    const hashArray = Array.from(new Uint8Array(hashBuffer));

    // convert bytes to hex string                  
    const hashHex = hashArray.map(b => ('00' + b.toString(16)).slice(-2)).join('');
    return hashHex;
}

Обратите внимание, что crypto.subtlein доступно только на httpsили localhost- например, для вашей локальной разработки, python3 -m http.serverвам необходимо добавить эту строку в свой /etc/hosts: 0.0.0.0 localhost

Перезагрузитесь - и можно начинать localhost:8000работать crypto.subtle.

Реализация Forge SHA-256 быстрая и надежная.

Чтобы запустить тесты для нескольких реализаций JavaScript SHA-256, перейдите по адресу http://brillout.github.io/test-javascript-hash-implementations/ .

Результаты на моей машине предполагают, что forge является самой быстрой реализацией, а также значительно быстрее, чем Стэнфордская криптографическая библиотека Javascript (sjcl), упомянутая в принятом ответе.

Forge имеет размер 256 КБ, но извлечение кода, связанного с SHA-256, уменьшает размер до 4,5 КБ, см. Https://github.com/brillout/forge-sha256

Для тех, кому интересно, это код для создания хэша SHA-256 с использованием sjcl:

import sjcl from 'sjcl'

const myString = 'Hello'
const myBitArray = sjcl.hash.sha256.hash(myString)
const myHash = sjcl.codec.hex.fromBits(myBitArray)

Нет, нет возможности использовать JavaScript в браузере для повышения безопасности паролей. Я очень рекомендую вам прочитать эту статью . В вашем случае самая большая проблема - проблема курица-яйцо:

В чем «проблема куриного яйца» с предоставлением криптографии Javascript?

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

[...]

Почему я не могу использовать TLS / SSL для доставки криптокода Javascript?

Вы можете. Это сложнее, чем кажется, но вы безопасно передаете шифрование Javascript браузеру с помощью SSL. Проблема в том, что, установив безопасный канал с SSL, вам больше не нужна криптография Javascript; у вас есть «настоящая» криптография.

Что приводит к следующему:

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

Для какой-либо части кода Javascript нет надежного способа проверить среду его выполнения. Криптографический код Javascript не может спросить: «Я действительно имею дело с генератором случайных чисел или с каким-то его факсимиле, предоставленным злоумышленником?» И он определенно не может утверждать, что «никому не разрешено делать что-либо с этой криптографической тайной, кроме тех способов, которые одобряю я, автор». Это два свойства, которые часто предоставляются в других средах, использующих шифрование, и они невозможны в Javascript.

В основном проблема заключается в следующем:

• Ваши клиенты не доверяют вашим серверам, поэтому они хотят добавить дополнительный код безопасности.
• Этот код безопасности доставляется вашими серверами (теми, которым они не доверяют).

Или, альтернативно,

• Ваши клиенты не доверяют SSL, поэтому они хотят, чтобы вы использовали дополнительный код безопасности.
• Этот защитный код доставляется через SSL.

Примечание. Кроме того, для этого не подходит SHA-256, так как несоленые неповторяющиеся пароли очень легко перебрать . Если вы все равно решите это сделать, поищите реализацию bcrypt , scrypt или PBKDF2 .

Я нашел эту реализацию очень простой в использовании. Также есть щедрая лицензия в стиле BSD:

jsSHA: https://github.com/Caligatio/jsSHA

Мне нужен был быстрый способ получить шестнадцатеричное представление хэша SHA-256. Потребовалось всего 3 строчки:

var sha256 = new jsSHA('SHA-256', 'TEXT');
sha256.update(some_string_variable_to_hash);
var hash = sha256.getHash("HEX");

Помимо Стэнфордской библиотеки, о которой упоминал Тайлерл. Я нашел jsrsasign очень полезным ( репозиторий Github здесь: https://github.com/kjur/jsrsasign ). Я не знаю, насколько он заслуживает доверия, но я использовал его API SHA256, Base64, RSA, x509 и т.д., и он работает очень хорошо. Фактически, он также включает Стэнфордскую библиотеку.

Если все, что вам нужно, это SHA256, jsrsasign может оказаться излишним. Но если у вас есть другие потребности в соответствующей области, я считаю, что это вам подходит.