1.Храните пароли исключительно в захешированном виде. 2.Для хеширования оптимально применять MD5. Он работает медленее чем DES, что увеличивает время, необходимое на раскрытие исходной строки. 3.Захешировав пароль 2-3 раза подряд, вы значительно усложните жизнь взломщику. 4.Принудительное увеличение длины пароля (например, путем приписывания к исходному паролю ещё одной псевдослучайной строки) создаст дополнительные сложности при переборе. Конечно, если дополнительная строка не станет известна взломщику.
5.Проверяйте введённый пароль на сложность. Оптимальный вариант - 7 - 12 символов букв различных регистров и цифр. Мало кто сможет дождаться окончания перебора, а таблицы есть ещё далеко не для всех строк. 6.Защититься от тупого перебора через веб интерфейс просто - достаточно блокировать аккаунт на 3 секунды после каждого ввода пароля. Взломщик сможет перебирать не более 20 строк в минуту. 7.На время сессии, запускайте контроль IP. Рекомендация устаревшая, но сколько разработчиков уже прокололось на этом. 8.А если пользователь и взломщик пришли через один прокси? Надо считать ещё и контрольную сумму для строки USER_AGENT. И сравнивать при каждом действии в защищенной зоне сайта. Простой и нехитрый прием, который отгоняет 80% взломщиков. 9.Галочку "запомнить меня" делайте только в крайнем случае. Какой бы не была надежной защита в скриптах - клиенты уязвимы и могут выдать свою конфиденциальную информацию вместе с куками. 10.Внимательно ознакомтесь с документацией по адресу http://ha.ckers.org/xss.html. И не допускайте такого! Хотя, не так то это и просто. XSS и немного СИ могут выманивать пароли не хуже, чем взлом БД.
Комментарии:
Онанимус (25 сентября 2007 01:08): заело итераций хеширования не спасёт. халахтекопасносте! upyachka тчк ру ъёопт
n0PxN0p (24 сентября 2007 09:57): А чего о ней рассказывать? Ssl, secure sockets layer - криптографический протокол, обеспечивающий защищённое соединение между пользователем и сервером, усложняющий перехват передаваемой информации третьей стороной. А для подробностей есть поисковые системы и куча бумаг на эту тему, тема как бы изъезженная или типа того (:
Онанимус (02 Октябрь 2006 22:37): n0xi0uzz, не заметно что-то))
n0xi0uzz (29 Сентябрь 2006 23:30): 4k, md5 RIP
Онанимус (21 Сентябрь 2006 23:11): хешировать исключительно с солью и 2 раза в md5 сессия - и ип и куки чтобы не брутили - блокировать после нескольких неправильных попыток (как в vB - так оптимальнее) насчет "запомнить" - если все фильтруется, то xss не будет (=
ns_keip, ssl шифрует траффик между пользователем и сервером, в результате чего неграмотно настроеный IDS не контролирует трафф
Онанимус (12 Сентябрь 2006 16:01): а как же SSL? бло бы прикольно если бы рассказали об этой технологии.
еще 1 важный, имхо, совет - то, что нужно уделять внимание секьюрности не только страницы входа на сервер.)), но и всем остальным, так как вот на моей памяти взломов (известных из новостей) "в лоб" было раз-два и обчелся.
большинство уязвимостей (как и большую часть "смысловой нагрузки" движка) как раз таят в себе страницы, призванные собирать инфу от пользователей (допустим, постингв форумах итд.). они не кажутся такими же "серьезными" на предмет секьюрити, как страницы login.* / admin.* / logout.*, и к ним относятся не так кропотливо.
как результат - то тут, то там недостаточная проверка данных какого-нибудь поля.
