Как стать автором
Обновить

Комментарии 52

Ожидал примера реализации какой-нибудь заковыристой капчи, а увидел описание очевидных вещей.
Не все знают эти «очевидные» вещи. Поиск по тегу на Хабре и примеры из жизни это подтверждают.
В топике, названном «Как это работает: CAPTCHA» и помеченном как туториал, вы ожидали увидеть реализацию заковыристой каптчи?
Посмотрите обсуждение ниже: здесь
Попытка что-то сгенерить удобное для пользователя и сложное для робота…
Ну и самое главное: не используйте капчу у себя на сайте, либо используйте как можно реже.
Согласен, но надо понимать, когда её можно не использовать. Например форма регистрации и два поля email и пароль — на почту приходит письмо с активацией. Капчи нет, а значит без дополнительных средств защиты такую форму могут завалить «левыми» адресами, и ваш сайт включат в черные списки почтовые службы. Да, в таком случае можно и нужно обходиться без капчи, но только в случае если у вас есть другой рубеж защиты, вроде лимита по ip (вынес это в статью)
if($_POST['captcha'] == $_SESSION['captcha']) return true;

В данном методе и заключена суть капчи, то, к чему может получить доступ приложение, но к чему не может получить доступ пользователь. Конечно в таком виде её не поставишь, пара проверок и все будет работать.
Хочу все написать рендеринг капчи на CSS3, но времени нет. Появится часок накидаю пост (=
Помню как после создания SMF форума для своих нужд через пару дней форум сразу загадился. Капча спасла ситуацию ровно на сутки. В итоге убрал капчу и добавил два контрольных вопроса в виде арифметических операций, но с разным ввод ответа (численным и буквенным). В течении года пока проблем не наблюдал.
У меня сервис с посещаемостью в 4-6 тыс уникальных посетителей в сутки. Заменяя капчу на скрытое поле ожидал увеличения количества регистраций ботов. По факту же оказалось, что либо я ботам неинтересен, либо мои несложные трюки вполне эффективны. Пользователю вводить вообще ничего не надо.
От ботов скрытое поле прекрасно спасает, сам таким методом пользуюсь. Но если захотят заспамить именно ваш сайт, как вы понимаете это вам ничем не поможет…
Я давно нашёл для себя эффективный способ блокирования спамщиков без всяких капч. В теге form атрибуту action указываем левый адрес, куда типо должна она уходить. Например form action="/application/poddelka.php".
Теперь все боты пытаются отправить данные по этому адресу. После формы /form, пишем ява скрипт в 2 строчки, который подменяет в атрибуте action значение на настоящее . Получается страница загружается и одновременно меняется action. Бот не может работать с js в данном случае, следовательно у него другие данные. На деле же у обычного пользователя конечно должен быть включён JS в настройках браузера (что лично для меня не критично). Зато у пользователя нету капчи, а боты не спамят. Возможно у этого метода есть другие минусы, но я их пока не выявил. Использую уже 3 года, ни один спам не прошёл. Ни разу за это время не встречал такого решения с капчей, вот решил поделиться своими знаниями…
Ваш сайт просто никому не нужен.
У меня посещалка 3000 уников в сутки. Я думаю достаточно для спамеров.
Думайте…
Без капчи иногда проблематично. На мой взгляд, наиболее интересное решение, направленное на минимизацию OCR, но в то же время вполне читабельное человеком — KCaptcha, а конкретно используемый алгоритм MultiWave. Может быть плохо искал, но нигде не видел алгоритмы ее распознавания, в отличие от многих других.
Можно, кстати, прегенерировать список капч, чтобы каждый раз не генерить изображение при запросе, а просто отдавать рандомное из существующих.
Сколько бы их не было — достаточно один раз собрать базу соответствия и спокойно ее использовать. Про то, что прегенерированные капчи — зло, уже много раз обсуждалось :)
А как собрать базу соответствия, если:
1. Капча после показа удаляется
2. Список капч регулярно обновляется
1) А какой вообще тогда смысл от прегенерации?
2) Если к примеру раз в сутки — можно собрать базу в начале суток. Если чаще — см. п. 1
Смысл прегенерации — защита от атак по урлу капчи, которые сильно нагрузят сервер в случае рантайм генерации изображений. Ниже верно заметили, что базу собирать смысла нет, т.к. капчи одноразовые. И всегда есть их запас, который может пополняться в любое время.
Можно собрать алфавит капчи.
Одна буква — это буква/цифра или картинка с различными модификациями (Wave, поворот и т.п.).
Как вот от этого защититься — вопрос…

