Может кто-нибудь объяснить, как сделать хеширование паролей + соление

Позвольте мне попытаться немного прояснить ситуацию на несколько упрощенном примере. (md5() используется только для примера - вам не следует не использовать его на практике.)

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

 echo md5('letmein')

... вы получите результат 0d107d09f5bbe40cade3de5c71e9e9b7. Если вы погуглите, вы увидите ряд страниц, сообщающих вам, что это Хеш MD5 для letmein. Соль предназначена для предотвращения подобных явлений.

Предположим, у вас есть функция randomStringGenerator(), которая генерирует случайную $x-символьную строку. Чтобы использовать его для добавления пароля, вы должны сделать что-то вроде этого:

 $password = 'letmein';
 $salt = randomStringGenerator(64); //let's pretend this is 747B517C80567D86906CD28443B992209B8EC601A74A2D18E5E80070703C5F49

 $hash = md5($password . $salt);

Затем вы выполняете md5(letmein747B517C80567D86906CD28443B992209B8EC601A74A2D18E5E80070703C5F49), который возвращает af7cbbc1eacf780e70344af1a4b16698, который нельзя "найти" так же легко, как letmein без соли.

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

Однако! Поскольку общие алгоритмы хеширования, такие как MD5 и SHA2, очень быстры, не следует использовать их для хранения паролей. Ознакомьтесь с phpass для реализации bcrypt в PHP.

Надеюсь, это поможет!

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

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

Как именно используется соль, зависит от используемого алгоритма. Некоторые алгоритмы хеширования (например, bcrypt, который специально создан для хеширования паролей) имеют специальный входной параметр соли (или сами генерируют соль и включают ее в вывод):

H = bcrypt (пароль, жесткость) или H = bcrypt (соль, пароль, жесткость)

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

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

HMAC (пароль, соль) = Хеш (пароль ⊕ opad || Хеш (ipad ⊕ пароль || соль))

где opad и ipad - некоторые постоянные значения заполнения.

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

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

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

Хотя у @Chris и @Pualo очень хорошие ответы. Я хотел добавить еще кое-что о солидных паролях, которые не были выражены.

Использование пароля не является настоящим механизмом защиты. Не имеет значения, используете ли вы bcrypt или какой-либо другой механизм. Это просто тактика проволочек, не более того.

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

Кроме того, большинство зомби-машин можно арендовать ...

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

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

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

Использование соли предотвращает использование предварительно вычисленных радужных таблиц, например, если пользователь использует «Пароль» в качестве пароля, MD5 («Пароль»), SHA1 («Пароль») или WhatEver («Пароль») могут быть хорошо известными результатами. хранится в некоторых радужных таблицах. Если вы используете другое значение соли для каждого человека, называемое nonce, вы получите MD5 (HMAC («Пароль», «RandomSaltValue»)), SHA1 («Пароль», «AnotherRandomSaltValue»), ... что означает два разных хешированные значения пароля для того же начального пароля. Теперь вопрос о хранении этих значений солей ... я думаю, что они могут быть сохранены в базе данных, идея солей состоит в том, чтобы предотвратить атаку в стиле радуги, а не проблему взлома базы данных.

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

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

Хотя кажется, что bcrypt и даже больше scrypt, похоже, привлекают меньше внимания с точки зрения криптоанализа, чем PBKDF2, изложенное в RSA PKCS # 5. Подробнее см. обсуждение.

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

РЕДАКТИРОВАТЬ: удалена ошибочная информация. Я буду придерживаться единственного хорошего совета, который у меня был, - не кататься самостоятельно.

А как насчет безопасного хэша и соли для паролей PHP? У него даже есть примеры на PHP.