SHA1 vs md5 vs SHA256: що використовувати для входу в PHP?

Я роблю логін для php, і я намагаюся вирішити, чи використовувати SHA1 або Md5, або SHA256, про які я читав в іншій статті stackoverflow. Чи хтось із них більш безпечний, ніж інші? Для SHA1 / 256 я все-таки використовую сіль?

Також це безпечний спосіб зберігання пароля як хеша в mysql?

function createSalt()
{
    $string = md5(uniqid(rand(), true));
    return substr($string, 0, 3);
}

$salt = createSalt();

$hash = sha1($salt . $hash);

Ні. Ви повинні використовувати bcrypt. Хеші, які ви згадуєте, оптимізовані для швидкого та легкого використання апаратних засобів, а тому їх розтріскування мають однакові якості. Якщо у вас немає іншого вибору, принаймні обов’язково використовуйте довгу сіль і повторний хеш кілька разів.

Використання bcrypt в PHP 5.5+

PHP 5.5 пропонує нові функції хешування паролів . Це рекомендований підхід для зберігання паролів у сучасних веб-додатках.

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) {
    // Success! Log the user in here.
}

Якщо ви використовуєте старішу версію PHP, вам дійсно слід оновити , але поки ви не зможете використовувати password_compat щоб відкрити цей API.

Також, будь ласка, нехай password_hash()генерує сіль для вас. Він використовує CSPRNG .

Два застереження із криптовалюти

1. Bcrypt мовчки вріже будь-який пароль довжиною більше 72 символів.
2. Bcrypt обрізається після будь-яких NULсимволів.

( Доказ концепції для обох застережень тут.)

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

Замість того, щоб писати власну схему, використовуйте наявну бібліотеку, написану та / або оцінену фахівцями з безпеки.

• Zend\Crypt (частина Zend Framework) пропонує BcryptSha
• PasswordLockподібний, BcryptShaале він також зашифровує хеш-файли bcrypt автентифікованою бібліотекою шифрування .

TL; DR - Використовуйте bcrypt .

Я думаю, що використовувати md5 або sha256 або будь-який хеш, оптимізований для швидкості, ідеально, і мені дуже цікаво почути будь-які спростування інших користувачів. Ось мої причини

1. Якщо ви дозволяєте користувачам використовувати слабкі паролі, такі як Бог, любов, війна, мир, то незалежно від шифрування, ви все одно будете дозволяти користувачеві вводити пароль, а не хеш, і ці паролі часто використовуються першими, таким чином, це НЕ буде мати щось спільне з шифруванням.

2. Якщо ви не використовуєте SSL або не маєте сертифікату, зловмисники, які слухають трафік, зможуть витягнути пароль, а будь-які спроби шифрування за допомогою JavaScript або тому подібного є клієнтом і легко зламаються та долаються. Знову ж це НЕ матиме нічого спільного з шифруванням даних на стороні сервера.

3. Брутальні атаки скористаються слабкими паролями і знову ж таки тому, що ви дозволяєте користувачеві вводити дані, якщо у вас немає обмеження на вхід 3 або навіть трохи більше, проблема знову НЕ мати нічого спільного з шифруванням даних.

4. Якщо ваша база даних стає скомпрометована, швидше за все, все було порушено, включаючи ваші методи хешування, незалежно від того, наскільки крипто ви це зробили. Знову ж таки це може бути незадоволена атака співробітника XSS або введення sql або інша атака, яка не має нічого спільного з шифруванням вашого пароля.

Я вважаю, що ви все ще повинні шифруватись, але єдине, що я можу бачити, це шифрування - це завадити людям, які вже мають або якимось чином отримали доступ до бази даних, просто не читати вголос пароль. Якщо це хтось, хто не має дозволу на базі даних, то у вас виникають більші проблеми, через що Sony взяла, тому що вони думали, що зашифрований пароль захищає все, включаючи номери кредитних карток, і все, що це робиться, - це захистити те поле.

Єдина чиста користь, яку я можу побачити при складних шифруваннях паролів у базі даних, - це затримати співробітників або інших людей, які мають доступ до бази даних, лише зчитуючи паролі. Тож якщо це невеликий проект або щось таке, я б не переймався питанням безпеки на серверній стороні, а я б більше переживав про те, щоб забезпечити що-небудь, яке клієнт може надіслати на сервер, наприклад, введення sql, XSS-атаки чи безліч інших способів може бути поставлено під загрозу. Якщо хтось не погоджується, я з нетерпінням чекаю прочитання способу, що супер зашифрований пароль є обов'язковим з боку клієнта.

