Безопасный хэш и соль для паролей PHP

гораздо более короткий и безопасный ответ -не пишите свой собственный механизм паролей вообще используйте испытанный механизм.

• PHP версии 5.5 или выше: функция password_hash() хорошее качество и часть ядра PHP.
• старых версий PHP: phpass библиотека намного лучше, чем большинство пользовательских кодов, используемых в WordPress, Drupal и т. д.

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

быстрая самопроверка: что такое растяжение пароля и сколько итераций вы должны использовать? Если вы не знаете ответа, вы должны использовать password_hash(), поскольку растяжение пароля теперь является критической особенностью механизмов паролей из-за гораздо более быстрых процессоров и использования графические процессоры и FPGAs взломать пароли по ставкам миллиарды догадок в секунду (С ГП).

для например, вы можете взломать все 8-символьные пароли Windows в 6 часов используя 25 графических процессоров, установленных на 5 настольных ПК. Это грубое принуждение, т. е. перечисление и проверка каждый 8-символьный пароль Windows, включая специальные символы, и не является атакой словаря. Это было в 2012 году, с 2018 года вы можете использовать меньше графических процессоров или быстрее взломать с помощью 25 графических процессоров.

есть также много радужных таблиц атак на пароли Windows, которые работают на обычных процессорах и являются очень быстрый. Все это потому, что окна еще не солит и не растягивает его пароли, даже в Windows 10 - не делайте ту же ошибку, что и Microsoft!

Читайте также:

• отличный ответ!--10--> больше о том, почему password_hash() или phpass лучший способ пойти.
• хорошая статья в блог давая recommmended 'факторы' (число итераций) для основных алгоритмы, включая bcrypt, scrypt и PBKDF2.

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

начиная с PHP 5.5, PHP имеет простые, безопасные функции для хэширования и проверки паролей,функция password_hash() и функцию password_verify()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

, когда , Он генерирует случайную соль и включает ее в выводимый хэш (наряду с используемой стоимостью и алгоритмом.) password_verify() затем читает этот хэш и определяет используемый метод salt и шифрования и проверяет его на предоставленный пароль открытого текста.

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

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

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

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

больше объяснения доступно на - http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

недавно у меня было обсуждение, были ли хэши паролей солеными со случайными биты более безопасны, чем тот, который посолен с угадываемым или известным посолит. Давайте посмотрим: если система хранения пароля скомпрометирована как а также система, в которой хранится случайная соль, злоумышленник будет имейте доступ к хэшу, а также соли, поэтому является ли соль случайной или нет, не имеет значения. Злоумышленник может генерировать предварительно вычисленные радужные столы, чтобы взломать хэш. Вот что интересно-это не так тривиально генерировать предварительно вычисленные таблицы. Давайте возьмем пример модели безопасности WPA. Ваш пароль WPA фактически никогда не отправляется Беспроводной точка доступа. Вместо этого он хэшируется с вашим SSID (the имя сети-как Linksys, Dlink и т. д.). Очень хорошее объяснение того, как это работает здесь. Чтобы получить пароль от hash, вы необходимо знать пароль, а также соль (сетевое имя). Церковь Wifi уже имеет предварительно вычисленные хэш-таблицы, которые имеют top 1000 SSIDs и около 1 миллиона паролей. Размер всех таблиц составляет около 40 ГБ. Как вы можете прочитать на своем сайте, кто-то использовал 15 массивов FGPA в течение 3 дней к создайте эти таблицы. Предполагая, что жертва использует SSID как "a387csf3" и пароль как "123456", он будет взломан теми столы? Нет! .. не может. Даже если пароль слабый, таблицы у вас нет хэшей для SSID a387csf3. Это прелесть случайная соль. Это отпугнет крекеров, которые процветают на предварительно вычисленных таблицы. Может ли это остановить решительного хакера? Скорее всего, нет. Но через случайные соли обеспечивают дополнительный уровень защиты. Пока мы здесь ... эта тема, давайте обсудите дополнительное преимущество хранения random соли по отдельной системе. Сценарий #1: хэши паролей сохраняются в системе X и значения соли, используемые для хэширования, хранятся в системе Y. Эти значения соли угадываются или известны (например, имя пользователя) Сценарий#2 : Хэши паролей хранятся в системе X и значениях соли, используемых для хэширование хранится в системе Y. Эти значения соли являются случайными. В случае система X была взломана, как вы можете догадаться, существует огромное преимущество использования случайной соли в отдельной системе (Сценарий № 2) . Злоумышленнику нужно будет угадать значения сложения, чтобы взломать гашиши. Если используется 32-битная соль, 2^32= 4,294,967,296 (около 4,2 миллиард) итерации могут потребоваться для каждого угаданного пароля.

