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

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

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

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

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

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

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

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

См. также:

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Я только что понял, что это кратко упоминается в ответе Роберта К. Я оставлю этот ответ здесь, поскольку я думаю, что он предоставляет немного больше информации о том, как он работает, и о простоте использования, которую он обеспечивает для тех, кто не знает безопасности.

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

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

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

ПАРОЛЬ

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

БАЗА ДАННЫХ

СЕРВЕР

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

ПОЛЬЗОВАТЕЛЬ

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

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

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

ПАРОЛЬ

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

PHP

ПАРОЛЬ

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

ХЭШИНГ

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

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

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

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

СОЛЕНИЕ

Перед хешированием пароли всегда следует солить. 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'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));
}
?>

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

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

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

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

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

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

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

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