Я читав, що при хешуванні пароля багато програмістів рекомендують використовувати алгоритм BCrypt.
Я програмую на C # і мені цікаво, чи хтось знає про гарну реалізацію BCrypt? Я знайшов цю сторінку , але насправді не знаю, вона хибна чи ні.
Що я повинен знати, вибираючи схему хешування паролів? Чи BCrypt є "хорошою" реалізацією?
Відповіді:
По-перше, кілька важливих термінів:
Хешинг - акт прийняття рядка та створення послідовності символів, які неможливо повернути до початкового рядка.
Симетричне шифрування - (зазвичай його також називають «шифруванням») - акт прийняття рядка та створення послідовності символів, які можна розшифрувати до початкового рядка, використовуючи той самий ключ шифрування, який його зашифрував.
Таблиця веселки - таблиця пошуку, яка містить усі варіанти хешированих символів у певному алгоритмі хешування.
Сіль - відомий випадковий рядок, доданий до початкового рядка до його хешування.
Для .NET Framework Bcrypt ще не має перевіреної посилання. Це важливо, оскільки немає можливості дізнатися, чи є серйозні недоліки в існуючій реалізації. Ви можете отримати реалізацію BCrypt для .NET тут . Я не знаю достатньо про криптографію, щоб сказати, чи це хороша чи погана реалізація. Криптографія - це дуже глибоке поле. Не намагайтеся створити власний алгоритм шифрування . Серйозно.
Якщо ви збираєтеся реалізувати власну безпеку пароля (зітхання), то вам потрібно зробити кілька речей:
На жаль, навіть якщо ви все це зробите, рішучий хакер все-таки потенційно міг розібратися в паролях, це зайняло б його дуже довго. Ось ваш головний ворог: час .
Алгоритм bcrypt працює, оскільки для хешування пароля потрібно п'ять порядків більше, ніж MD5 ; (і все ж набагато довше, ніж AES або SHA-512). Це змушує хакера витратити набагато більше часу на створення веселкової таблиці для пошуку ваших паролів, що робить набагато меншою ймовірність того, що ваші паролі будуть під загрозою злому.
Якщо ви засолюєте та хешируете свої паролі, і кожна сіль відрізняється, потенційний хакер повинен створити таблицю веселки для кожного варіанту солі , просто щоб мати таблицю веселки для одного засоленого + хешованого пароля. Це означає, що якщо у вас є 1 мільйон користувачів, хакер повинен генерувати 1 мільйон райдужних таблиць. Якщо ви використовуєте однакову сіль для кожного користувача, хакер повинен створити лише одну таблицю веселки, щоб успішно зламати вашу систему.
Якщо ви не засолюєте свої паролі, то зловмисник повинен лише підняти існуючу таблицю Rainbow для кожної реалізації там (AES, SHA-512, MD5) і просто подивитися, чи відповідає один хеш. Це вже зроблено , зловмиснику не потрібно обчислювати ці таблиці Веселки .
Навіть при всьому цьому ви повинні використовувати хороші методи безпеки . Якщо вони можуть успішно використовувати інший вектор атаки (XSS, SQL Injection, CSRF та ін. ) На вашому сайті, хороша безпека паролів не має значення. Це звучить як суперечливе твердження, але подумайте: якщо я можу отримати всю вашу інформацію про користувача через атаку ін'єкції SQL, або я можу змусити ваших користувачів передавати мені файли cookie через XSS, то не важливо, наскільки хороший ваш пароль безпека є .
Інші ресурси:
Примітка. Будь ласка, рекомендуйте інші хороші ресурси. Я, мабуть, прочитав десяток статей десятків авторів, але мало хто пише так просто, як Джефф. Будь ласка, редагуйте в статтях, як ви їх знайдете.
Ви не повинні використовувати BCrypt в .NET. Ви повинні використовувати PBKDF2, як і вбудована в .NET рамка. Це єдина вільно доступна криптографічно підтверджена реалізація в .NET, а також алгоритм, рекомендований NIST .
StackId раніше використовував BCrypt і саме з цієї причини перейшов на PBKDF2:
Для тих, хто цікавиться, ми хешируємо паролі з PBKDF2. Код розслаблення тут ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), через кілька шарів непрямості . У попередній ітерації ми використовували BCrypt; але він перейшов до PBKDF2, оскільки він вбудований у рамку .NET, тоді як BCrypt вимагатиме від нас перевірки виконання (не мале зобов'язання).
Кевін Монтроуз, 27 травня 2011 року
(Оновлене посилання на GitHub)
Редагувати: Здається, сенс підтвердженого в криптографічному відношенні поняття не легко зрозумілий; перевірена реалізація означає, що його криптографічно доведено реалізувати без помилок. Вартість цього може легко досягти 20 000 доларів або вище. Я пам’ятаю це, коли я робив дослідження на OpenSSL і читав, де вони заявляли, що не завершили весь процес перевірки, але якщо вам потрібно повністю перевірити, що вони можуть вказати вам правильний шлях для цього та згадані пов'язані з цим витрати. Окремі вимоги уряду включають мандати для перевірених алгоритмів шифрування.
Реалізації bcrypt в .NET не підтверджені. Використовуючи неперевірену реалізацію шифрування, ви не можете бути абсолютно впевнені в тому, що в ній немає ні навмисних зловмисних помилок, таких як введення заднього дому в те, що зашифроване, або ненавмисні помилки реалізації, що призводять до криптографічно незахищених даних.
2014 редакція: Для тих, хто поставив під сумнів імперативність використання перевірених криптографічних алгоритмів, подивіться на спустошення, спричинене сердечним злом, що експлуатується в OpenSSL. Це вартість використання неперевіреної реалізації. Це безпечно .... поки ви не дізнаєтесь, що будь-яка людина може просто прочитати весь вміст пам'яті вашого сервера.
Автор змін, який представив Heartbleed, Робін Сеггельманн, заявив, що "пропустив перевірку змінної, що містить довжину", і заперечив будь-який намір подати хибну реалізацію. Після розкриття Heartbleed Сеггельман запропонував зосередитися на другому аспекті, заявивши, що OpenSSL не розглядається достатньою кількістю людей.
Це визначення неперевіреної реалізації. Навіть найменший дефект може призвести до калічі всієї безпеки.
2015 редагувати: Видалено мову на основі рекомендацій та замінено абсолютними. Вкладений оригінальний коментар Кевіна Монтроза для нащадків.