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

133

Я делаю вход в 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);
Тони Старк
источник
См. Также этот ответ и прочтите раздел о хешировании паролей.
Ja͢ck

Ответы:

110

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

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

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

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

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

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

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

Йоханнес Горсет
источник
1
Кроме того, я новичок в этом: являются ли sha1, sha256 и md5 «хешами», на которые вы ссылаетесь?
Тони Старк
3
Да. Я имею в виду SHA1, SHA256 и MD5 и ряд других хешей, оптимизированных для скорости. Вы не хотите использовать хэш, оптимизированный для скорости, для защиты пароля. Есть много хороших статей, в которых обсуждается, почему, и мне особенно нравится эта: chargen.matasano.com/chargen/2007/9/7/…
Йоханнес Горсет
4
Он включен в функцию "crypt" начиная с PHP 5.3. Если у вас более ранняя версия, я бы посмотрел на фреймворк "phpass" в поисках следующего лучшего.
Йоханнес Горсет
3
@Stanislav Palatnik SHA512 - хорошая альтернатива. Не пойми меня неправильно; Я не говорю, что растянутый и соленый хеш SHA512 небезопасен. Это безопасно. Тем не менее, факт остается фактом: bcrypt более безопасен, и поэтому я не вижу причин не использовать его.
Йоханнес Горсет
10
@Cypher: bcryptразработан так, чтобы быть медленным, чтобы быть одинаково медленным для взлома.
Johannes Gorset
23

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

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

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

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

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

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

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

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

Роджер Джонсон
источник
1
Хорошо сказано. Cyber ​​Security предпочтительнее методов хеширования, они не только сохраняют ваши данные, но и поддерживают защиту сервера.
CᴴᴀZ
14
Это действительно дезинформировано. Конечно, безопасное хеширование паролей в базе данных не улучшает безопасность на уровне приложения или базы данных. Это не уловка для безопасности. Вы хотите надежно хэшировать пароль пользователя в своей базе данных по двум причинам; во-первых, клиент доверяет вам свой пароль, который они могут использовать или не использовать на других сайтах, поэтому вы хотите убедиться, что он не подлежит восстановлению, даже если ваш БД скомпрометирован, во-вторых, вы хотите снять ответственность в случае безопасности прорвать. Я не знаю ни о каких судебных процессах, но утечка паролей делает вашу компанию очень плохой.
Джеймс МакМахон
6
Это плохой совет. Если кто-то украдет вашу базу данных и получит все ваши хешированные пароли, даже если они также скомпрометировали другие части вашей базы данных, все равно может быть важно предотвратить взлом паролей и вход в систему. (Например, подумайте о банковском веб-сайте.) Оптимизированные по скорости алгоритмы позволяют злоумышленникам проверять множество кандидатов на соответствие украденным хешам, пока они не найдут совпадение. Такие алгоритмы, как bcrypt и scrypt, делают тестирование кандидатов на соответствие хешу медленным и дорогим, даже если они знают, какой алгоритм вы используете. Таким образом, они обеспечивают лучшую защиту, если кто-то украдет хэши.
Ричард
6
«Если ваша база данных скомпрометирована, то, скорее всего, скомпрометировано все, включая ваши методы хеширования, независимо от того, насколько загадочным вы это сделали». Вот почему так важен bcrypt. С bcrypt не имеет значения, есть ли у кого-то хеши. С быстрым алгоритмом хеширования, таким как SHA1 / MD5, это так.
ceejayoz 01
Я думаю, что некоторые из вас упускают из виду то, что не имеет значения, безопасен ли пароль на 1000%, если все остальные данные являются открытым текстом. Например, если вся база данных скомпрометирована, хакер теперь имеет все номера кредитных карт в открытом виде. Да, многие люди используют один и тот же пароль на разных веб-сайтах, но им уже до тошноты сказали не делать этого, так что это больше не наша проблема. Если сама база данных содержит конфиденциальную информацию и ее компрометация вызывает беспокойство, зашифруйте всю базу данных настолько сильно, насколько вы считаете необходимым.
UncaAlby 05
15

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

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

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

Пользователь @Will говорит:

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

Им не нужно. По-видимому, в случае с LinkedIn они использовали обычную уязвимость SQL-инъекций для получения таблицы БД входа и взломали миллионы паролей в автономном режиме.

Затем он возвращается к сценарию автономной атаки:

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

Нет, 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

