SHA1 против MD5 против SHA256: что использовать для входа в PHP?

Question

Я делаю логин 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);

Answer 1

Ни. Вы должны использовать 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] (http://

Два предостережения от bcrypt

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

( Подтверждение концепции для обоих предостережений здесь.)

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

Вместо написания собственной схемы используйте существующую библиотеку, написанную и / или оцененную экспертами по безопасности.

• Zend\Crypt (часть Zend Framework) предлагает BcryptSha
• PasswordLock аналогично BcryptSha, но также шифрует хэши bcrypt с помощью аутентифицированной библиотеки шифрования .

TL; DR - Использовать bcrypt .

Answer 2

Я думаю, что использование md5 или sha256 или любого хэша, оптимизированного для скорости, совершенно нормально, и мне очень любопытно слышать любые опровержения, которые могут иметь другие пользователи. Вот мои причины

1. Если вы разрешаете пользователям использовать слабые пароли, такие как Бог, любовь, война, мир, тогда независимо от шифрования вы все равно будете позволять пользователю вводить пароль, а не хеш, и эти пароли часто используются первыми таким образом, это НЕ будет иметь какое-либо отношение к шифрованию.

2. Если вы не используете SSL или не имеете сертификата, злоумышленники, прослушивающие трафик, смогут получить пароль, и любые попытки шифрования с помощью javascript или чего-либо подобного выполняются на стороне клиента, и их легко взломать и преодолеть. Опять же, это НЕ будет иметь какое-либо отношение к шифрованию данных на стороне сервера.

3. Атаки грубой силы будут использовать слабые пароли, и опять же, потому что вы позволяете пользователю вводить данные, если у вас нет ограничения на вход в систему 3 или даже чуть больше, чем проблема снова будет НЕ имеет какое-либо отношение к шифрованию данных.

4. Если ваша база данных скомпрометирована, то, скорее всего, все скомпрометировано, включая ваши методы хеширования, независимо от того, насколько загадочным вы это сделали. Опять же, это может быть XSS-атака недовольного сотрудника или SQL-инъекция или какая-либо другая атака, которая не имеет ничего общего с шифрованием вашего пароля.

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

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

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

Answer 3

Как отметил Йоханнес Горсет, сообщение Томаса Птачека из Matasano Security объясняет, почему простые универсальные функции хеширования, такие как MD5, SHA1, SHA256 и SHA512, не подходят для хеширования паролей .

Почему? Они слишком быстрые - вы можете рассчитывать не менее 1 000 000 хешей MD5 в секунду на ядро ​​с помощью современного компьютера, поэтому грубая сила возможна для большинства паролей, которые люди используют. И это намного меньше, чем кластерный сервер на базе GPU!

Соление без растяжения ключа означает только то, что вы не можете предварительно вычислить радужный стол, вам нужно построить его специально для этой конкретной соли. Но это не сильно усложнит жизнь.

Пользователь @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

Answer 4

Используйте SHA256. Он не идеален, так как SHA512 был бы идеальным для быстрого хэширования, но из всех возможных вариантов, это определенный выбор. Что касается любой технологии хеширования, обязательно добавьте хеш для дополнительной безопасности.

В качестве дополнительного примечания, FRKT, пожалуйста, покажите мне, где кто-то может легко взломать соленый хеш SHA256? Мне действительно очень интересно это увидеть.

Важно Редактировать:

Для продвижения вперед используйте bcrypt как усиленный хеш. Дополнительную информацию можно найти здесь .

---

Изменить на засолке:

Использовать случайное число или случайный поток байтов и т. Д. Вы можете также использовать уникальное поле записи в своей базе данных как соль, так что соль отличается для каждого пользователя.

Answer 5

То, что людям, похоже, не хватает, так это то, что если у хакера есть доступ к базе данных, он, вероятно, также имеет доступ к php-файлу, который хэширует пароль и, вероятно, может просто изменить его, чтобы отправить ему все удачные комбинации имени пользователя и пароля.Если у него нет доступа к веб-каталогу, он всегда может просто выбрать хэш пароля и записать его в базу данных.Другими словами, алгоритм хеширования на самом деле не так важен, как безопасность системы, и ограничение попыток входа в систему также, если вы не используете SSL, тогда злоумышленник может просто прослушать соединение, чтобы получить информацию.Если вам не нужен алгоритм, чтобы долго вычислять (для ваших собственных целей), тогда SHA-256 или SHA-512 с определенной солью пользователя должно быть достаточно.

Как добавленоМера безопасности устанавливает сценарий (bash, batch, python и т. д.) или программу, присваивает ей неизвестное имя, проверяет, изменился ли login.php (отметка даты / времени), и отправляет вам электронное письмо, если оно есть.,Также, вероятно, следует регистрировать все попытки входа в систему с правами администратора и регистрировать все неудачные попытки входа в базу данных и получать журналы по электронной почте.

Answer 6

Все говорят об этом, как будто их можно взломать через Интернет. Как уже говорилось, ограничение попыток делает невозможным взлом пароля в Интернете и не имеет никакого отношения к хешу.

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

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

Answer 7

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

Answer 8

Используйте argon2i . Функция хеширования пароля argon2 выиграла конкурс хэширования паролей.

Другие разумные варианты, если использование argon2 недоступно: 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: прочитайте FAQ по PHP , затем используйте password_hash () .

Answer 9

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

Ша-1 был бы достаточно безопасен для этого. Причина, по которой вы сохраняете соленую версию пароля sha-1, заключается в том, что вы, как правило, не сохраняете пароль пользователя в файле, который он может использовать на серверах других людей. Иначе, какая разница?

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

Что хорошего в том, что злоумышленник получает хеш-значение, если ваши пользовательские данные являются простым паролем?

И даже если бы хакер с будущей технологией мог генерировать миллион ключей ша-1 в секунду для атаки грубой силы, будет ли ваш сервер обрабатывать миллион входов в секунду, чтобы хакер проверил свои ключи? Это если вы позволяете хакеру попытаться войти с посоленным sha-1 вместо пароля, как при обычном входе.

Лучше всего ограничить количество неудачных попыток входа в систему каким-либо разумным числом - например, 25, а затем отключить пользователя на одну или две минуты. И если кумулятивная попытка входа в систему с ошибками достигнет 250 в течение 24 часов, закройте доступ к учетной записи и отправьте электронное письмо владельцу.

Answer 10

Давайте предположим следующее: хакеры крадут нашу базу данных, включая пользователей и пароль (зашифрованные). И хакеры создали поддельную учетную запись с паролем, который они знают.

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

Итак, допустим, что мы все еще используем MD5 с ОСО. Хакеры не знают СОЛИ, но знают пароль конкретного пользователя. Таким образом, они могут проверить: «12345, где 12345 - это пароль и пароль» это соль. Хакеры рано или поздно могут угадать СОЛЬ.

Однако, если мы использовали соль MD5 + и MD5, то восстановить информацию невозможно. Однако, повторяю, MD5 все еще короток.

Например, допустим, мой пароль: 12345. СОЛЬ БИЛЛЛИНТОН

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 с хешем: 56adb0f19ac0fb50194c312d49b15378

mD5 с хешем md5: 28a03c0bc950decdd9ee362907d1798a Я пытался использовать этот онлайн-сервис и не нашел ни одного, который смог бы его взломать. И это только MD5! (может быть, как сегодня, это может быть взломано, потому что я сгенерировал md5 онлайн)

Если вы хотите перебить, то SHA256 более чем достаточно, если его наносить солью и дважды.

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