Чи існують реалізації 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('utf-8').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.subtleу доступному лише на httpsабо localhost- наприклад, для вашого місцевого розвитку, python3 -m http.serverвам потрібно додати цей рядок до вашого /etc/hosts: 0.0.0.0 localhost

Перезавантажте - і ви можете відкрити localhost:8000з робочимcrypto.subtle .

КуватиВпровадження SHA-256 у є швидким та надійним.

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

Результати на моїй машині підказують, що forge є найшвидшим впровадженням, а також набагато швидшим, ніж криптобібліотека Stanford Javascript Crypto Library (sjcl), згадана у прийнятій відповіді.

Фордж має 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 crypto до браузера за допомогою 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 може бути надмірним. Але якщо у вас є інші потреби у відповідній галузі, я вважаю, що це добре підходить.