Причина, яку я хотів спробувати зробити це зрозумілим, полягає в тому, що занадто часто люди вважають, що зашифрований пароль означає, що їм не потрібно турбуватися про те, що він порушений, і вони кидають турбуватися про безпеку веб-сайту.

Як зазначав Йоханнес Горсет, повідомлення Томаса Птачека з Matasano Security пояснює, чому прості, хеш-функції загального призначення, такі як MD5, SHA1, SHA256 та SHA512, є поганим вибором хешування паролів .

Чому? Вони занадто швидкі - ви можете обчислити щонайменше 1 000 000 хешів секунди на ядро ​​за допомогою сучасного комп'ютера, тому груба сила можлива проти більшості паролів, якими користуються люди. І це набагато менше, ніж кластерний кластерний серверний кластер!

Соління без розтягування ключів означає лише, що ви не можете попередньо обчислити таблицю веселки, вам потрібно побудувати її спеціально для цієї конкретної солі. Але це насправді не ускладнить справи.

Користувач @Will каже:

Усі говорять про це так, як їх можна зламати через Інтернет. Як уже було сказано, обмеження спроб унеможливлює зламати пароль через Інтернет і не має нічого спільного з хешем.

Їм не потрібно. Мабуть, у випадку з LinkedIn вони використовували загальну вразливість ін'єкцій SQL, щоб отримати таблицю БД входу та зламали мільйони паролів в автономному режимі.

Потім він повертається до сценарію офлайн-атаки:

Безпека дійсно вступає в гру, коли вся база даних порушена, і хакер може виконувати 100 мільйонів спроб пароля в секунду проти хеду md5. SHA512 приблизно в 10000 разів повільніше.

Ні, SHA512 не в 10000 разів повільніше, ніж MD5 - це займає лише приблизно вдвічі більше. Crypt / SHA512 , з іншого боку, є зовсім іншим звіром, який, як і його аналог BCrypt, виконує розтягування ключів , створюючи дуже різний хеш із вбудованою випадковою сіллю і забирає що-небудь від 500 до 999999 разів більше, ніж для обчислення (розтягнення піддається регулюванню).

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

Тож вибір для PHP - це Crypt / Blowfish (BCrypt), Crypt / SHA256 або Crypt / SHA512. Або принаймні Crypt / MD5 (PHK). Дивіться www.php.net/manual/en/function.crypt.php

Використовуйте SHA256. Це не ідеально, як це SHA512було б ідеально для швидкого хешу, але поза варіантами це його певний вибір. Відповідно до будь-якої технології хешування, не забудьте посолити хеш для додаткової безпеки.

Як додана примітка, FRKT, будь ласка, покажіть мені, де хтось може легко зламати солоний хеш SHA256? Мені справді дуже цікаво це бачити.

Важлива редакція:

Рухаючись вперед, будь ласка, використовуйте bcryptяк затверділий хеш. Більше інформації можна знайти тут .

Редагувати в засолюванні:

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

Що, здається, людей не вистачає, це те, що якщо хакер має доступ до бази даних, він, ймовірно, також має доступ до файлу php, який має хеш-пароль і, можливо, може просто змінити його, щоб надіслати йому всі успішні комбінації паролів імені користувача. Якщо у нього немає доступу до веб-каталогу, він завжди може просто вибрати хеш пароля і записати його в базу даних. Іншими словами, алгоритм хешу насправді не має значення як безпека системи, а обмеження спроб входу також, якщо ви не використовуєте SSL, зловмисник може просто прослухати підключення, щоб отримати інформацію. Якщо вам не потрібно, щоб алгоритм витрачав тривалий час на обчислення (для власних цілей), то SHA-256 або SHA-512 із специфічною для користувача сілкою має бути достатньо.

Як доданий захід безпеки встановіть скрипт (bash, batch, python тощо) або програму та вкажіть неясне ім'я та перевірте, чи змінився login.php (перевірити дату / часовий штамп) та надішлете вам електронний лист якщо є. Також, ймовірно, слід зафіксувати всі спроби входу з правами адміністратора та записати всі невдалі спроби увійти в базу даних, а журнали вам надішлють електронною поштою.

Усі говорять про це так, як їх можна зламати через Інтернет. Як уже було сказано, обмеження спроб унеможливлює зламати пароль через Інтернет і не має нічого спільного з хешем.

Сіль є обов'язковою, але складність або кілька солей навіть не мають значення. Будь-яка сіль само зупиняє зловмисника від використання попередньо веселого столу. Унікальна сіль на кожного користувача зупиняє зловмисника від створення нової таблиці веселки, яку слід використовувати для всієї вашої бази користувачів.