Как вариант: «выберите недостающий предмет к предложенным на картинке» (или наоборот — лишний)
Т.е. отталкиваться от множества предметов объединенных одним свойством.
Например: картинка «ведро». Свойства для объекта «ведро» (они в бд на сервере): емкость для жидкости, с ручкой, из металла, не пропускает свет.
Далее выдать картинки: «ведро», «кружку» и «мяч». И текст: «Выберите лишний предмет».
Или: «мяч», «ножницы», «ведро». И текст: «Выберите лишний предмет».
Или: «ножницы», «иголка», «ведро». И текст: «Выберите лишний предмет».
По «клику» мышки — выбирается нужный и все.
Вы точно читали статью? Я её писал как раз, чтобы разработчики понимали что выбор одной картинки из трёх (как вы предлагаете) — не является защитной капчей. Она ломается перебором, причем в вашем случае более 30% попыток прохождения будут успешными.
Читал, конечно…
1. Неверный ответ — новое задание.
2. Картинка одна (или «раскрой» из нескольких) — передаются координаты клика и ID-куска (если их несколько). Карта изображения хранится на сервере.
3. Перебор и 30% успешности — да, если: картинки постоянно на одних позициях и одного размера и каждая покрывает 1/3 канваса задания.
Но!!!
1. Картинку мы делаем разного размера или вообще «кроим» на фрагмены (на несколько изображений) при передаче клиенту каждый раз по-разному. (пользователь не заметит разницы)
2. Можем менять размеры изображений, искажать, вертеть плоскость с изображением предмета в 3-х осях.
3. Перемещать изображения по основному полотну, чтобы они всегда были в разным местах + произвольный фон.

Все это можно складывать хэшами в БД, чтобы быть уверенным, что все последующие капчи — будут уникальными.
Теперь я вас понял, сначала думал вы имели в виду 3 картинки рядом и выбор одной из них.
В вашей схеме картинка делится на зоны. Попал в нужную зону — прошёл капчу. Я правильно понял?
Защита от распознавания довольно хорошая.
Но хромает защита от перебора. Если областей 50 — то и попыток для угадывания понадобится в среднем 50, или в случае 1 запроса в секунду — прохождение формы займет меньше минуты.

Но вашу капчу можно сделать намного лучше, если сделать несколько объектов. В случае трёх объектов — это уже не 1/50 а 1/19600 (если ничего не перепутал).

Кстати, в качестве источника для фона можно использовать фотографии городов в высоком разрешении (есть такие фото, например 100 гигапиксельные фото Лондона), там много мелких деталей и разных цветов, которые отличит человек но не робот.
Да нет. Идея в том, что нет в полученной информации данных о свойствах объектов.
Объекта 3 или больше и они объединены одним каким-то свойством. (прочитайте повнимательнее)
Пример: «ведро», «кружка» и «мяч» и текст: «Выберите лишний предмет (кликните «мышкой»)».

Если спросить: «2+3= ?» То компьютер знает: что есть 2 и что есть 3 и что делать со знаком "+".
А вот если попросить убрать лишний предмет, то только человек (пока что!) знает лишний в группе (или добавить недостающий к какому-то одному)
Идея была в этом.
Меня вообще давно интересует идея капчи с фотографическим фоном. Например такая:
image
У меня нет понимания того, как её распознать скриптом, при этом человек её читает без труда. Хотя возможно я не вижу какой то очевидный вариант её взлома. Поэтому говорю про это даже не как про идею, а лишь выдвигаю гипотезу которая нуждается в проверке.
1 Вариант: Логическое вычитание: берется представленная картинка и такой фон без цифр и выполняется «логическое вычитание». Остаются цифры на прозрачном фоне. Далее — OCR.
2 Вариант: выделение контуров, небольшое «размытие» (blur) всего изображения и затем еще раз выделение контуров, сравнение. Облака — пропадут, цифры — выделятся контуром. Далее — OCR.
Алфавит собрать будет трудно, т.к. искажения одного и того же символа могут быть случайными. Ещё можно несколько шрифтов использовать. Борьба с OCR на данный момент времени довольна проста, т.к. придумать новую защиту в данной ситуации проще, чем алгоритм её обхода.
Капчи с символами «тяжелы» стали для человека в последнее время…
У меня знакомый с 5 раза их отгадывает уже в 90% случаев…
(pqbd96 с вращением когда они на 360 и/или искажены, o0O — уже и так не просто)
Это очень затрудняет регистрацию посетителей и они «уходят».

Возможно одинаковые в написании символы надо (один из перечисленных ниже):
1. исключить
2. «мягко» проверять: q=p=6=9=b=d, 0=O=o, l=I=1, Z=z=2, 5=S=s, 8=B
3. использовать только заглавные буквы и цифры, «мягко» проверять 0=O, I=1, Z=2, 5=S, 8=B (т.к. при сильном искажении они неотличимы очень часто)
1) Генерировать дома или на на работе, вместо того, чтобы сервак нагружать.
Если капчи одноразовые, то базу соответствия не собрать.
Вообще, сервисы антикапч типа pixodrom.com и ему подобных пусть и позволяют обходить капчи, но всё же они пусть и совсем немного, но повышают стоимость распознавания.
Это как с обфускацией. В принципе прочитать код можно, но она (обфускация) повышает стоимость разбора кода.
Не просите ввести капчу, если вы уже убедились, что перед вами человек. Тут однако, надо быть осторожным, чтобы форму нельзя было использовать скриптом неограниченное число раз после однократного ввода капчи человеком.
Пример: форма регистрации. Если я где-то регистрируюсь, и забыл ввести поле «почтовый индекс», но правильно ввёл капчу — не надо показывать мне новую. Потратьте 10 минут на то, чтобы сохранить где-то у себя, что вот эту конкретную форму сейчас пытается заполнить живой человек. Ваши десять минут сэкономят многие часы человечеству.

