Здравствуйте.

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

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

Суть соли в том, чтобы при попадании хеша в чужие руки, и дальнейшем восстановлении, хакер(назовем его так) получил НЕ исходный пароль, а белиберду
Причем солить нужно с умом, а не просто так


Хранить пароли в открытом виде нельзя, особенно в таком общественном месте как сайт

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

123 = 202cb962ac59075b964b07152d234b70
123соль = d17108a0680e23556907de0759696b4b

так вот, когда подберут коллизию к 202cb962ac59075b964b07152d234b70 то её будет легко использовать. а вот подобрать правильную коллизию к d17108a0680e23556907de0759696b4b уже нераельно, так как система к 123соль добавит еще соль  и мы получим 05c9255b68ec930dd27e5d16250838c7

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

да не прав.
SQL иньекция и всех делов. Причем доступа к скриптам нету)

Добавлено через 1 минуту и 51 секунду
обычный пример уязвимости. делай что хочешь. 

Если думать, что связь идет по https, то из "реальных" возможностей у среднего хакера есть два варианта взлома аккаунта - клавиатурный перехватчик(троян?) на компьютере клиента или воровство базы с сервера(как правило - из-за уязвимостей самого сайта или сопутствующего ПО, хакер получает возможность исполнять sql запросы броузером)... В первом варианте пароль уже есть, а второй означает, что в базе хранятся хеши паролей пользователей, которые можно подобрать перебором. Если рядом с хешем храниться его соль, то смысл в таком солении совершенно отсутствует. Соль должна быть в другом месте.  К примеру, массив солей прописан в файле, а в базе имеется ее индекс. В этом случае хакеру потребуется иметь доступ еще и к файлам сервера, уметь понять логику приложения и получить файл с солями. 

$дмитрий, я ни где не храню их в открытом виде.  У меня есть админка, там я жму "добавить пользователя", указываю данные (включая почту), на почту падает пароль, а в БД записывается хеш. Я не говорил нигде что в открытом виде он хранится)

Все равно не понял =\

Коллизия - это если у нас есть например пароль 123 и его какой-то хеш, а потом хакер находит что 543 тоже имеет такой же хеш, и использует его в качестве пароля?
Если так, то когда он получат пароли и соли с ними, он может же перебирать хеши добавляя соль (вначале\вконце). ? 

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

Добавлено через 5 минут и 47 секунд
ksnk, а, вот - соли не должны хранится в БД. Тогда понятно. Только вот я просто узнал про неё из Ion auth, а она позволяет хранить соли в БД.

да так


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

Добавлено через 1 минуту и 51 секунду

  

я делаю смешание, грубо говоря такое:


\r\n - это банальная защита от перебора по радужным таблицам)

Имеет смысл подсалить, мало ли


Если получен доступ к скриптам, дальше замарачиваться с БД никто не будет


Он не получит соль если она хранится в файле

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

И вообще, коллизия и MD5 - это великая(!) теория чем практика... Да и вредит она только сопоставления, а не подбору

Даже если ты боишься, то лучше соль использовать так

ПЕРВАЯ_ЧАСТЬ_ПАРОЛЯ + КАКАЯ_ТО_ХРЕНЬ + ВТОРАЯ_ЧАСТЬ_ПАРОЛЯ

имеем: пароль: 202cb962ac59075b964b07152d234b70 и хрень: a3b

получаем: 202cb962ac59075ba3b964b07152d234b70

А вот теперь ни одна радужная таблица не поможет

Добавлено @ 14:55
и ещё раз повторюсь - пароль должен быть НОРМАЛЬНЫМ а не qwerty. А радужные таблицы это всего-лишь пароль=MD5(пароль)... Так что "нормальные" пароль просто там не должен быть

Это сообщение отредактировал(а) Gold Dragon - 22.12.2011, 14:56

А, кстати, а что если в файле просто прибавлять к паролю секретную строку.
Ведь смысл насколько я понял в том, чтобы если у хакера есть доступ к БД, то усложнить ему подбор хешей. Если соли хранить в БД - это плохо. Ок. Храним в файле в надежде что к файлам у него доступа нет.
Но ведь можно просто тогда в файле использовать единую соль для всех, ведь он все равно не имеет доступ к файлу, и перемешивать с ней.

так я про это и сказал  просто хеш имеет 32 знака, а вот если он будет иметь 33, то как его проверить? только перебирать и подбирать

Добавлено через 50 секунд
ps
в данном случае (по количеству символом) имею в виду MD5

а если SQL инъекция не возможна в принципе?

не использую, PDO наше все

Имеешь в виду так

Тогда это неправильно