Я просто хочу отметить, что PHP 5.5 включает в себя API хэширования паролей это обеспечивает обертку вокруг crypt(). Этот API значительно упрощает задачу хэширования, проверки и повторного хэширования хэшей паролей. Автор также выпустил пакет обеспечения совместимости (в виде единого пароля.php-файл, который вы просто require использовать), для тех, кто использует PHP 5.3.7 и более поздних версий и хочет использовать это прямо сейчас.

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

API предоставляет четыре функции:

• password_get_info() - возвращает информация о данном хэше
• password_hash() - создает хэш пароля
• password_needs_rehash() - проверяет, соответствует ли данный хэш заданным параметрам. Полезно проверить, соответствует ли хэш вашей текущей методике / схеме затрат, позволяющей при необходимости перефразировать
• password_verify() - проверяет, что пароль соответствует хэшу

на данный момент эти функции принимают константы паролей PASSWORD_BCRYPT и PASSWORD_DEFAULT, которые являются синонимами в момент, разница в том, что PASSWORD_DEFAULT " может измениться в новых версиях PHP, когда поддерживаются новые, более сильные алгоритмы хэширования."Использование PASSWORD_DEFAULT и password_needs_rehash() при входе в систему (и при необходимости повторное хэширование) должно гарантировать, что ваши хэши достаточно устойчивы к атакам грубой силы, практически не работая для вас.

EDIT: я только что понял, что это кратко упоминается в ответе Роберта К. Я оставлю этот ответ здесь, так как я думаю, что он обеспечивает немного более подробную информацию о том, как он работает и простоты использования он обеспечивает для тех, кто не знает безопасности.

Я использую Phpass который является простым классом PHP с одним файлом, который может быть реализован очень легко почти в каждом проекте PHP. См. также H.

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

возвращенный хэш может храниться в базе данных как есть. Польза образца для генерация хэша:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

для проверки пароля можно использовать:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

ПОМНИТЬ

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

сервер

порты

независимо от того, насколько хорошо ваше шифрование, если вы неправильно защищаете сервер, на котором работает PHP и Б.: Все ваши усилия бесполезны. Большинство серверов функционируют относительно одинаково, у них есть порты, назначенные для удаленного доступа к ним через ftp или shell. Убедитесь, что вы изменили порт по умолчанию, из которого когда-либо удаленное соединение у вас активно. Не делая этого, вы фактически заставили злоумышленника сделать еще один шаг в доступе к вашей системе.

имя пользователя

для всего, что хорошо в мире не используйте имя пользователя admin, root или нечто подобное. Также, если вы находитесь в системе на базе unix, не делайте вход в корневую учетную запись доступным, он всегда должен быть только sudo.

пароль

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

база данных

сервер

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

пользователей

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

тогда у вас есть отдельная учетная запись пользователя, которая не хранится нигде на сервере, даже в приложении.

Как всегда не делайте этот корень или что-то подобное.

пароль

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

PHP

пароль

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

хеширования

ОДИН СПОСОБ ХЭШИРОВАНИЯ!!!!!!!, Никогда не хэшируйте пароль таким образом, чтобы его можно было отменить, хэши должны быть в одну сторону, то есть вы не отменяете их и не сравниваете с паролем, вы вместо этого хэшируете введенный пароль таким же образом и сравните два хэша. Это означает, что даже если злоумышленник получает доступ к БД, он не знает, что такое пароль, а только его результирующий хэш. Что означает большую безопасность для ваших пользователей в худшем из возможных сценариев.

