немного о безопастности

[Elendor]

Покопавшись в форуме ничего ни нашел полезного для себя о безопастности web-приложений.

Решил внести свой вклад.

Первое что хотлось бы обсудить это шифрование данных. Когда-то мне казалось, что зашивровав пароль md5()'том можно не волноваться. Но недавно нашел другое решение. Это решение обычно называют засаливанием и т.д..

Что же подразумевается под этим понятием? Я объясню кто ещё не знает:

function my_md5($text, $salt)
{
		if(!$salt)
		{
				$salt = "my_salt";
		}
		return $salt.md5($salt.$text);
}

Этим мы защищаем себя от так называемых rainbow-таблиц

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

Пока все. Жду обсуждений и добавлений.

Edited October 15, 2008 by Elendor

[Furius]

как вариант можно еще предложить либо

md5($salt.md5($salt.$text));

но это уже из серии извращений конечно =)

так же еще можно добавить, что стоит на сайтах использовать логирование ВСЕХ ошибок, в том чсиле и php, так сказать, чтобы не палить имена полей в бд. А то видел я такой один сайт, до сих пор в дрож бросает

[Elendor]

md5($salt.md5($salt.$text));

это тоже самое что заархивировать архив

чтобы не палить имена полей в бд

Edited October 15, 2008 by Elendor

[vvsh]

Кодировать лучше sha1, у него нет дырок.

[Elendor]

ну это как сказать, хоть sha1, хоть sha2. Нет нечего что нельзя взломать.

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

[rash]

Кодировать лучше sha1, у него нет дырок.

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

Почему вы считаете sha1 более надежным?

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

Хотя хороший криптоалгоритм подразумевает невозможность компрометации данных даже при знании деталей используемого алгоритма. "Соль" выглядит шагом в правильном направлении.

[NJSmith]

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

ну, судя по фразе - вааще не имеет смысла что-то делать раз рано или поздно взломают

на самом деле знаменитая фраза знаменитого человека "If it run, it can be defeated" не пример для подражания, не обязательно менять алгоритмы, может лучше написать один, но такой, который предельно осложнит жизнь хацкерам? и тогда трудозатраты на взлом не окупят прибыль как следствие и ломать не станут до упора, а кто станет - те фанатики, от них никто не застрахован они и с топором в офис вломиться могут

[vvsh]

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

Почему вы считаете sha1 более надежным?

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

А для md5 такого нет, можно конечно их подбирать, а потом шифровать и сравнивать со значением из поля, но это слишком долгий процесс.

[rash]

Это и есть rainbow-таблицы, расшифровать md5 пока невозможно, можно подобрать по таблице известных соответствий, соль как раз этому мешает.

[vvsh]

Я просто не хочу светить сайт, сейчас попробую случайный пароль, и потом попробую расшифровать его.

[rash]

Да таких сайтов несколько мне попадалось (уже не помню ни одного, но видел как минимум 2), так что не хочешь - не свети, его можно будет найти и так. :-)

Там просто обширные таблицы соответствия хешей и распространенных паролей.

[vvsh]

Да, вы правы, извините...

P.S. ко мне можно и на ты......

[rash]

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

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

[Ялекс]

sha1(md5($pass)) ?

[rash]

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

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

[vvsh]

md5(sha1(md5($pass))) - а как тебе такой вариант?

[Elendor]

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

[rash]

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

А мы экономим место или усложняем перебор? :-)

Усложнить раскрытие данных такой подход вполне может, просто он менее универсален.

[Elendor]

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

[vvsh]

А можешь мне рассказать как защищаться от sql-иньекций?

А можешь мне рассказать как защищаться от sql-иньекций?

[Elendor]

дал бы ссылку, да только она сейчас не работает. Полазь по antichat.ru там есть много чего по этому поводу.

[NJSmith]

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

на 5-10 мс?

[rash]

Кстати скорость загрузки страницы не изменится совершенно — она зависит от пропускной способности канала и ее ограничений. Изменится время обработки скрипта на сервере. :-) Это если придиратсья. :-)

[Elendor]

не надо придираться

[Ялекс]

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

Да и вообще это дурацкая затея разбирать подобные темы...

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

Если вы хотите обезопасить своих пользователей, то прежде всего лучше ставить проверку на создаваемый пароль: как минимум 6 символов + текстовые + цифры + спец символы. Таким образом скрипт долго будет искать подобную комбинацию в таблицах хэша. Да еще забыл напомнить: Хакер начинает взламывать хеш, только после того как онный попадет ему в руки. Так что держите БД под замком и все будет ОК)

[IceBars]

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

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

з. ы. : хотелось бы кроме криптографии вопрос безопасности пошире рассмотреть, хотя бы те вопросы, которые Фленов в своей книге упоминает.