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

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

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

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


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

если честно, то я не понимаю смысл соли.. Допусти 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 наше все

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

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

 Никогда, это сказки пьяных математиков.

 +1.

 Времена SQL-inj прошли. 
Потому что программисты опыта набрались.
Сейчас их могут допустить только новички, причем только те, кто по старым книгам учится.

Соль по сути - перестраховка. Ну как жилеты под сиденьем самолетов - спасти не спасут, но "на всякий случай".

Пхпшники о безопасности    или еще одна забавная тема наполненная чуть более чем полностью заблуждениями.



Теоретически база (и даже исходники) может утечь другими каналами, например при помощи взлома бекап сервера etc.



Да больше велосипедов хороших и разных. Новые еще более хитрые способы извратиться и получить мнимую безопасность.

Итак. Чтобы говорить о salt в первую очередь стоит различать секретную и публичную соль. Обычно подразумевают что секретная соль одна на всю базу и хранится в секрете. Публичная соль может быть уникальна для каждого пользователя и может храниться там же в базе данных рядом с хешем.
Далее я буду иметь ввиду именно публичную соль уникальную для каждого пользователя.
Зачем это все нужно.
1. Затруднить восстановление пароля по радужным таблицам.
2. Скрыть наличие одинаковых паролей.
Все. Все остальные извращения на тему добавлений спецсимволов, логинов, ни коим образом не меняют эффективность схемы, кроме морального удовлетворения автора.


Чем лучше? Приводите факты, а не допущения.
В данном случае все хитрости и усложнения алгоритма являются "Security through obscurity".

По поводу коллизий. Так как обычно размер входа хеш-функции меньше или сопоставим с размером выхода, вероятность найти коллизию (учитывая сопоставимый размер входа) крайне мала.
Хотя стоит отметить, что многие научные источники в последнее время весьма сомнительно высказываются о MD5. (Вопрос детально не изучал, приведете авторитетные научные источники будет полезно).
К примеру SHA-1 является более стойкой, однако на задаче о хешировании паролей говорить о том что же лучше MD5 или скажем SHA-1 сомнительно.

P.S. Используйте bcrypt, господа, и не изобретайте велосипедов.


Это сообщение отредактировал(а) cutwater - 23.12.2011, 00:08

Докажи. Факты хочу


Сказка, до сих пор встречаю. Еще скажите, что про XSS надо забыть как страшный сон


тогда уж в обратном порядке символы поставить   



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

Вот именно - просто изврат!


ты уже ответил на этот вопрос 
и только!

да безразницы 

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

мне больше вот эта выдержка нравится

Как то уже ближе к реальности, да и то, кто видел их реально? Я так и не нашёл, то какие-то обрезанные, то чистый развод на бабло... Ну если кто реально знает адрес, покажите. А сделайте пароль типа "рПшzge2k" и я посмотрю как ты его подберёте 

А что касается инъенкций, то если мне не изменяет память, старшие версии MySQL уже сами с этим справляются

на сколько старшие? вроде везде стоят MySQL 5 версии, а там такого я не видел 