есть много хороших функций хэширования там (password_hash, hash, etc...) но вам нужно выбрать хороший алгоритм, чтобы хэш был эффективным. (bcrypt и подобные ему-достойные алгоритмы.)

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

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

соление

пароли всегда должны быть посолены перед хэшированием. Соление добавляет случайную строку к паролю, поэтому аналогичные Пароли не отображаются одинаково в БД. Однако, если соль не уникальна для каждого пользователя (т. е. вы используете жесткий код соль), чем вы в значительной степени сделали свою соль бесполезной. Потому что, как только злоумышленник выясняет один пароль соли у него есть соль для всех из них.

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

ПОЛЬЗОВАТЕЛИ, СОЗДАЮЩИЕ ПАРОЛИ

если пользователь создает пароль через интерфейс, что означает, что он должен быть отправлен на сервер. Это открывает проблему безопасности, потому что это означает, что незашифрованный пароль отправляется на сервер, и если злоумышленник может слушать и получать доступ, что вся ваша безопасность в PHP бесполезна. Всегда передавайте данные безопасно, это делается через SSL, но будьте утомлены, даже SSL не безупречен (порок Heartbleed OpenSSL является примером этого).

Также пользователь создать надежный пароль, это просто и всегда должно быть сделано, пользователь будет благодарен за это, в конце концов.

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

вот класс PHP это создает хэш и соль для пароля легко

http://git.io/mSJqpw

Google говорит, что SHA256 доступен для PHP.

вы определенно должны использовать соль. Я бы рекомендовал использовать случайные байты (и не ограничиваться символами и числами). Как обычно, чем дольше вы выбираете, тем безопаснее, медленнее он становится. 64 байта должны быть в порядке, я думаю.

Я нашел идеальную тему по этому вопросу здесь:https://crackstation.net/hashing-security.htm, я хотел, чтобы вы получили выгоду от этого, вот исходный код, который также обеспечивает предотвращение атаки на основе времени.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

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

Я обычно использую SHA1 и соль с идентификатором пользователя (или какой-либо другой пользовательской информацией), а иногда дополнительно использую постоянную соль (поэтому у меня есть 2 части соли).

SHA1 теперь также считается несколько скомпрометированным, но в гораздо меньшей степени, чем MD5. Используя соль (любую соль), вы предотвращаете использование универсального Радужный таблице чтобы атаковать ваши хеши (некоторые люди даже имели успех, используя Google как своего рода радужную таблицу поиск хэша). Злоумышленник может создать радужную таблицу, используя вашу соль, поэтому вы должны включить пользовательскую соль. Таким образом, они должны будут генерировать радужную таблицу для каждой записи в вашей системе, а не только для всей вашей системы! С таким типом соления даже MD5 прилично безопасен.

в SHA1 и соли должно хватить (в зависимости, естественно, от того, кодируете ли вы что-то для Форт-Нокс или входа в систему для вашего списка покупок) в обозримом будущем. Если SHA1 недостаточно хорош для вас, используйте SHA256 и.

идея соли заключается в том, чтобы выбросить результаты хэширования из равновесия, так сказать. Известно, например, что MD5-хэш пустой строки d41d8cd98f00b204e9800998ecf8427e. Итак, если кто-то с достаточно хорошей памятью увидит этот хэш и знать, что это хэш пустой строки. Но если строка соленая (скажем, со строкой"MY_PERSONAL_SALT"), хэш для "пустой строки" (т. е."MY_PERSONAL_SALT") становится aeac2612626724592271634fb14d3ea6, следовательно, не очевидно, след. Что я пытаюсь сказать, что лучше использовать любой соль, чем не. Поэтому, это не слишком важно, чтобы знать , который соль использовать.

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

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

ok в fitsy нам нужна соль соль должна быть уникальной так пусть генерируют его

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

также Нам нужен хэш Я использую криптография SHA512 это лучшее, и это в php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

Теперь мы можем использовать эти функции для генерации безопасного пароля

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

Теперь нам нужно сохранить в базе данных наше значение переменной $hash_psw и переменную $salt

и для авторизации мы будем использовать те же шаги...

Это лучший способ обезопасить наших клиентов пароли...

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