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

 +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