не могу найти, но где-то у себя читал в доках :( Просто сам на это внимание заострил... а может речь шла об MySQLi...

может быть, но это расширение для СУБД а не самостоятельная СУБД.

 Применительно к реальности это факты. А доказывать нужно не невозможность, а возможность. А это уже на твоей стороне.
Докажешь? Найди пароль(не равный '123456'), для которого md5 будет равен md5('123456').

 Я тоже встречаю, но только в ###коде, работающем с SQL-запросами, как со строками.

Вот с XSS все сложно. Я, к примеру, не смогу 100% обезопаситься от него без потери данных(при обработке пользовательского HTML). И, как видно из истории, многие XSS работали в 1-2 браузерах из-за их отступлений от стандартов.
А в SQL-запросах все четко и элементарно определено и ошибку могут сделать лишь новички.

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

Добавлено через 43 секунды
И скажу еще одно, на это форуме я находил и SQL и XSS. Тезка все давно прикрыл, но сам факт говорит за себя

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

Высказанная вами идея о не симметричном шифрование, не безынтересна, но опять же возникает вопрос что и как?

Встречался с такой ситуацией: произошел взлом сайта, злоумышленниками были изменены js файлы очень хитрым способом. Так как продакшен версия выгружается на сервер через SVN-сервер, то восстановление было произведено в течение нескольких минут. Сделав восстановление, был проведен аудит безопасности, в том числе и проверка на  SQL-инекции. Результатом стало следующие: 
1. В коде уязвимостей не было, что и не удивительно 50% времени при написание и тестирование уделяется вопросам безопасности.
2. Взлом произошёл из-за администратора, которому понадобилось скачать файл с сервера и он не придумал ничего лучше как открыть для этого FTP(установив и настроив при этом сам FTP сервер) доступ к серверу, подключиться к нему через FileZilla и сохранить в ней настройки соединения.

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



Это сообщение отредактировал(а) krundetz - 23.12.2011, 10:43

krundetz, на все 100 согласен  Из статистики: "... 95% несанкционированного доступа к информации осуществляется путём банальной кражи системных блоков или носителей.." 

А вообще что касается соли... Интересно взглянуть на стоимость информации, которую стоит защищать как сервера ГРУ   
Куда проще заставить пользователя создавать пароль из строчная_буква+прописная_буква+цифра, да ещё и про словарю прогнать, чтобы запретить ввод паролей хотя бы из основного словаря..

зы
вот ещё одна причина по которой лучше использовать для работы с базой отдельный класс. Один раз в нём предусмотрел защиту от инъекций и больше не паришься, что в будущем какое-нибудь расширение нарушит безопасность..

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



Рассмотрим такой пример: 
1. Есть популярный блог 50000 уникальных посетителей в сутки и 1000 страниц.
2. Посетители могут оставлять комментарии только после регистрации, причем если посетитель недавно зарегистрировался на сайте то комментарий появляется только после модерации, после оставления 100 комментариев его комментарии добавляются без модерации.
3. Зарегистрировано 5000 комментаторов из них 500 не модерируются.
4. Произошёл взлом сайта, о котором владелец блога не знает.
5. Внезапно на сайте все зарегистрированные комментаторы начинают оставлять спам, ко всем записям, пусть это будет 1 запись к оному посту от одного пользователя за сутки. Это будет 5000000 спам комментариев за сутки, и 50000 спам комментариев которые точно появятся на страницах сайта.
6. Владелец блога узнал о проблеме на 3 сутки, когда решил оставить новую запись.
7. Устранение проблемы потребовало ещё 2 суток, причем владелец блога догадался закрыть комментирование только на 2 сутки и спамные комментарии продолжали поступать на сайт.
Вопрос сколько времени придется потратить владельцу блога на очистку блога от таких комментариев?
Вопрос сколько посетителей потеряет блог из-за таких комментариев?
Зная сколько приносит в среднем один посетитель, зная сколько стоит час времени владельца блога и ответив на два предыдущих вопроса мы будем знать сколько денег стоит эта информация.

Это сообщение отредактировал(а) krundetz - 23.12.2011, 12:51

krundetz, тут правильно поднимался вопрос про безопасность сервера... Вопрос больше к нему. Да и ситуация больше теоретическая... 

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

ты меня тут с кемто путаешь, я с тобой насчет MD5 не спорил

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


Mysqli и PDO. Все придумано до нас. mysql deprecated.



Я перечитал тему и воспользовался поисом. Где речь шла о симметричном шифровании?

Это сообщение отредактировал(а) cutwater - 23.12.2011, 16:21

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

о симметричном не шла нигде, а вот это ваше высказывание:

натолкнуло меня на мысль о Асимметричном (не симметричном) шифрование

Это сообщение отредактировал(а) krundetz - 23.12.2011, 16:57

Ок. А то моя воспринял не симметричное шифрование как ломаная русская языка.

А зачем? Не вижу смысла. Как вы себе это представляете?

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

Это сообщение отредактировал(а) cutwater - 23.12.2011, 17:34

krundetz, да я вообще не спорю, чисто рассуждения и только    ту как ни странно вообще что-то споров нет...
Мне не хватает много способов отдачи данных, т.е. в каком виде и в какой форме.. 

ksnk, почему не реально? я задаю условие для пароля:
1. должна быть минимум одна цифра
2. должна быть минимум одна строчная буква
3. должна быть минимум одна прописная буква
4. длина не менее 8 знаков
5. пароль не должен попасть в основной словарь "для взлома". Таких много... средний размер 2-3 метра в формате txt

и я больше чем уверен, что "тупых" юзеров будет минимум минимума 

А я развернусь и свалю с блога. Потому, что я ВСЕГДА и ВЕЗДЕ ставлю пароль 12345.   

Ситуация неразрешима логически

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

Это сообщение отредактировал(а) Gold Dragon - 23.12.2011, 18:11

В твоих требованиях к пользователю встречаются такие нетривиальные, как
-- умение запомнить 8-ми буквенный пароль с цифрами
-- умение скачать, распаковать и произвести поиск своего пароля в сторонней базе паролей

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

Это я к тому, что если для дополнительной безопасности достаточно слегка подсолить - почему бы это не сделать?

 Именно, были новичками. А сейчас SQL-inj не находят в популярных CMS.
Смотри трекеры уязвимостей: последние такие уязвимости были давно, а SQL-inj находят лишь в плагинах к ним(который совсем не кортим пишет).

 Повторю еще раз: ранее софт писали не программисты, а новички, т.к. отрасль тогда только появлялась. И только потом они стали программистами.

 Вот кто его использует, тот и может SQL-inj получить. Просто из-за человеческого фактора.

 А еще хуже тот, кто думает, но не делает.

ну вообще-то основные почтовики предъявляют эти требования.. тотже гугля.. Или к примеру тотже скайп, ICQ

Вот нужно и разумно подходить в защите..  md5 вполне хватает почти всегда без всякой соли 

я точно это и имел в виду


в рамках конкретно этой задачи? или вообще?


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

 Мне показалось, что ты говорил про человеческий фактор.
Я же сказал, что он будет только при некачественном коде иметь место быть(SQL-запросы в виде строк). При качественном человеческого фактора не будет.

пример

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

 Забудут(человеческий фактор, обусловленный кривым инструментом) кусок строки заэскейпить.

 Тут про SQL-што спорили. Не использую никаких мер защиты против сабжа.

От криворуких программистов защиты не бывает, но мы, вроде не их обсуждаем   

Как это? Даже mysql_real_escape_string принципиально не используешь?

 Во-первых, я в этой теме уже 2 раза писал, что наличие этой функции - признак воняющего кода. По нескольким причинам, одна из которых - безопасность.
Потому что при использовании SQL-запросов в виде строк мы имеем наличие человеческого фактора и возможную SQL-inj из-за него.
Хочешь писать SQL запросы - используй плейсхолдеры. А можешь не писать и использовать AR или ORM.

Во-вторых, при правильной работе с СУБД SQL-inj не будет без использования каких-либо мер для обеспечения безопасности. Вобщем RTFM по вашей библиотеке для работы с СУБД.

Причина твоих заблуждений в том, что ты считаешь экранирование средством от SQL-inj, а не обеспечением правильного синтаксиса запроса.

  Я чет совсем запутался, вроде как раз от человеческого фактора на прямую зависит качество кода. Или ты имеешь в виду инструментарий?


Я бы добавил что важна ещё правильная настройка самой СУБД.

Это сообщение отредактировал(а) krundetz - 31.12.2011, 01:01

 Программист не должен использовать потенциально-опасные функции типа mysql_real_escape_string. Точка.
Потому что рано или поздно он забудет ее применить.

Поэтому едтинственный разумный вариант - не работать с SQL-запросом как со строкой.

Согласен.

Не всегда есть такая возможность. Да и если здесь не будет косяков, найдутся в другом месте. Что со всем ни с чем не работать?


Это сообщение отредактировал(а) krundetz - 2.1.2012, 20:59

 И когда ее нет? Всякие плагины-экстеншены не рассматриваем, только отдельные продукты.

 Ну в данном случае говорили про SQL-inj.
От того же XSS пока полностью защититься очень сложно и эта работа явно не на человеконеделю.