Я должен хранить хэши для паролей?

Question

Пользовательская система и пароли: я просматривал MD5, и мне интересно, что является нормальной / хорошей практикой для паролей.Прямо сейчас, я думаю, что люди супер зашифровывают пароли и хранят хэши.Если да, то как работает проверка пароля?У меня просто есть входной пароль, снова пройдите процесс шифрования и затем проверьте хеш с сохраненным, правильно?

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

Редактировать: В пользовательской системе, кроме паролей, что еще следует зашифровать в качестве хорошей практики?Они шифруют имена пользователей или что-то еще?

2nd Edit: Что такое односторонний хэш?Я имею в виду, технически, я не могу перепроектировать мой исходный код?Может быть, это плохой вопрос, потому что я мало знаю об одностороннем хешировании.

Answer 1

Сначала вы создаете соль.

Примеры примечаний написаны на PHP

// Setup a salt, this isn't "random" but it doesn't really have to be
$salt = sha1(microtime());

Затем введите пароль

// First we hash the password, then XOR it with the salt hashing the result
$hash = sha1(sha1($password) ^ $salt);

Store$hash и $salt в базе данных.

Когда пользователь вводит пароль, сравнивают его с хешем

if(sha1(sha1($entered_password) ^ $salt) == $hash)
    // Correct password

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

Редактировать: кроме паролей, в пользовательской системе, что еще должно быть зашифровано в качестве хорошей практики?Они шифруют имена пользователей или что-то еще?

Пароли не шифруются, они хешируются.Представьте себе хэш ( очень упрощенный) как нечто, которое принимает число и умножает его на десять.Скажем, я хочу хешировать число 30.Я бы сказал 30*10 и получил бы 300 в качестве моего "хеша" для 30.Обратите внимание, что вы не можете получить 30 из 300, не зная, как работает хеш-функция.

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

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

I Предположим, вы можете применить аналогичную комбинацию соли / хэша к имени пользователя, но тогда у вас есть подводные камни.Что если вы хотите использовать это имя пользователя где-то в вашем коде?Что если вы хотите проверить, чтобы убедиться, что он уникален для таблицы?

2nd Edit: Что такое односторонний хэш?Я имею в виду, технически, я не могу перепроектировать мой исходный код?Возможно, это плохой вопрос, потому что я мало что знаю об одностороннем хешировании.

См. Выше ( или нажмите здесь ).Односторонний хеш - это просто.Одностороннее картирование.A => B и больше ничего.B !=> A и A не может быть ничем, кроме B.

Кто-то упомянул о выполнении операции XOR.Хотя я чувствую, что производительность в значительной степени незначительна, я провел быстрый тест.

function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}

Теперь запустите

$start_time = $this->microtime_float();

for($i = 0; $i < 100000; $i++)
{
 $sha = sha1(sha1(microtime()) . sha1(microtime()));
}

$end_time = $this->microtime_float();

echo "1000 in " . ($end_time-$start_time) . " for CAT\n";


$start_time = $this->microtime_float();

for($i = 0; $i < 100000; $i++)
{
 $sha = sha1(sha1(microtime()) ^ sha1(microtime()));
}

$end_time = $this->microtime_float();

echo "1000 in " . ($end_time-$start_time) . " for XOR\n";

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

1000 in 0.468002796173 XOR
1000 in 0.465842008591 XOR
1000 in 0.466115951538 XOR
1000 in 0.498080968857 CAT
1000 in 0.506876945496 CAT
1000 in 0.500174045563 CAT

Answer 2

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

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

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

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

Один из способов сделать жизнь злоумышленника труднее - сделать процесс хеширования вычислительно интенсивным (например,5000 раундов sha1 (соль + sha1 (соль + sha1 (соль + пароль)))).Вы должны сделать это только для каждой попытки входа в систему.Атакующий должен сделать это для каждой комбинации соли и пароля, которую он хочет угадать.Вы должны решить, стоит ли это что-то для ваших нужд.Ответ, вероятно, нет.

Редактировать: Помимо паролей, в пользовательской системе, что еще должно быть зашифровано в качестве хорошей практики?Они зашифровывают имена пользователей или что-то еще?

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

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

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

2nd Edit:Что такое односторонний хэш?Я имею в виду, технически, я не могу перепроектировать мой исходный код?Возможно, это плохой вопрос, потому что я мало знаю об одностороннем хешировании.

Хеш - это метод для систематического отбрасывания информации.Допустим, вы начинаете со строки и производите "srflcdos", отбрасывая все, кроме каждого четвертого символа.Текст, который я «хешировал», мог бы быть: «Копье, если рыба лежит спокойно. Не сидите!», Или это может быть: «Суперкалифрагистическое явление».Невозможно доказать в любом случае.

Криптографические хеши делают намного больше микширования и других преобразований наряду с выбрасыванием, чтобы сделать их более безопасными для небольших объемов входных данных и избежать утечки любых фактов ввсе о входных данных.В качестве примера небезопасного хэша, если вы знаете, что всякий раз, когда вход содержит букву A, 12-битный хэш равен 1, то вы предоставляете информацию об исходном тексте, и результат не является криптографически безопасным хешем.

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

Answer 3

Стандартная практика с паролями - нигде не хранить оригинальный пароль. Unix-пароли использовались для шифрования с помощью «crypt», который использовал бы случайную соль. Сама соль хранилась в первых двух символах зашифрованного пароля. Когда пользователь вводит свой пароль, система использует два символа зашифрованного пароля в качестве соли для шифрования введенного пароля, и если зашифрованный результат совпадает с сохраненным зашифрованным паролем, это совпадение. Подобные вещи можно сделать с паролями MD5.

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

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

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

Answer 4

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

Answer 5

Избегайте использования MD5-хэшей, если можете, так как это довольно некорректно.

Альтернативами являются SHA1 или даже лучше SHA256 или SHA512.

Answer 6

Я настоятельно не рекомендую использовать MD5. Для получения дополнительной информации прочитайте раздел Википедия [MD5] Безопасность . Вместо этого я рекомендую использовать алгоритм хеширования SHA-1.

Answer 7

2nd Edit: Что такое односторонний хэш? Я имею в виду, технически, я не могу перепроектировать мой исходный код? Может быть, это плохой вопрос, потому что я мало знаю об одностороннем хешировании.

«Один путь» в криптографии означает «трудно перевернуть». Проще говоря, это означает, что если я дам вам sha1(password), вы не сможете найти password в любое разумное количество времени.

Это называется в одностороннем порядке . Многие люди путают это с другим определением одностороннего (из математики) значения «не один к одному» , которое здесь не применимо.

Answer 8

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

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

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

Answer 9

Существует множество вариантов этой темы.

Для получения более подробной информации, пожалуйста, прочитайте это: http://en.wikipedia.org/wiki/Digest_access_authentication.

Затем прочитайте это: http://tools.ietf.org/html/rfc2617

Как правило: Выхранить только дайджест.Никогда не пароль.

После RFC2617 вы должны сохранить дайджест имени пользователя, области и пароля.

Клиент («агент») принимает имя пользователя, пароль, область и т. Д. И создает дайджест, который он отправляет на ваш сервер.

Ваш сервер, основываясь на имени пользователя, ищетэто версия дайджеста.

Если их дайджест == дайджест сохранен на сервере, вы соглашаетесь с паролем (и всем остальным).

Если их дайджест! = дайджест сохранен всервер, вы не согласны с паролем (или что-то еще).Это означает, что они не правильно поняли сферу или имя пользователя, или не поняли одноразовый номер, или что-то еще пошло не так.Им нельзя доверять.

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

Answer 10

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