Comments 42
эти капчи-пазлы собирать с тач пада одно получасовое удовольствие (подгонять пиксель в пиксель)
Превращать регистрацию/логин для нормальных пользователей в приключение — не выход.
Я на хабре видел (не могу найти ссылку) более действенный способ защиты от брутфорса: ограничение по количеству попыток логина с прогрессирующим баном по времени. Т.е. если не угадали — подождите 15 секунд, например; если опять не угадали — 30, опять — минуту, 5, 10… и запрещать попытки логина в этот временной промежуток. В оригинале этот способ предлагался для защиты от DDoS — бан за спам http-запросами. Утверждалось, что он может выдержать даже целую сеть ботов.
Я на хабре видел (не могу найти ссылку) более действенный способ защиты от брутфорса: ограничение по количеству попыток логина с прогрессирующим баном по времени. Т.е. если не угадали — подождите 15 секунд, например; если опять не угадали — 30, опять — минуту, 5, 10… и запрещать попытки логина в этот временной промежуток. В оригинале этот способ предлагался для защиты от DDoS — бан за спам http-запросами. Утверждалось, что он может выдержать даже целую сеть ботов.
Это не выход, поскольку все бруты работают через прокси и с очисткой cookies.
А User-Agent, набор плагинов и установленных шрифтов? Если брать маленький временной промежуток, то среди тех, кто работает с сайтом, это позволит практически однозначно идентифицировать того, кто пытается брутфорсить.
Ну и если на бруте стоит User-Agent IE9, то что, не пускать всех пользователей IE9? Я уже не говорю про то, что его можно каждый раз менять.
А как определить набор плагинов/шрифтов?
А как определить набор плагинов/шрифтов?
Фишка не в том, что IE9, а что 5 минут назад этот человек пытался 3 раза неудачно войти на Ваш сайт, притом у него Windows 7, Firefox, редкий шрифт из малоиспользуемой программы и очень специфический набор плагинов для браузера.
Это теория вероятностей — комбинация в общем распространённых признаков даёт однозначную идентификацию. См. Бертильонаж
Это теория вероятностей — комбинация в общем распространённых признаков даёт однозначную идентификацию. См. Бертильонаж
Кстати такая защита была одно время реализована в почте Yahoo и она была очень эффективна. Скрипты регистрации перечисляли все плагины, их версии, шрифты, разрешение экрана, размер окна браузера и даже все поддерживаемые браузером MIME-типы для формирования уникального отпечатка. В общем были задействованы все возможности javascript для определения окружения пользователя.
Если мы говорим об атаке на конкретный логин, то прокси и куки не имеют значения — ограничение касается собственно логина. По-моему, на хабре такое тоже есть — не попал с паролем с первого-второго раза — жди пять минут, перед следующей попыткой.
В статье описан случай брута по базе email: пароль
В таком случае, пользоваться, как и сказал выше evocatus, комбинацией свойств браузера (была на хабре статья о том, что комбинация этих факторов позволяет трекинг пользователя даже несмотря на куки, прокси и т.п.)
хранить пароли в открытом виде — это уже нарушение «морали разработчика», только соленые хеши
То есть возможно при помощи брута через прокси, имея список юзеров хабра, заблокировать логин?
Не уверен, на сколько по времени действует блокировка. Думаю, там задержка минута, может секунд 30. Для нормального юзера не проблема, он подождет, а для ботов вполне ощутимо (учитывая еще и капчу). Так что мне даже интересно, кому придет в голову потратить кучу бабла на индусов (=капча) и время/бабло на разработку бота, просто ради того, чтобы сделать некий кратковременный DoS (причем не всего сервиса, а только логина)…
А против такого давно существует противоядие. Список доверенных хостов. Steam, Google и т.д.
Куки здесь вообще ни при чём. Посмотрите:
http://habrahabr.ru/post/156909/
https://panopticlick.eff.org/
http://habrahabr.ru/post/156909/
https://panopticlick.eff.org/
Вот это уже интересно, не знал. Добавлю с статью
Кстати, бывают и «брутальные куки на стеройдах» :) http://samy.pl/evercookie/
Это не выход, если брутят разные логины, по одному паролю на логин. Если логин один и тот же, то легко посчитать число неверных попыток и выставить нужный таймаут.
Можно запрещать постить ссылки пока не набрано, например, 15 сообщений и не прошло, например, 3 дня с момента регистрации.
Насчёт баз паролей — никто не мешает самому сайтовладельцу проверять при регистрации, не находится ли пароль в базе. Если да, то объяснять человеку как он глупо делает, ставя везде одинаковые пароли, и заставить выбрать другой, сложный.
Вообще поведение спамера всегда будет отличаться от поведения нормального пользователя. Если сравнивать его по многим параметрам (дата регистрации, ник, частота и содержание сообщений, использование лс и т.д.), то я верю, что можно написать самообучающийся алгоритм, определяющий спамеров.
Спам нельзя уничтожить, его можно сделать очень дорогостоящим удовольствием.
Насчёт баз паролей — никто не мешает самому сайтовладельцу проверять при регистрации, не находится ли пароль в базе. Если да, то объяснять человеку как он глупо делает, ставя везде одинаковые пароли, и заставить выбрать другой, сложный.
Вообще поведение спамера всегда будет отличаться от поведения нормального пользователя. Если сравнивать его по многим параметрам (дата регистрации, ник, частота и содержание сообщений, использование лс и т.д.), то я верю, что можно написать самообучающийся алгоритм, определяющий спамеров.
Спам нельзя уничтожить, его можно сделать очень дорогостоящим удовольствием.
Можно запрещать постить ссылки пока не набрано, например, 15 сообщений и не прошло, например, 3 дня с момента регистрации.
Это упоминалось в статье, но ведь такие ограничения не всегда могут быть уместными.
Насчёт баз паролей — никто не мешает самому сайтовладельцу проверять при регистрации, не находится ли пароль в базе. Если да, то объяснять человеку как он глупо делает, ставя везде одинаковые пароли, и заставить выбрать другой, сложный.
Не очень понял, что вы имели в виду. Этих баз в свободном доступе нет, они продаются. Вы предлагаете владельцу каждого сайта скупать все базы?
Вообще поведение спамера всегда будет отличаться от поведения нормального пользователя. Если сравнивать его по многим параметрам (дата регистрации, ник, частота и содержание сообщений, использование лс и т.д.), то я верю, что можно написать самообучающийся алгоритм, определяющий спамеров.
Распознавать чисто по поведению, мне кажется, трудновато придется.
Спам нельзя уничтожить, его можно сделать очень дорогостоящим удовольствием.
А вот это чистая правда
Заставив спамера прятаться, вести себя как можно более похоже на обычного пользователя, мы просто превращаем его в обычного пользователя. Его эффективность упадёт катастрофически.
Но, чтоб этот подход сработал на 100%, поля должны быть одинакового размера, типа, выводится в случайном порядке на странице и, желательно, добавить одно или несколько полей «Оставьте это поле пустым». И окончательным штрихом будет использование изображений одинакового размера и динамическим адресом вместо label.
Конечно, это все сложновато, но отлично защитит ваш сайт практически без неудобств для реальных пользователей.
Ах-ха-ха
А что страшного в том, что пользователь введет сначала email, потом логин, а не наоборот? Конечно не стоит разделять пару с паролем и подтверждением, но есть же еще куча полей, типа имени, города, которые, в принципе, можно перемешать.
Многие люди любят использовать штуки типа LastPass, запоминания паролей Chrome и Firefox. И это хорошо, потому что тогда они могут ставить много разных паролей, не боясь их забыть (LastPass даже позволяет удобно сгенерировать сложный пароль).
А таким образом Вы просто убиваете саму идею таких сервисов — они просто не смогут распознать факт логина, сделанный настолько через ****
А таким образом Вы просто убиваете саму идею таких сервисов — они просто не смогут распознать факт логина, сделанный настолько через ****
Конечно, есть и более изощренные способы, которыми спамеры составляют базы, но их обзор сам по себе потянет на статью. Если общество проявит интерес к этому вопросу, то, возможно, я напишу обо всем намного подробнее.
напишите, пожалуйста!
я давно говорил, что капчи это безсмысленно — сидят студенты-обезьяны и тупо пробивают все за копейки, капчи сложные только мешают нормальным пользователям. Я старался добавлять при регистрации поля с выбором, ответ для нового посетителя является знакомым (городские ресурсы — улицу популярную или здание или автомобильный ресурс… вообщем тематика ресурса). И только тогда сократилось число левых аккаунтов до минимума.
Eсли речь идет о неанглоязычном ресурсе, то проблему индо-китайцев, разгадывающих каптчу, можно решить достаточно простым способом:
как это сделал ивритоязычный портал Walla!:
На неанглийском языке (русском/украинском/иврите/...) генерируется картинка с курсивом, в которой указана простенькая задачка. В случае с Walla! просят написать цифрами «сто двадцать шесть».
Учитывая, что русский курсив можно сделать таким:
индийским отгадывателям каптчи придется нелегко.
как это сделал ивритоязычный портал Walla!:
На неанглийском языке (русском/украинском/иврите/...) генерируется картинка с курсивом, в которой указана простенькая задачка. В случае с Walla! просят написать цифрами «сто двадцать шесть».
Учитывая, что русский курсив можно сделать таким:
индийским отгадывателям каптчи придется нелегко.
Ага, индусы категорически не справляются с нестандартными капчами. На личном сайте через кошачью капчу Asirra за последний год ни один бот не пробился, тогда как до этого спам валил тоннами через reCAPTCHA.
А ещё можно совместить приятное с удобным: настроить дополнительную регистрацию/вход через OpenID/OAuth и убрать капчу только там. Боты и роботизированные индусы будут гарантированно ломиться в парольную аутентификацию, но там их будет ждать суровая кошачья капча, а простые пользователи в большинстве своём даже и не узнают, что на сайте есть капча.
А ещё можно совместить приятное с удобным: настроить дополнительную регистрацию/вход через OpenID/OAuth и убрать капчу только там. Боты и роботизированные индусы будут гарантированно ломиться в парольную аутентификацию, но там их будет ждать суровая кошачья капча, а простые пользователи в большинстве своём даже и не узнают, что на сайте есть капча.
Но убрать капчу со страницы регистрации – очень глупое решение, поскольку регистрация станет не только абсолютно бесплатной для спамера, но и невероятно быстрой (решение капчи индусом в среднем занимает 30 секунд).
Капчу можно убрать, и поставить проверку по времени между запросом формы (генерации токена) и приходом данных. Токен всё равно будет, т.к. от CSRF (и фреймов) защиту ставить тоже надо.
автор одной из систем автоматизации браузера
яваскрипт эмулируете? полную загрузку страницы со всеми картинками, скриптами и прочего? по ssl ходить умеете?
Конечно, автоматизируется ведь браузер, в котором поддержка всего этого есть изначально.В моем профиле есть ссылка, можете посмотреть.
А в чём, собственно, проблема (в контексте озвученных вопросов) :)
Взять python и webkit — фактически у вас в руках оказывается полностью работоспособный браузер, который выполнит весь яваскрипт, загрузит страницу полностью со всеми картинками, скриптами и прочим, по ssl сходит куда надо, и при этом выполнит click'и в нужных местах, которые получит программно, а не от манипулятора, типа мышь :)
Взять python и webkit — фактически у вас в руках оказывается полностью работоспособный браузер, который выполнит весь яваскрипт, загрузит страницу полностью со всеми картинками, скриптами и прочим, по ssl сходит куда надо, и при этом выполнит click'и в нужных местах, которые получит программно, а не от манипулятора, типа мышь :)
я при авторизации добавлял скрытый токен в куку,
токен вычислялся как сумма логина и хеша пароля и случайного числа и для каждой сессии токен уникален
после авторизации я вычислял новый токен и сравнивал с токеном в куке (случайное число хранится в учетной записи на одну сессию), далее я вытаскивал логин и сверял хеш от сумма логина хеша пароля и случайного числа из БД с полученным токеном.
вроде как такая схема хорошо помогала. Если кука отсутствовала, то выкатывал капчу
токен вычислялся как сумма логина и хеша пароля и случайного числа и для каждой сессии токен уникален
после авторизации я вычислял новый токен и сравнивал с токеном в куке (случайное число хранится в учетной записи на одну сессию), далее я вытаскивал логин и сверял хеш от сумма логина хеша пароля и случайного числа из БД с полученным токеном.
вроде как такая схема хорошо помогала. Если кука отсутствовала, то выкатывал капчу
Отлично!
Информация специфическая и полезная. Продолжать нужно!
(Так же ждём описание проблем и решений high-load от команд порнопорталов!)
Информация специфическая и полезная. Продолжать нужно!
(Так же ждём описание проблем и решений high-load от команд порнопорталов!)
Sign up to leave a comment.
Защита сайта от спамеров и угона аккаунтов