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

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

• PHP 5.5 или выше: password_hash() - это хорошее качество и часть ядра PHP.
• Старые версии PHP: библиотека php OpenWall намного лучше, чем большинство пользовательских кодов - используется в WordPress, Drupal и т.д.

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

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

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

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

Смотрите также:

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

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

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

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

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

Начиная с 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_hash(), он генерирует случайную соль и включает ее в выведенный хэш (наряду с затратами и используемым алгоритмом). password_verify() затем считывает этот хэш и определяет используемый метод соли и шифрования и проверяет его на предоставленный пароль открытого текста.

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

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

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

Я просто хочу отметить, что PHP 5.5 включает API хеширования паролей, который предоставляет оболочку вокруг crypt(). Этот API значительно упрощает задачу хэширования, проверки и повторного использования хэшей паролей. Автор также выпустил пакет совместимости (в виде одного файла password.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 для шифрования паролей, убедитесь, что у вас есть следующее реализовано или готово к внедрению.

SERVER

ПОРТЫ

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

ИМЯ_ПОЛЬЗОВАТЕЛЯ

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

ПАРОЛЬ

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

DATABASE

СЕРВЕР

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

USER

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

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

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

ПАРОЛЬ

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

PHP

ПАРОЛЬ

НИКОГДА НЕ сохраняйте пароль в своей БД, вместо этого храните хеш и уникальную соль, я объясню, почему позже.

хэширования

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

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

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

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

посола

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

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

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

Если пользователь создает пароль через интерфейс, это означает, что он должен быть отправлен на сервер. Это открывает проблему безопасности, поскольку это означает, что незашифрованный пароль отправляется на сервер, и если злоумышленник может слушать и получать доступ к тому, что вся ваша безопасность в PHP бесполезна. ВСЕГДА передавайте данные БЕЗОПАСНО, это делается через SSL, но утомляйтесь, даже SSL не безупречен (примером этого является OpenSSL Heartbleed.

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

Наконец, независимо от того, какие меры безопасности вы ничего не берете, это на 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 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));
}
?>

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

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

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

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

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

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

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

ОК в 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 шага вы можете использовать свой собственный алгоритм... но будьте уверены, что вы можете генерировать этот хешированный пароль в будущем когда вам нужно авторизовать пользователя...