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

Question

Я прочитал на SO (и с других веб-сайтов, найденных в Google после того, как попытался немного подробнее разобраться в нем), что правильный безопасный способ хранения паролей в базе данных - хранить хэшированное + соленое значение пароль. Кроме того, соль должна быть разной для каждого пользователя, чтобы хакеры не могли нанести вред, даже если у них есть зашифрованные значения.

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

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

Это правильно, или я просто ничего не понял о хешировании паролей + засолке?

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

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

Что я хотел бы знать: как вы последовательно получаете одну и ту же соль, если она генерируется случайным образом? Если соль хранится в базе данных, как упоминали некоторые люди, тогда я вижу, как вы продолжаете получать ту же соль, но возникает другой вопрос: как она делает пароли более безопасными, если кто-либо, имеющий доступ к базе данных, имеет доступ к соль? Разве они не могут просто добавить (известную) соль ко всем паролям, которые они пробуют, и результат будет таким же (исключая незначительные потери времени), чем отсутствие его вообще?

Answer 1

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

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

 echo md5('letmein')

... вы получите вывод 0d107d09f5bbe40cade3de5c71e9e9b7.Если вы Google это , вы получите несколько страниц, сообщающих, что это хеш 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 для реализации PHP bcrypt.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

---

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

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

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

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

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

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

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

---

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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