Я, как предполагается, храню хеши для паролей?
Пользовательская Система и Пароли: Я просматривал материал MD5, и я задаюсь вопросом, какова нормальная/хорошая практика для паролей. Прямо сейчас я думаю, что люди супер шифруют пароли и хранят хеши. Если так, как проверка пароля работает? У меня просто есть входной пароль, проходят процесс шифрования снова и затем проверяют хеш с сохраненным, корректным?
Этот вопрос может противоречить вышеупомянутому, но моя соль должна когда-либо быть случайным образом сгенерированным значением? Если так, когда это может быть полезно?
Править: Кроме паролей, в пользовательской системе, что еще должно быть зашифровано как хорошая практика? Они шифруют имена пользователей или что-либо еще?
2-е Редактирование: Что такое односторонний хэш? Я имею в виду, технически, разве я не могу перепроектировать свой исходный код? Возможно, это - плохой вопрос, потому что я не знаю много об одностороннем хешировании.
11 ответов
Сначала вы создаете соль.
Примеры заметок написаны на 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);
Сохраните $ hash и $ salt в базе данных.
Когда пользователь вводит пароль, сравните его с хешем
if(sha1(sha1($entered_password) ^ $salt) == $hash)
// Correct password
Никогда не храните пароли в обратимом формате. Также я бы не советовал использовать MD5 в качестве хеша.
Изменить: кроме паролей, у пользователя система, что еще нужно зашифровать как хорошая практика? Они шифруют имена пользователей или что-то еще?
Пароли не шифруются, они хешируются. Представьте себе хэш ( очень упрощенный) как нечто, умножающее число на десять. Скажем, я хочу хешировать число 30 . Я бы сказал 30 * 10 и получил 300 в качестве моего «хеша» для 30 . Обратите внимание, что вы не можете получить 30 из 300 , не зная, как работает хеш-функция.
Это очень упрощенный «хеш», и если вы знаете, что он всегда умножается на десять, вы можете легко его отменить. Теперь взглянем на хэш-функцию SHA1 . Это намного сложнее. Это не может быть просто отменено.
Вы обнаружите, что редко что-либо, кроме пароля, хешируется и ничего не зашифровывается. Объем накладных расходов, связанных с шифрованием базы данных, будет огромным.
Я полагаю , что вы можете применить аналогичный шаблон соли / хеширования к имени пользователя, но тогда у вас есть подводные камни.Что, если вы хотите использовать это имя пользователя где-нибудь в своем коде? Что, если вы хотите убедиться, что он уникален для таблицы?
2-е изменение: Что такое односторонний хэш? я значит, технически я не могу отменить разработать мой исходный код? Может это плохой вопрос, потому что я не знаю много об одностороннем хешировании.
См. Выше ( или щелкните здесь ). Односторонний хэш - это именно то, что вам нужно. Одностороннее отображение. 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
Никогда не храните пароль обратимым способом, всегда используйте односторонний хэш. Проверка работает путем хеширования введенного пароля и сравнения двух хешей друг с другом.
По возможности избегайте использования хэшей MD5, так как это довольно некорректно.
Альтернативы - SHA1, а лучше - SHA256 или SHA512.
Я настоятельно не рекомендую использовать MD5. Для получения дополнительной информации прочтите раздел Википедии [MD5] Безопасность . Вместо этого я рекомендую использовать алгоритм хеширования SHA-1.
Стандартная практика с паролями - нигде не хранить исходный пароль. Пароли Unix обычно зашифровывались с помощью «крипты», в которой использовалась случайная соль. Сама соль хранилась в первых двух символах зашифрованного пароля. Когда пользователь вводил свой пароль, система использовала два символа зашифрованного пароля в качестве соли для шифрования введенного пароля, и если зашифрованный результат был таким же, как сохраненный зашифрованный пароль, это было совпадение. То же самое можно сделать и с паролями MD5.
Вот почему хорошие сайты никогда не отправят вам ваш пароль по электронной почте, а вместо этого сбросят ваш пароль на одноразовое значение - потому что они не знают вашего пароля.
Чтобы немного расширить это: хеш MD5 - это односторонняя функция - если вы хешируете одно и то же значение, вы получаете тот же хеш, но вы не можете взять хеш и каким-то образом превратить его в значение. Существует небольшая, но конечная вероятность того, что два значения дадут один и тот же хэш (вероятность тем выше, чем больше исходные строки или меньше хеш), но они выбирают алгоритмы хеширования, чтобы повысить вероятность того, что люди выберут две строки. поскольку пароли будут иметь одно и то же значение, почти бесконечно малое. Вы можете думать об одностороннем хешировании как о мясорубке: вы можете посмотреть на мясо, которое выходит из мясорубки, и увидеть, корова это, баранина или свинья, но вы не можете передать его другим путем и вернуть корову.
Из-за этого никто не может восстановить ваш пароль, потому что он никогда не хранится нигде в их системе, только его хэш.
На эту тему существует множество вариаций.
Для получения достоверной информации прочтите это: http://en.wikipedia.org/wiki/Digest_access_authentication .
Тогда прочтите это: http://tools.ietf.org/html/rfc2617
Обычно: вы храните только дайджест. Никогда не пароль.
Согласно RFC2617, вы должны сохранить дайджест имени пользователя, области и пароля.
Клиент («агент») берет имя пользователя, пароль, область и т. Д. И создает дайджест, который он отправляет на ваш сервер.
Ваш сервер, основываясь на имени пользователя, ищет свою версию дайджеста.
Если их дайджест == дайджест, сохраненный на сервере, вы соглашаетесь на пароль (и все остальное).
Если их дайджест! = Дайджест, сохраненный на сервере, вы не согласны с паролем (или чем-то еще). Это означает, что они неправильно указали область или имя пользователя, или они неправильно поняли одноразовый номер, или что-то еще пошло не так. Им нельзя доверять.
Полный RFC2617 включает другие данные для вычисления дайджеста другого материала и дайджест пароля, чтобы быть абсолютно уверенным, что клиент отвечает.
Этот вопрос может противоречить выше, но если моя соль когда-нибудь станет случайно сгенерированное значение? Если да, то когда может быть это полезно?
Соли должны быть случайными. Их единственное назначение - сделать атаки методом перебора хешей намного дороже. Что-то, называемое «радужной таблицей» (это причудливое название для базы данных, где кто-то заранее хеширует целую кучу возможных паролей и позволяет вам искать пароли, если вы знаете хеш), позволяет брать несоленые хэши паролей и превращать их в пароли во многих случаях за доли секунды.
Соль умеренного размера может экспоненциально увеличить сложность предварительно вычисленной атаки методом перебора. Для каждого бита случайных данных в вашей соли вы удваиваете время, необходимое для предварительно вычисленной атаки методом грубой силы. Для каждого уникального значения соли в вашей базе данных злоумышленник должен начинать заново при атаке пароля, защищенного этой солью.
Если бы у вас был 1 КБ случайной соли для каждого пароля пользователя, заранее вычисленные хэши были бы просто невозможны. Однако вы не повлияете на количество времени, которое потребуется для перебора пароля одного пользователя.
Один из способов усложнить жизнь злоумышленнику - это сделать процесс хеширования ресурсоемким (например, 5000 раундов sha1 (salt + sha1 (salt + sha1 (salt + password)))). Вам нужно делать это только при каждой попытке входа в систему. Злоумышленник должен делать это для каждой комбинации соли + пароля, которую он хочет угадать. Вы должны решить, подходит ли это для ваших нужд. Ответ, наверное, нет.
Изменить: кроме паролей, у пользователя система, что еще нужно зашифровать как хорошая практика? Они шифруют имена пользователей или что-то еще?
Я параноик, но я бы сказал, что любая информация, которая вам, владельцу сайта, не нужна, пока пользователь не вошел в систему, должна быть зашифрована производным от пароля пользователя. Таким образом, у злоумышленников нет доступа, потому что у вас нет доступа.
Для системы обработки онлайн-заказов, например, вам может потребоваться, чтобы их почтовый адрес, их имя и самый последний заказ были незашифрованными, но их история заказов и любимый цвет могут быть зашифрованы паролем их учетной записи.
Обратите внимание, что если вы сделаете это, и они потеряют свой пароль, защищенная информация также будет потеряна.
2nd Edit: Что такое односторонний хеш? я значит, технически я не могу отменить разработать мой исходный код? Может это плохой вопрос, потому что я не знаю много об одностороннем хешировании.
Хеш - это метод систематического удаления информации. Допустим, вы начинаете со строки и производите «srflcdos», отбрасывая все, кроме примерно каждого четвертого символа. Текст, который я «заштриховал», мог быть: «копьё, если рыба лежит спокойно. Не садись!», Или это могло быть: «суперкалифрагилистический экспериментальный». В любом случае доказать невозможно.
Криптографические хэши делают намного больше смешивания и других преобразований вместе с отбрасыванием, чтобы сделать их более безопасными для небольших объемов входных данных и избежать утечки каких-либо фактов о входных данных.В качестве примера небезопасного хеша: если вы знаете, что всякий раз, когда ввод содержит букву A, 12 бит хеша равны 1, то вы предоставляете информацию об исходном тексте, и результат не является криптографически безопасным хешем.
Принцип заключается в том, что вы не можете реконструировать процесс, если между каждым преобразованием вы выбрасываете информацию, жизненно важную для отмены предыдущего преобразования. MD5sum производит 128 битов вывода, независимо от того, вводите ли вы 1 бит или 12 петабайт информации. Очевидно, вы не можете сжать 12 петабайт в 128 бит, поэтому информация явно выбрасывается в процессе вычисления хэша.
2-е изменение: что такое односторонний хэш? Я имею в виду, что технически я не могу реконструировать свой исходный код? Может быть, это плохой вопрос, потому что я не очень разбираюсь в одностороннем хешировании.
«Односторонний» в криптографии означает «трудно инвертировать». Проще говоря, это означает, что если я дам вам sha1 (пароль) , вы не сможете найти пароль за любой разумный промежуток времени.
Это называется вычислительно односторонним . Многие путают это с другим определением одностороннего (из математики), означающим «не один к одному» , которое здесь не применяется.
Вы должны хранить хэш вашего пароля вместо фактической читаемой строки, также рассмотрите возможность использования "Salting" для дополнительной безопасности
Причина, по которой вы храните хешированный пароль, заключается в том, что если кому-то удастся получить данные в вашей таблице пользователей, он все равно не сможет войти в систему. Односторонний хэш не может быть расшифрован (даже человек, который его зашифровал!), поэтому очень сложно использовать хешированный пароль для чего-либо.
Поскольку вы не можете расшифровать пароль в базе данных, вам нужно взять введенный пароль и повторить тот же процесс для его хеширования, а затем сравнить хешированные значения, чтобы найти совпадение. Из-за этого ваша соль не может быть полностью случайной, так как в конечном итоге вы получите разные результаты.
Кроме того, вы не хотите, чтобы пароль передавался в незашифрованном виде, поэтому страницы входа обычно являются страницами HTTPS.