Безпека дійсно вступає в гру, коли вся база даних порушена, і хакер може виконувати 100 мільйонів спроб пароля в секунду проти хеду md5. SHA512 приблизно в 10000 разів повільніше. Складний пароль із сьогоднішньою потужністю все-таки може зайняти 100 років, щоб жорстка сила з md5, і SHA512 зайняла б 10000 разів довше. Солі взагалі не зупиняють жорстоку силу, так як вони завжди повинні бути відомими, а якщо зловмисник завантажив вашу базу даних, він, швидше за все, був у вашій системі.

MD5 поганий через проблеми зіткнення - два різні паролі, можливо, генерують один і той же md-5.

Ша-1 був би досить безпечним для цього. Причиною зберігання засоленої версії пароля sha-1 є те, що ви не перестанете зберігати в програмі додаткове слово користувача, яке вони можуть використовувати на серверах інших людей. Інакше яка різниця?

Якщо хакер вкраде всю вашу незашифровану базу даних, єдине, що робить хешований солоний пароль, - це не допустити, щоб він видав себе за користувача на майбутніх реєстраторів - хакер уже має дані.

Яку користь для зловмисника має хешоване значення, якщо те, що вводить ваш користувач, це звичайний пароль?

І навіть якщо хакер з майбутніми технологіями міг би генерувати мільйон ключів ша-1 на секунду для грубої атаки, чи вдасться ваш сервер обробляти мільйон логотипів секунди, щоб хакер перевірив свої ключі? Ось якщо ви дозволяєте хакеру спробувати ввійти в систему із засоленим ша-1 замість пароля, як звичайний вхід.

Найкраще, щоб обмежити невдалі спроби входу на якусь розумну кількість - наприклад, 25, а потім вимкнути користувача на хвилину-дві. І якщо сукупна спроба входу в систему не перевищує 250 протягом 24 годин, вимкніть доступ до облікового запису та надішліть електронному адресу власнику.

Ось порівняння між MD5 та SHA1. Ви можете зрозуміти, який з них краще.

Використовуйте argon2i . Argon 2 паролів перемогла в конкурсі паролів.

Інші розумні варіанти, при використанні Argon 2 немає в наявності, є Scrypt , Bcrypt і PBKDF2 . У Вікіпедії є сторінки для цих функцій:

• https://en.wikipedia.org/wiki/Argon2
• http://en.wikipedia.org/wiki/Scrypt
• http://en.wikipedia.org/wiki/Bcrypt
• http://en.wikipedia.org/wiki/PBKDF2

MD5, SHA1 і SHA256 - це дайджести повідомлень, а не функції збору паролів. Вони не підходять для цієї мети.

Перехід з MD5 на SHA1 або SHA512 не настільки поліпшить безпеку конструкції. Обчислення хеша SHA256 або SHA512 дуже швидко. Зловмисник із загальним обладнанням все ще може спробувати десятки мільйонів (з одним процесором) або навіть мільярди (з одним графічним процесором) хешей за секунду. Хороші функції хешування паролів включають фактор роботи для уповільнення атак на словник.

Ось пропозиція для програмістів PHP: прочитайте відповіді на поширені запитання PHP, а потім використовуйте password_hash () .

Припустимо наступний момент: хакери викрадають нашу базу даних, включаючи користувачів та пароль (зашифровані). А хакери створили підроблений обліковий запис із паролем, який вони знають.

MD5 слабкий, оскільки його короткий і популярний і практично кожен хеш-покоління без пароля слабкий від атаки словника. Але ..

Отже, скажімо, що ми все ще використовуємо MD5 за допомогою солі. Хакери не знають солі, але вони знають пароль конкретного користувача. Так вони можуть перевірити: 12345 де 12345 - пароль ноу-хау і ????? - сіль. Хакери рано чи пізно можуть здогадатися про солі.

Однак якщо ми використовували MD5 + SALT і застосували MD5, то відновити інформацію не існує. Однак, повторюю, MD5 все ще короткий.

Наприклад, скажімо, що мій пароль: 12345. SALT - BILLCLINTON

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 з хешем: 56adb0f19ac0fb50194c312d49b15378

mD5 з хешем md5: 28a03c0bc950decdd9ee362907d1798a Я спробував скористатися цими онлайн-сервісами, і я не знайшов жодного, який міг би його зламати. І єдиний його MD5! (може бути, як сьогодні це буде crackeable, тому що я створив md5 в Інтернеті)

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

tldr MD5 (HASH + MD5 (пароль)) = нормально, але коротко, SHA256 - більш ніж достатньо.

Шифрування md5 - одне з найгірших, тому що ви повинні повернути код, і він уже розшифрований. Я рекомендував би вам SHA256. Я програмую трохи довше і мав хороший досвід. Нижче також було б шифрування.

password_hash() example using Argon2i

<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>
The above example will output something similar to:

Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0