LexLythius
источник
Простое хеширование паролей - это нормально, это дело брандмауэра, чтобы обеспечить безопасность сервера .. и под "брандмауэром" я подразумеваю реактивный брандмауэр, который блокирует / замедляет грубую силу (человек может вводить только ТАК быстро) .. это соревнование бессмысленно .. .. «а что, если какой-то хакер взломал и теперь все имеет» (face-desk) - если хакер проник на ваш сервер - все кончено. Пароли взламываются в основном потому, что они чертовски просты или разработчики программного обеспечения чертовски ленивы, чтобы думать как киберпреступники.
@argon Прочтите еще раз. Вся цель хеширования паролей состоит в том, чтобы, когда ваша БД входа в систему скомпрометирована (а это произойдет в какой-то момент), вы не сразу просочите все пароли ваших пользователей, которые чаще всего повторно используются пользователями на разных сайтах - в противном случае простой задержка после ввода сделает. И «игра окончена, если они попали на ваш сервер» - спорный вопрос, потому что им не нужно проникать внутрь вашего сервера. Наиболее распространенной уязвимостью, которую используют хакеры, является SQL-инъекция (см. Случай с Linkedin), а затем они подбирают хэш. Вот почему вам нужны посол и растяжка.
LexLythius
если требования к безопасности действительно настолько высоки, то хранение паролей в другом месте может быть хорошей идеей. Есть много способов защитить ваши данные (и исходный код) - на случай «если / когда» ... .. - но хеширование паролей размером до «миллиарда битов» настолько же безопасно, как: создатель пароля / гостевая система , передача данных и люди, обслуживающие серверное оборудование. ... при этом: я НЕ говорю, что хеширование бесполезно, однако я говорю, что если ваше решение представляет собой просто более сложные хеши, то я боюсь, что оно не будет работать в ближайшем будущем в отношении квантовых компьютеров.
Рекурсивное хеширование увеличивает трудозатраты / затраты на любые попытки взлома. Чем больше итераций, тем сложнее взломать, поэтому можно использовать даже быстрые хеши, такие как SHA256. Итерации должны быть случайными и могут быть опубликованы. password_hash()показывает стоимость в самом хеше.
Виктор Стоддард
@VictorStoddard Да, вы можете развернуть свою собственную схему хеширования и обеспечить настраиваемое растяжение ключа. Но почему вы захотите сделать это вместо использования уже существующих, гораздо более тщательно изученных алгоритмов, которые эксперты создали и сделали доступными именно для этой цели?
LexLythius
13

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

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

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

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


Редактировать при солении:

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

Кайл Розендо
источник
1
Но они оптимизированы по скорости, а это означает, что они позволяют взломать грубой силой.
arbales
6
Факт остается фактом, это для защиты пароля. Используя хэш с солью, а затем добавив ограничение на 3 попытки на веб-сайте, вы существенно замедляете попытки хакеров (даже брутфорс). Используя любое чистое шифрование, у вас теперь есть другая проблема - защита ключа. Если ключ найден, вся ваша база данных будет скомпрометирована (если соль не добавлена). Однако хеши, вы никогда не получите оригинальный пароль из системы, и так должно быть.
Кайл Розендо
1
Как уже отмечалось, проблема серий MD и SHA в том, что они оптимизированы по скорости. Неизбежно, что хэши такого рода становятся все более небезопасными по мере развития вычислений.
Йоханнес Горсет
1
По мере развития вычислительной техники все становится все более плохим / небезопасным и т. Д. К тому времени, как SHA512 и т. Д. Будут взломаны, будут доступны более безопасные алгоритмы. В любом случае, такова природа вычислений.
Кайл Розендо,
1
как хорошо сделать соль на php? есть пример кода? Я полагаю, мне не следует просто выбирать что-то вроде «жирафа»
Тони Старк
4

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

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

Деннис Беллинджер
источник
«Людям, кажется, не хватает того, что если хакер имеет доступ к базе данных, он, вероятно, также имеет доступ к файлу php, в котором хешируется пароль ...» Это неправда. Одна из наиболее распространенных уязвимостей - это SQL-инъекция, которая дает возможность чтения / записи в базу данных, но нулевой доступ к PHP-коду.
ceejayoz 01
Если у вас есть доступ к коду, вы можете изменить и сохранить весь пароль, который пользователь отправляет, в виде обычного текста. Так что нет, если код скомпрометирован, ИГРА ЗАКОНЧЕНА.
magallanes
3

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

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

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

Будет
источник
1

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

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

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

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

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

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

Брэд Дженсен
источник
Даже если я использую более слабое шифрование, практически ни одна система не может выдержать грубую атаку более 1 миллиона попыток в секунду.
magallanes
1
Три неудачных входа в систему, и вы заблокированы. Период, конец рассказа. Даже супер-глупые пароли, такие как «1234», безопасны, если хакер сначала попробует «пароль», «pa $$ word» и «passw0rd» (заблокировать!). То, как пользователь восстанавливает доступ, становится вашей точкой преткновения в плане безопасности, а то, что вы делаете, зависит от размера вашей пользовательской базы. 200 пользователей? Попросите их позвонить за помощью.
UncaAlby 05
Этот ответ не имеет смысла для кого-либо еще, или это только мне?
Wildcard
1

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

введите описание изображения здесь

Бисваджит Кармакар
источник
1

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

Другие разумные варианты, если использование argon2 недоступно, - это scrypt , bcrypt и PBKDF2 . В Википедии есть страницы для этих функций:

MD5, SHA1 и SHA256 - это дайджесты сообщений, а не функции хеширования паролей. Они не подходят для этой цели.

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

Вот предложение для программистов PHP: прочтите FAQ по PHP, затем используйте password_hash () .

Эрван Легран
источник
0

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

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

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

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

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

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 с хешем: 56adb0f19ac0fb50194c312d49b15378

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

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

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

Магеллана
источник
Проблема с использованием MD5 с солью заключается в том, что компьютеры могут создать атаку грубой силы на один пароль на сверхбыстрой скорости. shylor.com/2015/09/14/php-5-5-secure-password-hashing
Шайлор
0

Шифрование 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
Ларс Гросс
источник