Защита от подбора пароля.

Popoff

popoff.donetsk.ua
а я баню не по ip, а по логину. по разным логинам - пожалуйста, подбирайте. по одному логину - не более 10 неправильных попыток подряд в сутки. и ни о каких прокси не задумываюсь :) чтобы работа пользователей не блокировалась, у меня есть система разблокировки заблокированных логинов, которая работает через отправку почты и переходу по секретной ссылке (которую тоже можно подбирать, но она на несколько порядков сложнее пароля и ее подбор ограничивается другими средствами). у меня ведется журнал всех блокировок-разблокировок и в случае постоянных блокировок я могу вручную смотреть, кого блокируют, откуда блокируют и, соответственно, банить вручную. :)
 

Royal Flash

-=MaestrO=-
Popoff
Банить по логину при 10 попытках - не самая хорошая идея, и это тут уже обсуждалось. Зная логин юзера, что не есть большая сложность, так как в большинстве систем логин - это имя, которым подписываются статьи, например, можно его специально заблокировать. Попробуй потом объяснить пользователю, почему его аккаунт заблокирован и как его разблокировать... А если это будет повторяться каждый день с разных IP? Пользователь будет вынужден каждый раз заходить на сайт через свою почту?! Разве вариант предложеный мной не лучше? Там проблема блокировки IP-шника реального юзера решается кукой.
white phoenix
Просьба, конкретно обрисовать это самое зло.
 

Popoff

popoff.donetsk.ua
Куки - это если мы подбираем вручную, через браузер, да? Или я, программируя скрипт подбора пароля, должен также запрограммировать функциональность для запоминания этих кук и последующей отсылки их на сервер?

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

IP можно банить не только по одиночке, но и по маске. Запускаем, например, whoisinform.ru и баним, баним, баним. Придумываем особый вид бана, который только запрещает логиниться. Это к тому, что "каждый день - разные IP"

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

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

Универсальной защиты нет. Блокировка по адресу - менее надежная, поскольку дает возможность большего (в десятки, сотни, тысячи раз) количества попыток, чем блокировка по логину. Делаем вирус, рассылаем его всем и устраиваем распределенную атаку, когда с огромного количества разных адресов подбираются пароли к разным логинам. После этого система окажется заблокированной для всех при любом подходе - хоть по адресам, хоть по логинам блокируй. Как ты от такого предлагаешь защититься?

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

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

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

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

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

Royal Flash

