Это безопасный способ хранения моих паролей? - PullRequest
Новая
       24

Это безопасный способ хранения моих паролей?

0 голосов
/ 04 ноября 2011

Я прочитал несколько различных руководств / руководств по этой теме и обнаружил следующее:

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

Вот мой код: 

<?php

    $static_salt = ""; // Removed value for obvious reasons

    $dynamic_salt_choice = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    $dynamic_salt_length = 40;

    $dynamic_salt = "";

    $dynamic_salt_max = strlen($dynamic_salt_choice)-1;

    for ($i = 0; $i < $dynamic_salt_length; $i++) {

        $dynamic_salt .= substr($dynamic_salt_choice, rand(0, $dynamic_salt_max), 1);

    }

    $password_length = length($password);
    $split_at = $password_length / 2;
    $password_array = str_split($password, $split_at);

    $password = $password_array[0] . $static_salt . $password_array[1];

    $password_hash = hash_hmac('sha512', $password, $dynamic_salt);

?>

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

Затем мы хешируем пароль с помощью sha12 вместе с динамической солью.

Мой вопрос к вам: это более безопасно или так же безопасно, как два метода, с которыми я связан? Или я делаю это более уязвимым, путая вещи таким образом?

Я также считаю, что $password_hash хранится в cookie вместе с cookie для имени пользователя для автоматического входа - это большое нет-нет? Если да, то как веб-сайты запоминают вас с помощью файлов cookie безопасным способом?

Ответы [ 4 ]

2 голосов
/ 04 ноября 2011

Я пытаюсь повысить уровень безопасности с моими сайтами

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

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

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

Мой вопрос к вам: это более безопасно или так же безопасно, как два метода, с которыми я связан? Или я делаю это более уязвимым, путая вещи таким образом?

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

Я также полагаю, что сохранение $ password_hash в cookie вместе с cookie для имени пользователя для автоматического входа - это большое нет-нет?

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

1 голос
/ 04 ноября 2011

Предполагая, что $dynamic_salt хранится вместе с окончательным $password_hash - поскольку хеш не будет тестируемым без него - эта схема довольно слабая.Использование соли защищает от радужных таблиц, но не повторяющийся HMAC оставляет эту схему слабой для атак методом перебора.(Длина соли вас не устраивает, так как это известная константа в хэш-вводе. Поместить ее в середине исходного пароля тоже не очень помогает.)

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

$salt = uniqid();
$password_hash = hash_hmac('sha512', $password, $salt);

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

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

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

1 голос
/ 04 ноября 2011

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

Что касаетсяautologin, вы должны хранить (в cookie) случайный токен, который соответствует записи в базе данных, указывающей на учетную запись пользователя.Когда пользователь меняет свой пароль, удалите все эти записи для этого пользователя.При генерации этого токена rand() недостаточно хорош - вам нужно secure , unguessable random number.К сожалению, в PHP на самом деле нет встроенной функции для безопасного случайных чисел - mt_rand() примерно настолько близок, насколько это возможно, но я лично буду напрямую читать случайные байты из /dev/urandom в системе Linux и использовать это для генерациимой одноразовый номер.

0 голосов
/ 04 ноября 2011

Соли можно использовать, но у них есть свои ограничения.Другой способ - использовать bcrypt. Более подробную информацию можно найти по адресу http://www.openwall.com/phpass/

И я думаю, что этой статьи более чем достаточно Безопасный хеш и соль для паролей PHP

...