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

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

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

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

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

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

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

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

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

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

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

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

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

Recently I had a discussion whether password hashes salted with random bits are more secure than the one salted with guessable or known salts. Let’s see: If the system storing password is compromised as well as the system which stores the random salt, the attacker will have access to hash as well as salt, so whether the salt is random or not, doesn’t matter. The attacker will can generate pre-computed rainbow tables to crack the hash. Here comes the interesting part- it is not so trivial to generate pre-computed tables. Let us take example of WPA security model. Your WPA password is actually never sent to Wireless Access Point. Instead, it is hashed with your SSID (the network name- like Linksys, Dlink etc). A very good explanation of how this works is here. In order to retrieve password from hash, you will need to know the password as well as salt (network name). Church of Wifi has already pre-computed hash tables which has top 1000 SSIDs and about 1 million passwords. The size is of all tables is about 40 GB. As you can read on their site, someone used 15 FGPA arrays for 3 days to generate these tables. Assuming victim is using the SSID as “a387csf3″ and password as “123456″, will it be cracked by those tables? No! .. it cannot. Even if the password is weak, the tables don’t have hashes for SSID a387csf3. This is the beauty of having random salt. It will deter crackers who thrive upon pre-computed tables. Can it stop a determined hacker? Probably not. But using random salts does provide additional layer of defense. While we are on this topic, let us discuss additional advantage of storing random salts on a separate system. Scenario #1 : Password hashes are stored on system X and salt values used for hashing are stored on system Y. These salt values are guessable or known (e.g. username) Scenario#2 : Password hashes are stored on system X and salt values used for hashing are stored on system Y. These salt values are random. In case system X has been compromised, as you can guess, there is a huge advantage of using random salt on a separate system (Scenario #2) . The attacker will need to guess addition values to be able to crack hashes. If a 32 bit salt is used, 2^32= 4,294,967,296 (about 4.2 billion) iterations will can be required for each password guessed.

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

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

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

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

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

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

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

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

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

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

Я нашел идеальную тему по этому поводу здесь: 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));
}
?>

Начиная с 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() подхватывает его.

ОК в припадке нам нужна соль соль должна быть уникальной так позволь сгенерировать это

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