-=MaestrO=-
Popoff
Куки - это если мы подбираем вручную, через браузер, да? Или я, программируя скрипт подбора пароля, должен также запрограммировать функциональность для запоминания этих кук и последующей отсылки их на сервер?
Если бы вы внимательно читали, то что я писал, то не задавали бы лишних вопросов. Повторю: куки нужны только на случай предотвращения блокировки, т.е. если у пользователя есть кука с секретным словом, (у каждого пользователя свое слово-идентификатор), то блокировка IP на него не распространяется, точнее ему дается еще 10 попыток. Этот вариант я описал ранее.
IP можно банить не только по одиночке, но и по маске.
Согласен.
в случае с блокировкой по логину пользователь может разблокировать свой логин самостоятельно, а в случае с блокировкой по адресу все окажутся со связанными руками.
Нет. Ставим, например, unlock.php, который не проверяет блокировку IP, через который и можно разблокировать аккаунт.
Делаем вирус, рассылаем его всем и устраиваем распределенную атаку, когда с огромного количества разных адресов подбираются пароли к разным логинам.
Как вы себе это представляете? Ведь машина-жертва, где запущен троян имеет свой 1 IP. При 10 неверных заходах она блокируется. Не имеет значения, 1 логин подбирался или более. Далее, предположим, что есть 100`000 разных IP. Заполучить их очень и очень тяжело, но всеже, допустим этот вариант. Только он ничего не принесет взломщику, так как все эти 100000 ip попадут в стоп-лист - если не согласны, пожалуйста, логику скрипта подбора пароля "в студию".

Мой вариант, в случае распределенного подбора паролей - выдержит намного большее кол-во хостов, нежели ваш. А защита от атак DoS и DDoS, я в этом топе не рассматривал вообще - это тема для отдельного топа, да и только средствами PHP её решить нереально. Логика моего мкрипта базируется на утверждении: потенциальному взломщику (а перебор паролей 10 шт в 10 сек явно указывает, что это попытка взлома) доступ на сайт "заказан".
Я выбрал блокировку по логину всего лишь потому, что она немножко надежнее блокировки по адресу
В своем топе, я опроверг ваше утверждение. Блокировка по логину тоже имеет место быть, но только в случае, если 1 и тот-же логин подбирается с разных IP, 10 шт за 10 сек. (не 5000, как я писал ранее.) В случае обнаружении перебора пароля к 1 логину, действие: после входа в систему отобрать у этого пользователя все права, отослать пользователю на почтовый ящик письмо с новым паролем, ссылкой на разблокировку аккаунта и предупреждением, и полный доступ в систему, до разблокировки аккаунта не давать. Выводить вместо ожидаемого контента сообщение, наподобии: "Ваша учетная запись блокирована в связи с подбором пароля для логина "вася". Инструкции по разбл. отправлены на ваш почтовый ящик, указаный вами при регистрации."
 

Юзер

Новичок
Royal Flash
Собственно твоя тема и тебе решать, но я бы предложил уже как-нить подэтожить всё изложенное. Т.е. каждый уже наверняка сделал для себя какие-нить выводы, и вот в связи с этим, хотелось бы всёже услышать умо заключение каждого в виде алгорита на поставленный вопрос "Защита от подбора пароля".
Предлагаю с тебя начать ;-)
 

zarus

Хитрожопый макак
>> Умо заключение каждого в виде алгорита на поставленный вопрос "Защита от подбора пароля".
Вы хотели сказать, изложение вариантов алгоритма защиты? И крайних вариантов - самый жесткий, и самый мягкий.
 

zarus

Хитрожопый макак
Мой вариант:
Мягкий. Пусть пробуют подобрать до бесконечности с интервалом в Н секунд. Никаких блокировок.
Потому что на моем сайте нет разделов, которые нужно закрывать абсолютно. Т.е. я пока не решаю задачу о "неуловимом Джо".
 

Popoff

popoff.donetsk.ua
Royal Flash
Делаем вирус, рассылаем его *ВСЕМ* и устраиваем распределенную атаку
Ведь машина-жертва, где запущен троян имеет свой 1 IP.
Не одну машину инфицируем. Много машин.

Для обычных проектов это чисто гипотетическая ситуация. Реально возможна только для очень больших и важных проектов. Подбор пароля на обычном сайте - это тоже ситуация скорее из разряда гипотетических %) Уже четвертый раз за сегодня это дурацкое слово использую %)

-~{}~ 29.12.05 23:06:

Только он ничего не принесет взломщику, так как все эти 100000 ip попадут в стоп-лист - если не согласны, пожалуйста, логику скрипта подбора пароля "в студию".
Именно об этом я Вам и говорю. Все эти миллион ни в чем не повинных людей окажутся заблокированными. Я ситуацию предложил не для подбора пароля, а для блокировки.
 

zarus

Хитрожопый макак
Автор оригинала: kruglov
zarus

Как реализуете интервал в Н секунд? sleepом?
Про это см. выше.
Выборка last_login_try из БД, если не установлена сессионная переменная + запись в сессию, проверка интервала через time(), в случае ошибки - просто выдаем предупреждение без слипа. Естественно, так и DoS можно получить, но это уже отдельная песня :|
 

kruglov

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

zarus

Хитрожопый макак
Автор оригинала: kruglov
Сессионная переменная у хакера никогда в начале каждой попытки не установлена, ему выгодно притворяться новым пользователем.
Запись в сессию только чтобы уменьшить число обращений к БД. Ну так я к тому, что мой сайт навряд-ли будут ломать, и делать что-то серьезное нет смысла.
з.ы. А тема хорошая, неплохо бы из нее FAQ слепить
з.з.ы. За последний месяц очень много хороших и грамотных тем появилось, достойных FAQ...
 

php_m

Новичок
А я сделал еще проще :)
Если юзер 5 раз подряд вводит неправильный логин\пасс, получает бан по IP на 30 минут, и на мыло, соответствующее данному логину(если такой вообще есть в БД) приходит ссылка, по которой ему надо перейти, чтобы снять бан со своего IP, т.е. если это какой-то оглумевший "хакир" пытается подобрать пароль, то бан снять он не сможет никак, а если это админ сайта, то бан легко снимется переходом по пришедшей ссылке.
 

kruglov

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

В целом, это решение примерно соответствует по защищенности просто бану IP на тот же срок.
 

Royal Flash

-=MaestrO=-
Юзер
В ближайшее время постараюсь выложить здесь логику приложения, со всеми доработками :)
 

Royal Flash

-=MaestrO=-
1. Блокируем пользователя по IP (блокировка 1, описание ниже, на вход на страницу авторизации (не на весь сайт!) на 10 мин.) в случае если с одного IP 10 раз за 10 сек. введены неверные логин и пароль.
2. Блокируем пользователя (блокировка 2, описана ниже) по логину, если 20 раз за одни сутки для одного логина введен неправильный пароль. Если все эти попытки с 1-го IP блокируем и IP.
3. Если ip адресс пользователя стоит в стоп-листе - проверяем, есть ли у пользователя кука с секретным словом, и если есть, пускаем еще на 10 попыток. Только поле для ввода логина уже не используется, логин узнается по соответствию с секретным словом. В случаее повторения варианта 1 - стираем секретное слово из базы, что приводит к блокировке этого пользователя.
Секретное слово генерируется случайным образом, для каждого пользователя свое. Нпример md5(mt_rand(10000, 100000000))

Блокировка 1. В случае, если заблокирован ip пользователя, разблок. производится только после контакта с администратором, так как в этом случае есть все оснавания подозревать данного пользователя в попытках несанкционированного доступа.

Блокировка 2. После ввода не правильного пароля для 1 логина 20 раз, заносим этот логин в базу стоп-логинов, отсылаем на e-mail этого логина сообщение с новым паролем, ссылкой для разблокировки (10 значное число, файл ссылки генерируется случайным образом) и инструкции. В ответ на 21 и последующие попытки входа под заблокированным логином, выводится сообщение, что логин заблокирован, инструкции по разблокировке отправлены на e-mail, указанный при регистрации. Причем, даже если логин отсутствует в базе, необходимо на 21-ую попытку слать такое-же сообщение, для предотвращения узнавания логинов пользователей ресурса.
 
Сверху