А еще не очищайте поле ввода пароля. Два поля ввода пароля. Два поля ввода пароля с проверкой на JS их соответствия. Люто, бешено, ненавижу вбивать пароль по 4-10 раз, из-за кривой капчи, которую с первого раза не подберешь.
Вот тут, как говорится, «люто бешено плюсую». Зачем очищают поле пароля? Никогда не понимал. Может есть в этом какой то смысл с точки зрения безопасности? Но лично я его не вижу.
Формально рисков больше — страница может быть сохранена где-то в месте доступном злоумышленникам, например на промежуточном прокси или даже локально и там пароль будет в открытом виде, даже если используется https.
А при первой передаче пароля в форме? Не может??
Может и запрос быть записан и перехвачен или скопирован, и ответ. Но перехват запроса требует большей квалификации, чем ответа: показ ответа — штатная функция популярных браузеров ещё с прошлого тысячелетия.
ПАТ!
Понятно! В таком случае надо сохранять пароль в сессии на сервере, а на клиенте просто не показывать поля для ввода пароля если он был уже введен ранее
Кстати, да, вариант, писать что-то вроде «ваш пароль уже сохранен на сервере» вместо инпута или «ваш пароль уже сохранен на сервере, введите новый только если хотите его изменить» вместе с инпутом.
Могу сказать точно: очищают только тогда, когда пароль от клиента на сервер уходит в «чистом» виде. (не хешируясь через JS)

А если это так — повод призадуматься, стоит ли вообще работать дальше с таким сайтом!
Если однажды Вашу почту «взломают» просто будут читать через открытый ОДИНАКОВЫЙ пароль в БД такого сайта — не удивляйтесь!

А если он хешированный уже ушел на сервер — то почему бы не выдать его в форме (сохранив в сессии на сервере) при повторном запросе капчи с флагом для JS: «пароль хеширован. повторно не хешировать.» и если только поле будет изменено — тогда хешировать на стороне клиента или на стороне сервера ( при несовпадении хеша пароля в сессии и присланного: при попытке отправки «чистого» пароля)?
Парадокс!

Плюсую однозначно!
Имхо, хэширование пароля ещё на клиенте довольно редкая практика. И его отсутствие вовсе не означает, что пароль будет храниться в БД на сервере в открытом виде.

А если он уходит на сервер в хэшированном виде, то как его выдать в форме? Сохранив оригинал в куках?
1. Пароль в БД пока будет «лететь» в открытом виде — уже будет перехвачен злоумышленниками. А как он там дальше будет храниться (в открытом, закрытом, с солью, с перцем) — уже не важно.
2. В форме в поле ввода пароля — хеш (а не «чистый» пароль). Хеш — вернем из сессси при формировании страницы. (он уже один раз ушел, можем и далее его туда-сюда кидать — хеш обмена). Когда в БД будем класть — можем добавить «соли» и еще раз захешировать. Проверка: if (хеш обмена + «соль» из БД == хеш в БД) пароль верен.
Бред какой-то. Вы хотите сказать, что злоумышленники могут перехватить пароль между, допустим, апачем с php и базой данных? И даже если бы такое случилось, как тут поможет шифрование пароля на клиенте?
Между клиентом (web-браузер ) и сервером (apache).
Между клиентом (web-браузер ) и сервером (apache).

Если нужен такой уровень безопасности при котором это невозможно — надо использовать HTTPS, а не яваскрипт
Шифрование пароля на клиенте поможет не подобрать пароль к другим сервисам, если пароли одинаковые, что не редкость.Собственно та же цель для чего шифруют пароль в базе.
— использование CSS или JS капчи (генерация картинки при помощи кучи div с позиционированием, либо с использованием canvas)
и так далее.

Малоэффективно, если результат будет находится в одной области страницы. На том же spynner можно элементарно получить скриншот области страницы (чтобы там и как не выводилось):

captcha = br.webframe.findFirstElement('img#captchaImg')
captchaCoords = captcha.geometry().getCoords()
br.snapshot(captchaCoords).save('captcha.png')
Вы правы, убрал этот пункт
Ненавижу эту срань!!! Чтоб все «прикручиватели» капчи до конца жизни её вводили!!!
Если бы у вас был свой сайт, то вы бы так не говорили.
Пусть вводит, а мы будем мышкой кликать в нужное место или тапать)))
Благо вариантов всегда X*Y канваса капчи )))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории