Риски и проблемы хеширования паролей

В прошлой статье хеширование паролей обсуждалось как способ безопасного хранения учетных данных пользователя в приложении. Безопасность — это всегда очень спорная тема, во многом похожая на политику и религию, где существует множество точек зрения, и «идеальное решение» для кого-то не то же самое, что и для других. На мой взгляд, нарушение мер безопасности приложения — это вопрос времени. С ростом мощности и сложности компьютеров с каждым днем ​​современные безопасные приложения не будут такими уж безопасными завтра.

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

• Односторонняя функция : вывод не может быть обращен с помощью эффективного алгоритма.
• Сопоставляет данные переменной длины с данными фиксированной длины : это означает, что пространство входного сообщения может быть «бесконечным», а пространство вывода — нет. Это означает, что 2 или более входных сообщения могут иметь одинаковый хэш. Чем меньше выходное пространство, тем больше вероятность «столкновения» между двумя входными сообщениями.

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

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

Почему простое хеширование небезопасно для хранения паролей

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

демонстрация

Вот краткое видео о том, как такой инструмент, как sqlmap, может взломать пароли с помощью инъекции sql путем подбора хешей md5

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

• http://www.hash-database.net/
• https://isc.sans.edu/tools/hashsearch.html
• http://md5online.net/
• https://crackstation.net/

Мы также должны учитывать, что, поскольку 2 или более идентичных пароля действительно будут иметь одинаковое значение хеша, взлом одного хеша автоматически даст вам пароли каждого отдельного пользователя, который использовал один и тот же. Просто для ясности, скажем, у вас есть тысячи пользователей, весьма вероятно, что значительное количество из них будет использовать (если политики паролей не применяются) позорный пароль «123456». Хеш-значение md5 для этого пароля равно ‘e10adc3949ba59abbe56e057f20f883e’, поэтому, когда вы взломаете этот хеш (если вам даже придется) и выполните поиск всех пользователей, которые имеют это значение в своем поле пароля, вы будете знать, что каждый из них использовал пароль «123456».

Почему соленые хэши небезопасны для хранения паролей

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

Основная функция пароля / соли определяется как:

f(password, salt) = hash(password + salt)

Чтобы смягчить атаку методом «грубой силы», соль должна быть длиной до 64 символов, однако для дальнейшей аутентификации пользователя соль должна храниться в виде простого текста внутри базы данных, поэтому:

 if (hash([provided password] + [stored salt]) == [stored hash]) then user is authenticated

Поскольку у каждого пользователя будет совершенно другая соль, это также позволяет избежать проблемы с простыми хэшами, где мы могли бы легко определить, используют ли 2 или более пользователей один и тот же пароль; теперь хэши будут другими. Мы также больше не можем напрямую брать хэш пароля и пытаться его найти. Кроме того, с длинной солью атака грубой силой маловероятна. Но если злоумышленник получит доступ к этой соли с помощью SQL-инъекции или прямого доступа к базе данных, вероятна атака методом перебора или словаря, особенно если ваши пользователи используют общие пароли (опять же, например, «123456»):

 Generate some string or get entry from dictionary
Concatenate with salt
Apply hash algorithm
If generated hash == hash in database then Bingo
else continue iterating

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

 <?php

function getRandomBytes ($byteLength)
{
    /*
     * Checks if openssl_random_pseudo_bytes is available 
     */
    if (function_exists('openssl_random_pseudo_bytes')) {
        $randomBytes = openssl_random_pseudo_bytes($byteLength, $cryptoStrong);
        if ($cryptoStrong)
            return $randomBytes;
    } 

    /*
     * if openssl_random_pseudo_bytes is not available or its result is not
     * strong, fallback to a less secure RNG
     */
    $hash = '';
    $randomBytes = '';

    /*
     * On linux/unix systems, /dev/urandom is an excellent entropy source, use
     * it to seed initial value of $hash
     */
    if (file_exists('/dev/urandom')) {
        $fp = fopen('/dev/urandom', 'rb');
        if ($fp) {
            if (function_exists('stream_set_read_buffer')) {
                stream_set_read_buffer($fp, 0);
            }
            $hash = fread($fp, $byteLength);
            fclose($fp);
        }
    }

    /*
     * Use the less secure mt_rand() function, but never rand()!
     */
    for ($i = 0; $i < $byteLength; $i ++) {
        $hash = hash('sha256', $hash . mt_rand());
        $char = mt_rand(0, 62);
        $randomBytes .= chr(hexdec($hash[$char] . $hash[$char + 1]));
    }
    return $randomBytes;
}

 <?php

/*
 * PHP PBKDF2 implementation The number of rounds can be increased to keep ahead
 * of improvements in CPU/GPU performance. You should use a different salt for
 * each password (it's safe to store it alongside your generated password This
 * function is slow; that's intentional! For more information see: -
 * http://en.wikipedia.org/wiki/PBKDF2 - http://www.ietf.org/rfc/rfc2898.txt
 */
function pbkdf2 ($password, $salt, $rounds = 15000, $keyLength = 32, 
        $hashAlgorithm = 'sha256', $start = 0)
{
    // Key blocks to compute
    $keyBlocks = $start + $keyLength;

    // Derived key
    $derivedKey = '';

    // Create key
    for ($block = 1; $block <= $keyBlocks; $block ++) {
        // Initial hash for this block
        $iteratedBlock = $hash = hash_hmac($hashAlgorithm, 
                $salt . pack('N', $block), $password, true);

        // Perform block iterations
        for ($i = 1; $i < $rounds; $i ++) {
            // XOR each iteration
            $iteratedBlock ^= ($hash = hash_hmac($hashAlgorithm, $hash, 
                    $password, true));
        }

        // Append iterated block
        $derivedKey .= $iteratedBlock;
    }

    // Return derived key of correct length
    return base64_encode(substr($derivedKey, $start, $keyLength));
}

 <?php
//bcrypt is implemented in php's crypt() function
$hash = crypt($pasword, '$2a$' . $cost . '$' . $salt);