Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
ну так ведь прокси в наше время найти не проблема в любых количествах.
Количество проксей, кстати, тоже ограничено. А еще можно тупо сразу отсекать, скажем, весь Китай :-)
Не так давно в википедии забанили один IP, а оказалось, что с него сидела целая небольшая страна.
Северная Корея?
Там вроде 6 или 7 адресов всего.
Впрочем, на остров в океане достаточно и одного IP :-)
Там вроде 6 или 7 адресов всего.
Впрочем, на остров в океане достаточно и одного IP :-)
Это был Катар
Ага. А потом пишут, что правительство страны NNN препятствует доступу своих граждан к сайту SSS. :)
Да, забавный был случай. :) Не для пользователей страны конечно.
У некоторых стран один IP на всех.
Вариант интересен, но разве сейчас спамеры в основном используют не леммингов/школьников дешёвую рабочую силу для обхода капчи?
Ну с этим уже да, сильно не поборешся :)
Хотя на досуге подумать надо будет, но в принципе уже в данном методе ДРС не сможет одновременно распознавать несколько капч => упадет производительнось => поднимется стоимость ДРС что приведет к их нерентабельности. (это в идеале)
Хотя на досуге подумать надо будет, но в принципе уже в данном методе ДРС не сможет одновременно распознавать несколько капч => упадет производительнось => поднимется стоимость ДРС что приведет к их нерентабельности. (это в идеале)
Мне ваш метод с одной стороны нравится, но с другой пугает ориентацией на вычислительные мощности машины. В нашей стране диапазон поколений компьютеров широк просто необычайно, а значит и диапазон силы воздействия метода (читай загрузки клиента) будет сильно разниться.
Вобщем я так подумал что пользователь сталкивается с данным вопросом чаще всего только при регистрации, а следовательно пока он дойдет до ввода капчи ему еще приходится заполнить несколько полей на что уйдет некоторое время, из чего следует что разница между 5-ю и 20-ю секундами работы скрипта на разных клиентских машинах не оч. существенна.
К тому же можно по небольшому заданию рассчитать сколько времени уйдет на все задание и информировать об этом пользователя.
К тому же можно по небольшому заданию рассчитать сколько времени уйдет на все задание и информировать об этом пользователя.
интересная идея, мне нравится
Делать задержку в отдавании «капчи», после трех неудачных попыток предлагать зайти еще раз, при откровенном флуде — банить и вносить в список контроля (повторный бан гораздо быстрее).
По поводу нагрузки я уже выше отписался(предупреждать, и начинать считать перед заполнением формы),
по поводу ограничений на время выполнения это да, но думаю можно это как-нибудь обойти,
по поводу ограничений на использования яваскрипта в принципе это уже почти не актуально т.к. большинство сайтов ориентируются на АЯКС или похожее, и пользователю с отключенным яваскриптом там делать нечего.
Но конечно я могу быть некомпетентен в некоторых технических аспектах, и возможно вы правы.
по поводу ограничений на время выполнения это да, но думаю можно это как-нибудь обойти,
по поводу ограничений на использования яваскрипта в принципе это уже почти не актуально т.к. большинство сайтов ориентируются на АЯКС или похожее, и пользователю с отключенным яваскриптом там делать нечего.
Но конечно я могу быть некомпетентен в некоторых технических аспектах, и возможно вы правы.
А если капчу показывает флеш, то зачем ему трудится для создания паузы? может, пусть просто тихо её по таймеру отжидает, не грузя машину? А чтоб паралельно не запускали, можно на пользовательской машине это… через флешовый персистент-объект попробовать флажёк «считаю» организовать, один на всю клиентскую машину.
Все что можно отснифить, не поддается защите от регистрации ботами. Дело только во времени.
Хотите убрать нагрузку на сервер, отдавайте капчу с «задержкой».
Хотите убрать нагрузку на сервер, отдавайте капчу с «задержкой».
Дело в том что этим мы не уберем загрузку а только отсрочим ее, т.е. например:
Клиент посылает 100 запросов сначала, потом за время пока ждет капчу по первым 100 запросам делает еще 1000 в итоге мы получаем ту же нагрузку но осроченую на время ожидания капчи.
Клиент посылает 100 запросов сначала, потом за время пока ждет капчу по первым 100 запросам делает еще 1000 в итоге мы получаем ту же нагрузку но осроченую на время ожидания капчи.
Только не стоит засыпать (sleep) при генерации капчи, а то только усугубим ситуацию, собственноручно приложив участия в достижения лимита одновременно работающих обработчиков веб-сервера.
Сохраняйте на стороне сервера, в какое время капча может быть получена в момент генерации страницы. А у клиента скрипт с задержкой на загрузку капчи на нужное нам количество секунд. Далее если запрос пришел на капчу раньше времени — просто выкидываем мусор, ибо это точно робот.
Сохраняйте на стороне сервера, в какое время капча может быть получена в момент генерации страницы. А у клиента скрипт с задержкой на загрузку капчи на нужное нам количество секунд. Далее если запрос пришел на капчу раньше времени — просто выкидываем мусор, ибо это точно робот.
Поправьте загаловок.
Предлагалось использовать подобное решение для борьбы с почтовым спамом (hashcash). Но большого распространения эта идея не получила.
В случае сайта вся ситуация под контролем, вполне может сработать.
В случае сайта вся ситуация под контролем, вполне может сработать.
Видишь регистрацию на каждом втором «вшивом сайте» и понимаешь — что главное для чего её делали — бороться с ботами. А человеки им не нужны.
Мой совет такой — никаких капч, до систематического интереса к вашему сайту ботов.
Ну а про брутфорс md5 для каждого клиента на яваскрипте улыбнусь и промолчу :)
Мой совет такой — никаких капч, до систематического интереса к вашему сайту ботов.
Ну а про брутфорс md5 для каждого клиента на яваскрипте улыбнусь и промолчу :)
Брутфорс в данном случае приведен только для примера программы нагружающей клиента, вместо него может быть любая задача результат выполнения которой мы знаем, а для получения ответа клиентом нужно некоторое время работы его компьютера,
По поводу необращения внимания ботов на маленькие сайты, приведу пример: Года 3 назад пытался сделать развлекалку типа фишек, посещалка была в среднем примерно 500 человеков/день, потом туда был поставлен форум(ipb кажется), на котором по прошествии месяца, в день регистрировалось по 20-50 ботов.
Но вы правы, конечно, иногда сложность регистрации не соответствует нужности регистрации на сайте. Каждый для себя выбирает методы согласно своих потребностей, а я только предложил один из них.
По поводу необращения внимания ботов на маленькие сайты, приведу пример: Года 3 назад пытался сделать развлекалку типа фишек, посещалка была в среднем примерно 500 человеков/день, потом туда был поставлен форум(ipb кажется), на котором по прошествии месяца, в день регистрировалось по 20-50 ботов.
Но вы правы, конечно, иногда сложность регистрации не соответствует нужности регистрации на сайте. Каждый для себя выбирает методы согласно своих потребностей, а я только предложил один из них.
Идея с брутфорсом — фигня. Обычный юзер брутфорсит яваскриптом или флешем — я не поленюсь написать на Си, он будет работать в несколько тысяч раз быстрее яваскрипта без оптимизации. то, что юзер будет брутфорсить 10 секунд, я решу за 0.01 с. Вот и все.
p.s. Кстати недоумеваю, почему в качестве скриптов для web-страниц был выбран тормозной javaScript, а не компилирууемый в ассемблеро-подобный байткод язык. На клиенте его можно было бы перекомпилироваьт в чистый ассемблер, и все бы летало. Лишнее подтверждение тому, что HTML/CSS и прочая муть устарели окончалельно и являются скорее худшим из возможных решений для представления информации в Web.
p.s. Кстати недоумеваю, почему в качестве скриптов для web-страниц был выбран тормозной javaScript, а не компилирууемый в ассемблеро-подобный байткод язык. На клиенте его можно было бы перекомпилироваьт в чистый ассемблер, и все бы летало. Лишнее подтверждение тому, что HTML/CSS и прочая муть устарели окончалельно и являются скорее худшим из возможных решений для представления информации в Web.
А вы представляете себе проблемы безопасности с вашим вариантом?
Я написал «ассемблеро-подобный язык» а не ассемблер! С соответствующими ограничениями, например на использование указателей (вместо них например используем ID переменной и проверку границ, чтобы программа не вылезла из своей области памяти). Но компилируемый в результате в ассемблер. Скорость по сравнению с языком с динамическими типами и хеш-таблицами — огромная.
в данном случае мне ответить нечего :) тут вы правы, но конечно не думаю что настолько все плохо, раз в 5 еще ладно но на 2-3 порядка :/ не очень верится, может только задачу подобрать которая будет выполнятся одинаково независимо от языка… (но по этому поводу никаких мыслей по крайней мере пока у меня нет)
p.s. Кстати недоумеваю, почему в качестве скриптов для web-страниц был выбран тормозной javaScript, а не компилирууемый в ассемблеро-подобный байткод язык.
Потому что мощности современных компьютеров позволяют игнорировать разницу в производительности (для задач клиентских скриптов), лежащую между компилируемыми и интерпретируемые программами. А последние имеют гораздо большую гибкость и, на мой взгляд, лучше подходят для задач, которые скрипты сейчас решают на стороне клиента.
Поищите вот на этой странице: https://wiki.mozilla.org/JavaScript:TraceMonkey слово «JIT».
Java-апплеты появились до flash, однако последний фактически вытеснил jvm из веб-пространства — Вас такой факт не смущает?
Потому что флеш позволяет легко рисовать всякие красивости и работать с мультимедией (а это в принципе то, ради чего эти плагины и ставятся), на Яве все таки это посложнее… к тому же я подозреваю что он оптимизирован для работы с графикой и скорее всего еще и производительнее явы в этом направлении.
спасибо, я в курсе, почему один другого вытесил :)
я просто хотел отметить тот факт, что идея отдавать байткод для выполнения на виртуальной машине стара как мир, и была реализована в различных вариантах.
а про производительность, я думаю, Вы правы ровно до тех пор, пока для java не будут (а уже скорее всего не будут) реализованы специализированные библиотеки.
я просто хотел отметить тот факт, что идея отдавать байткод для выполнения на виртуальной машине стара как мир, и была реализована в различных вариантах.
а про производительность, я думаю, Вы правы ровно до тех пор, пока для java не будут (а уже скорее всего не будут) реализованы специализированные библиотеки.
почему бы не показывать пользователю картинку с пересекающимися прямыми и не спрашивать сколько существует пересечений, или показывать фотографию и попросить щелкнуть на определенный предмет на ней
С прямыми не понял, если там «не» лишние то это делается так навскидку:
просматриваем окружность около всех точек на вопрос смены цвета если смен >=8 то пересечение. Может есть и более легкие методы.
С предметами уже было обсуждение, проблема была в том что сервер не сможет этого сгенерировать. Если же количество предметов, картинок ограничено то вся идея тряет смысл после перебора всех возможных вариантов.
К тому же суть идеи только коственно касается сложности подбора а более для противодействию нагрузке при подборе с слабой вероятностью распознавания.
просматриваем окружность около всех точек на вопрос смены цвета если смен >=8 то пересечение. Может есть и более легкие методы.
С предметами уже было обсуждение, проблема была в том что сервер не сможет этого сгенерировать. Если же количество предметов, картинок ограничено то вся идея тряет смысл после перебора всех возможных вариантов.
К тому же суть идеи только коственно касается сложности подбора а более для противодействию нагрузке при подборе с слабой вероятностью распознавания.
Слишком мало вариантов. Сервер будет тупо отвечать 3 и угадывать с немалой вероятностью, т.к. заставить пользователя найти больше десятка пересечений в каше из прямых нереально.
Я думаю очень полезно вводить проверку след характера:
1)При отгрузке страницы производим старт таймера
2)При нажатии кнопки, мы проверяем время затраченное на заполнение форм
3)Установить минимальный порог по времени, в результате которого нормальный юзер заполняет эту форму, ну допустим 15-30 сек.
4)Всех скоростных после трех попыток либо баним, либо заносим в БЛ, как было предложено выше.
+Можно вообще не использовать капчи, что я думаю будет актуально для мелких сайтов.
1)При отгрузке страницы производим старт таймера
2)При нажатии кнопки, мы проверяем время затраченное на заполнение форм
3)Установить минимальный порог по времени, в результате которого нормальный юзер заполняет эту форму, ну допустим 15-30 сек.
4)Всех скоростных после трех попыток либо баним, либо заносим в БЛ, как было предложено выше.
+Можно вообще не использовать капчи, что я думаю будет актуально для мелких сайтов.
Выше я уже обьяснил почему задержка выдачи капчи не сработает.
Тут тоже самое только паузу будет делать не сервер а клиент.
Тут тоже самое только паузу будет делать не сервер а клиент.
А как быть с пользователями всяких Робоформ(или как их там), где поля заполняются автоматом. Юзеру толко понадобится 2-5 секунд чтобы ввести капчу и нажать кнопку.
Да и delay на 15 секунд после get запроса в боте поставить не проблема. А если бот с поддержкой потоков и прокси то разницы вообще нет.
Да и delay на 15 секунд после get запроса в боте поставить не проблема. А если бот с поддержкой потоков и прокси то разницы вообще нет.
Ну не знаю, не знаю… Сколько видел авторегеров — на яваскрипт и флеш им по-барабану, ибо качают они только текст странички + вычленяют картинку капчи. Ну хотя наверное самые тру-спамеры пишут плагины к браузерам, тогда да, загнутся «клиенты»
Что мешает хранить уже сгенерированные изображения капч на сервере, и генерировать новые только в небольшом количестве случаев. Старые изображения, разумеется, периодически зачищаются.
Появилась идея — держать капчу до тех пор, пока ее не разгадают. Чтобы не повторялась, держать 1000 капч. Разгадали — удаляем, генерим новую.
CAPTCHA можно и (на нагруженном ресурсе) нужно генерировать заранее.
На мой взгляд правильнее будет ввести на уровне скриптов сайта некую переменную $LOG. При попытке авторизации/регистрации (и как следствие генерации капчи) переписывать ее — $LOG ++;, при достижении значения переменной $LOG равным к примеру 4, делаем все просто — die(«Brootforce Protect !»);. Все. Как минимум боту надо открыть новую сессию. Но ведь нам никто не мешает запоминать IP где-нибудь на сервере и запрещать коннект к скрипту все тем же die(«Brootforce Protect !»); какой-то интервал времени. Нагрузка будет в разы меньше.
Я в последнее время отошёл от идеи использования собственных каптч в пользу recaptcha.net/. Конечно популярность этого сервиса может расцениваться как минус, так как спамеры могут заточит свои системы под взлом именно этой системы. Ну и самое главное. Бороться нужно прежде всего не со спамерами, а с их клиентами.(впрочем и тут появляется дыра, для черного пиара)
извините, если глупость скажу. а можно для регистрации написать какой-нибудь клиентик на флеше? маленькая флешка, которая будет оставлять на компьютере пользователя след в виде Локал Шаред Обжекта, доступного только экземплярам этой флешки. ну и соответственно хранить в этом Локал Шаред Обжекте количество обращений к экземплярам этой флешки. А если во флеш плеере отключена возможность создавать Локал Шаред Обжекты, мило просить клинета включить эту функцию. Правда флешку могут докомпильнуть случайно… если кто-нибудь узнает название этого шаред обжекта случится глобальная жопа :)
Самый простой способ борьбы с людьми-подбиральщиками каптчи — сделать капчу, которая потребует от пользователя выполнить какие-то длительные интерактивные действия, например путём диалога на ajax, чтобы сам процесс занимал столько времени, что стоимость такого подбора сильно вырастает. Достаточно выводить по одной букве в несколько секунд, после набора предыдущей буквы, например, или нескольких буквосочетаний.
ЭЦП на каждого. Заходишь на сайт, подписываешься под каждым постом (к примеру). ЭЦП анонимный. Но процедура его регистрации должна занимать минут 5-10 времени. Таким образом можно избавиться от капчи как факта, а в случае злоупотреблений конкретным ЭЦП блокировать его в автоматическом режиме через чёрные списки. Полная анонимность приносится, конечно, в жертву.
Мне кажется проблему подбора можно решить гораздо проще. Каптча должна быть одноразовой. Если не решена, то клиенту выдается другая, а все повторные ответы на старую отклоняются, даже если они правильные.
Интересно, какова вероятность подбора капчи, если после каждого неправильного ответа она будет меняться? Сам и отвечу на этот вопрос — вероятность будет нулевой.
Остается найтиидиота наивного спаммера, готового брутфорсить ресурс, зная, что подобрать капчу за реальный промежуток времени ему все равно не удастся. Проще ввести ее ручками или заплатить тому, кто это сделает за него.
Можно даже под такой невероятный случай найти простое решение — если с момента выдачи клиенту капчи прошло, к примеру, менее 5 секунд (минут|часов), то отсылать клиенту сообщение об ошибке. Бороться с брутфорсом с помошью яваскриптов и флэша просто бессмысленно.
Остается найти
Можно даже под такой невероятный случай найти простое решение — если с момента выдачи клиенту капчи прошло, к примеру, менее 5 секунд (минут|часов), то отсылать клиенту сообщение об ошибке. Бороться с брутфорсом с помошью яваскриптов и флэша просто бессмысленно.
Как тут уже написали, единственным препятствием явным может быть время. Задержка например 5 сек. При ошибке подождать не долго, зато весь брут идет в… Самый «дешевый способ» защиты, и быстрый при тестовой разработке
1. Давать регистрировать нового пользователя с одного айпишника раз в минуту или раз в 5 минут
2. Сделать возможность нажатия кнопки «зарегистрироваться» только через 20-30 секунд после загрузки страницы. Как раз за это время пользователь должен заполнить поля формы. Время, оставшееся до возможности нажать кнопку «зарегистрироваться» хранить на сервере, дабы исключить возможность обхода javascript;
Тоесть сочитать в себе и счетчик на яваскрипте и хранение времени в базе. При сабмите средствами серверных языков программирования проверять прошло ли время с открытия страницы до ее сабмита.
2. Сделать возможность нажатия кнопки «зарегистрироваться» только через 20-30 секунд после загрузки страницы. Как раз за это время пользователь должен заполнить поля формы. Время, оставшееся до возможности нажать кнопку «зарегистрироваться» хранить на сервере, дабы исключить возможность обхода javascript;
Тоесть сочитать в себе и счетчик на яваскрипте и хранение времени в базе. При сабмите средствами серверных языков программирования проверять прошло ли время с открытия страницы до ее сабмита.
Советую ознакомиться с шарадами Меркля, если «ещё не».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размышления на тему автоматической регистрации.