Я делаю логин 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. Хеши, о которых вы упоминаете, оптимизированы для быстрого и легкого использования на оборудовании, и поэтому взломать их имеют одинаковые качества. Если у вас нет другого выбора, по крайней мере, обязательно используйте длинную соль и повторный хеш несколько раз.
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://
NUL.(Доказательство концепции для обоих оговорок.)
У вас может возникнуть соблазн разрешить первое предостережение предварительное хеширование ваших паролей перед запуском их через bcrypt, но это может привести к вашему приложению для запуска вперёд во второй.
Вместо того, чтобы писать свою собственную схему, используйте существующую библиотеку, написанную и/или оцененную экспертами по безопасности.
Zend\Crypt (часть Zend Framework) предлагает BcryptShaPasswordLock похож на BcryptSha, но также шифрует хэширование bcrypt с помощью аутентифицированная библиотека шифрования.TL; DR - Использовать bcrypt.
Я думаю, что использование md5 или sha256 или любой хеш, оптимизированный для скорости, отлично подходит, и мне очень любопытно слышать любые опровержения, которые могут иметь другие пользователи. Вот мои причины.
Если вы разрешаете пользователям использовать слабые пароли, такие как Бог, любовь, война, мир, то независимо от того, какое шифрование вы по-прежнему позволяете пользователю вводить пароль, а не хэш, и эти пароли часто используются сначала, таким образом, это НЕ будет иметь какое-либо отношение к шифрованию.
Если вы не используете SSL или не имеете сертификата, тогда злоумышленники, прослушивающие трафик, смогут вытащить пароль, а любые попытки шифрования с помощью javascript или тому подобного будут на стороне клиента и легко взломать и преодолеть. Опять же, это НЕ будет иметь какое-либо отношение к шифрованию данных на стороне сервера.
Атаки грубой силы будут использовать слабые пароли и снова, потому что вы разрешаете пользователю вводить данные, если у вас нет ограничения на вход 3 или даже немного больше, чем проблема снова будет НЕ имеют какое-либо отношение к шифрованию данных.
Если ваша база данных становится скомпрометированной, то, скорее всего, все было скомпрометировано, включая ваши методы хеширования, независимо от того, насколько вы загадочны. Опять же, это может быть недовольная атака сотрудника XSS или SQL-инъекция или другая атака, которая не имеет никакого отношения к вашему шифрованию паролей.
Я действительно считаю, что вы все еще шифруете, но единственное, что я вижу, это шифрование, это предотвращение того, что люди уже имеют или каким-то образом получили доступ к базе данных, просто прочитав вслух пароль. Если в базе данных кто-то несанкционирован, у вас есть больше проблем, чтобы беспокоиться о том, почему Sony взяла их, потому что они считали, что зашифрованный пароль защищает все, включая номера кредитных карт, все, что он делает, защищает это одно поле.
Единственное чистое преимущество, которое я могу видеть для сложных шифровок паролей в базе данных, - это задержка сотрудников или других людей, которые имеют доступ к базе данных, просто просматривая пароли. Поэтому, если это небольшой проект или что-то, что я не буду беспокоиться о безопасности на стороне сервера, я больше беспокоюсь о том, чтобы обеспечить что-либо, что клиент может отправить на сервер, например, SQL-инъекция, атаки XSS или множество других способов, которыми вы могут быть скомпрометированы. Если кто-то не согласен с этим, я с нетерпением жду возможности прочитать способ, которым супершифрованный пароль является обязательным с клиентской стороны.
Причина, по которой я хотел попытаться понять это, заключается в том, что слишком часто люди считают, что зашифрованный пароль означает, что им не нужно беспокоиться о том, что он скомпрометирован, и они перестают беспокоиться о безопасности веб-сайта.
Как отметил Йоханнес Горсет, сообщение Томаса Птачека из 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
Используйте SHA256. Это не идеально, так как SHA512 идеально подходит для быстрого хэша, но из вариантов, его определенного выбора. В соответствии с любой технологией хэширования, обязательно добавьте хэш для дополнительной безопасности.
Как добавленное примечание, FRKT, пожалуйста, покажите мне, где кто-то может легко взломать хвойный SHA256? Мне действительно очень интересно это видеть.
Двигаясь вперед, используйте bcrypt как затвердевший хеш. Более подробную информацию можно найти здесь.
Изменить на соле:
Используйте случайное число или случайный поток байтов и т.д. Вы можете использовать уникальное поле записи в своей базе данных как соль тоже, таким образом, соль различна для каждого пользователя.
Кажется, что люди не видят, что, если у хакера есть доступ к базе данных, он, вероятно, также имеет доступ к файлу php, который хэширует пароль и, скорее всего, просто изменит это, чтобы отправить ему все успешные пароли паролей имени пользователя. Если у него нет доступа к веб-каталогу, он всегда может просто выбрать хэш пароля и записать его в базу данных. Другими словами, алгоритм хеширования не имеет особого значения, как системная безопасность, и ограничение попыток входа в систему также, если вы не используете SSL, тогда злоумышленник может просто прослушать соединение, чтобы получить информацию. Если вам не нужен алгоритм для вычисления времени (для ваших собственных целей), то SHA-256 или SHA-512 с определенной пользователем солью должно быть достаточно.
В качестве дополнительной меры безопасности настройте script (bash, batch, python и т.д.) или программу и дайте ему неясное имя и попросите его проверить и посмотреть, изменился ли login.php(проверьте дату/время печать) и отправьте вам электронное письмо, если оно есть. Также, вероятно, следует регистрировать все попытки входа в систему с правами администратора и регистрировать все неудавшиеся попытки входа в базу данных и отправки журналов по электронной почте.
Все говорят об этом, так как их можно взломать через Интернет. Как уже говорилось, ограничение попыток делает невозможным взломать пароль через Интернет и не имеет ничего общего с хешем.
Соль является обязательной, но сложность или несколько солей даже не имеет значения. Любая соль сама по себе останавливает злоумышленника от использования готового радужного стола. Уникальная соль для каждого пользователя останавливает злоумышленника от создания новой таблицы радуги для использования против всей вашей базы пользователей.
Безопасность действительно вступает в игру, когда вся база данных скомпрометирована, и хакер может выполнить 100 миллионов попыток пароля в секунду против хеша md5. SHA512 примерно в 10 000 раз медленнее. Сложный пароль с сегодняшней властью может по-прежнему занять 100 лет, чтобы выполнить брутфорс с помощью md5 и потребовал бы в 10 000 раз больше с SHA512. Соли не останавливают грубую силу вообще, поскольку они всегда должны быть известны, что, если злоумышленник загрузил вашу базу данных, он, вероятно, был в вашей системе.
MD5 плохо из-за проблем с столкновением - два разных пароля могут генерировать один и тот же md-5.
Sha-1 будет достаточно безопасным для этого. Причина, по которой вы храните засоленную версию пароля sha-1, заключается в том, что вы не храните пользовательский apassword в файле, который они могут использовать с серверами других пользователей. В противном случае, какая разница?
Если хакер крадет всю вашу незашифрованную базу данных, как только, единственное, что сделал хэшированный соленый пароль, не позволяет ему олицетворять пользователя для будущих подписей - у хакера уже есть данные.
Что хорошего делает злоумышленник иметь хешированное значение, если ваши пользовательские входы - это простой пароль?
И даже если бы хакер с будущими технологиями мог генерировать миллион ша-1 ключей в секунду для атаки грубой силы, мог бы ваш сервер обрабатывать миллион логинов в секунду, чтобы хакер мог проверить свои ключи? Это, если вы позволяете хакеру пытаться подключиться к соленой sha-1 вместо пароля, как обычный вход в систему.
Лучше всего ограничить неудачные попытки входа в систему на какое-то разумное число - например, 25, а затем вывести пользователя на минутку или два. И если кумулятивные неудачные попытки входа в систему достигают 250 в течение 24 часов, отключите доступ к учетной записи и отправьте по электронной почте владельцу.
Используйте argon2i. Функция хэширования паролей argon2 выиграла конкурс хэширования паролей.
Другие разумные варианты, если использование argon2 недоступно, это scrypt, bcrypt и PBKDF2. В Википедии есть страницы для этих функций:
MD5, SHA1 и SHA256 - это дайджесты сообщений, а не функции хеширования паролей. Они не подходят для этой цели.
Переключение с MD5 на SHA1 или SHA512 не сильно улучшит безопасность конструкции. Вычисление хэша SHA256 или SHA512 выполняется очень быстро. Злоумышленник с обычным оборудованием может попробовать десятки миллионов (с одним процессором) или даже миллиарды (с одним графическим процессором) хэшей в секунду. Хорошие функции хеширования паролей включают рабочий фактор, замедляющий атаки по словарю.
Вот предложение для программистов PHP: прочитайте FAQ по PHP, затем используйте password_hash().
Вот сравнение между MD5 и SHA1. Вы можете получить четкое представление о том, какой из них лучше.
Предположим следующее: хакеры украдут нашу базу данных, включая пользователей и пароль (зашифрованные). И хакеры создали фальшивую учетную запись с паролем, который они знают.
MD5 слаб, потому что его короткое и популярное и практически каждое хеш-генерация без пароля слаба в словарной атаке. Но..
Итак, скажем, что мы все еще используем MD5 с SALT. Хакеры не знают СОЛЬ, но они знают пароль конкретного пользователя. Поэтому они могут проверить: 12345, где 12345 - пароль для получения информации и????? это соль. Хакеры рано или поздно могут угадать СОЛЬ.
Однако, если мы использовали MD5 + SALT, и мы применили MD5, тогда нет способа восстановить информацию. Однако, повторяю, MD5 по-прежнему короток.
Например, скажем, что мой пароль: 12345. СОЛЬ - BILLCLINTON
md5: 827ccb0eea8a706c4c34a16891f84e7b
md5 с хешем: 56adb0f19ac0fb50194c312d49b15378
mD5 с хешем по md5: 28a03c0bc950decdd9ee362907d1798a Я попытался использовать эти онлайн-службы, и я не нашел ни одного, кто мог бы взломать его. И его единственный MD5! (может быть, так как сегодня это будет треск, потому что я создал md5 в Интернете)
Если вы хотите переполнить, тогда SHA256 более чем достаточно, если его применить с солью и дважды.
TL;DR MD5 (HASH + MD5 (пароль)) = ok, но короткий, 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