Использование соли - это все хорошо? - PullRequest
0 голосов
/ 28 апреля 2009

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

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

Ваше мнение?

Дубликат:

Ответы [ 13 ]

21 голосов
/ 28 апреля 2009

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

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

Пароли никогда не хранятся в базе данных, сохраняется только хеш (MD5, SHA1, SHA2 * и т. Д.).

MD5 «пароля» всегда равно 286755fad04869ca523320acce0dc6a4. Если вы только что сохранили MD5 в базе данных паролей, вы можете просто найти эту строку и узнать, что пароль есть «пароль».

При добавлении соли '84824' сумма становится 2ca20e59df3a62e5dc4a3a0037372124. Но если у вас есть другая база данных (или другой пользователь использует тот же пароль), они могут иметь случайную соль 8999, что дает: 4e7a210a07958cfe24138a644cbb7f84

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

Edit:

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

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

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

Редактировать: Конечно, теперь это совершенно актуально: Я только что вошел как вы

16 голосов
/ 28 апреля 2009

Аксиома безопасности: никогда не храните пароли в виде простого текста в базе данных.

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

10 голосов
/ 28 апреля 2009

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

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

6 голосов
/ 28 апреля 2009

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

Конечно, злоумышленник может просто добавить соль в свои радужные таблицы, но вы только что сделали его радужные таблицы должны быть больше в зависимости от того, какие данные вы используете в качестве соли.

Если вы добавите два случайных байта, вы заставите радужные таблицы атакующих быть в 65536 раз больше. Это немаловажно. Добавьте четыре случайных байта, и коэффициент превысит 4 млрд.

5 голосов
/ 28 апреля 2009

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

john1970-> D3 88 99 до н.э. 0C B5 DC 0E D1 7F BB F7 EB F4 EA B2

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

2A CA 76 59 03 23 35 61 E0 20 49 11 8F FE F3 0E

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

md5 (x + 123456) = 2A ... 0E

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

5 голосов
/ 28 апреля 2009

Это имеет значение по той самой причине, которую вы упомянули: это усложняет атакующему использование атаки по словарю.

Взгляните на Вы хотите посолить? для хорошего объяснения.

4 голосов
/ 28 апреля 2009

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

http://en.wikipedia.org/wiki/Salt_(cryptography)

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

2 голосов
/ 28 апреля 2009

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

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

2 голосов
/ 28 апреля 2009

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

Лично я хеш (hash (salt1) + hash (pass) + hash (salt2)); Однако соль защищает только тогда, когда можно получить хэши из базы данных. Если кто-то действительно не может добраться до хэшей, то лучше всего ввести случайные вещи в форму.

1 голос
/ 28 апреля 2009

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

В самом деле? Как? Как они узнают, где соль заканчивается, и начинается пароль пользователя? Какое правило для разбора соли из пароля?

Вы говорите, что это "очевидно", потому что соль числовая? Тогда используйте соль base64. Насколько это "очевидно"?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...