Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
К сожелению, без потери безопасности тут не обойтись. :-)
необоснованный поверхностный взгляд.
«на лету» не значит «на клиенте». все остальное есть лишь небольшие технические сложности.
«на лету» не значит «на клиенте». все остальное есть лишь небольшие технические сложности.
Поверхностный? Мы же на хабре, уважаемый. :-) Хотите обоснование? Пожалуйста:
Вдумайтесь, какое счастье будет боту, что при подборе капчи еще и дополнительная помощь от сервера добавится. Одно дело, когда валидация происходит для всей капчи сразу и совсем другое, когда для каждого отдельного символа в процессе набора. Бот просто будет циклически менять символы, если вдруг один из символов сервер забраковал. Вероятность подобрать каптчу с первой же попытки для робота увеличивается в десятки раз. Смысл капчти становится, практически, нулевым.
Вдумайтесь, какое счастье будет боту, что при подборе капчи еще и дополнительная помощь от сервера добавится. Одно дело, когда валидация происходит для всей капчи сразу и совсем другое, когда для каждого отдельного символа в процессе набора. Бот просто будет циклически менять символы, если вдруг один из символов сервер забраковал. Вероятность подобрать каптчу с первой же попытки для робота увеличивается в десятки раз. Смысл капчти становится, практически, нулевым.
Вы не видите леса на фоне деревьев.
Никто и не говорит о проверке ввода каждого символа.
Банально на jquery при нажатии на субмит аяксом проверяем все поля, включая капчу без перезагрузки страницы и, если есть невалидные поля, просто подчеркиваем их.
Никто и не говорит о проверке ввода каждого символа.
Банально на jquery при нажатии на субмит аяксом проверяем все поля, включая капчу без перезагрузки страницы и, если есть невалидные поля, просто подчеркиваем их.
Тогда простите, но в чем новизна такого метода?
Новизны тут нет, я еще пару лет назад такое встречал.
Но все же спасибо автору что напомнил общественности об этом, так как подобные решения на данный момент крайне редки, чрезвычайно редки, невообразимо редки, несмотря на все удобство этого метода (хотя в нем есть и минусы, ниже в одном из комментов я это привел).
Но все же спасибо автору что напомнил общественности об этом, так как подобные решения на данный момент крайне редки, чрезвычайно редки, невообразимо редки, несмотря на все удобство этого метода (хотя в нем есть и минусы, ниже в одном из комментов я это привел).
>>Никто и не говорит о проверке ввода каждого символа.
Ну как это никто не говорит? Сам автора топика это подтвердил, положительно ответив на это уточнение:
kaant.habrahabr.ru/blog/64202/#comment_1786552
Это значит, что exvel все правильно увидел, и, соответственно, разъяснил автору топика.
Ну как это никто не говорит? Сам автора топика это подтвердил, положительно ответив на это уточнение:
kaant.habrahabr.ru/blog/64202/#comment_1786552
Это значит, что exvel все правильно увидел, и, соответственно, разъяснил автору топика.
Может потому, что теряется весь смысл каптчи?
не теряется.
асинхронная валидация капчи до сабмита формы никак не препятствует в выполнении основной задачи капчи — резать ботов.
асинхронная валидация капчи до сабмита формы никак не препятствует в выполнении основной задачи капчи — резать ботов.
За исключением появления дополнительного условия: у пользователя должен быть включён Javascript
Стандартно, в подавляющем большинстве случаев, JS включен.
… многие капчи и так требуют JS, к сожалению. Только вот об этом они не всегда заранее (и вобще) предупреждают, в результате чего проверка просто фэйлится.
Если Javascript выключен, можно использовать старый, обычный способ — проверку введенного пользователем текста каптчи после сабмита формы.
Если Javascript включен — вполне можно использовать асинхронную проверку через AJAX. Это действительно удобно для пользователя. Только на сервере нужно делать дополнительную антифраудную проверку, чтобы перебором не баловались.
Если Javascript включен — вполне можно использовать асинхронную проверку через AJAX. Это действительно удобно для пользователя. Только на сервере нужно делать дополнительную антифраудную проверку, чтобы перебором не баловались.
Разве это не еще одна возможность для ботов? Т.е. бот разве не сможет таким образом тоже узнать, правильно ввёл каптчу или нет и если нет, попробовать подобрать еще раз?
тоесть, вы наивно полагаете, что если не использовать этот метод и проверять каптчу по сабмиту, это помешает боту попробовать подобрать каптчу ещё раз? разумеется, после неправильной попытки, каптча будет обновлена.
ограничьте количество попыток и все снова станет секьюрненько.
Как на счет уменьшить искажения?
Как на счет не использовать в вашей капче I и l?
Как на счет добавить кнопку — обновить капчу, чтобы дало другую?
Как на счет не использовать в вашей капче I и l?
Как на счет добавить кнопку — обновить капчу, чтобы дало другую?
а он и не использует. он вообще не программист и капчи не писал.
топикстартер задал правильный вопрос с позиции юзера: «какого фига из-за хреновой капчи или опечатки приходится повторно заполнять форму?»
ответ на этот вопрос простой — потому что лениво :(
большинство девелоперов не озадачиваются вопросами юзабельности их «монстров», лишь бы ботов отсекало.
топикстартер задал правильный вопрос с позиции юзера: «какого фига из-за хреновой капчи или опечатки приходится повторно заполнять форму?»
ответ на этот вопрос простой — потому что лениво :(
большинство девелоперов не озадачиваются вопросами юзабельности их «монстров», лишь бы ботов отсекало.
1. Дело в том, что, если уменьшить искажение, то можно, теоретически, считать код программными средствами.
2. Я только «ЗА», но многие продолжают использовать эти, и другие, неудобные символы.
3. Нуу, дело в том, что в ней могут также попасться эти символы :)
2. Я только «ЗА», но многие продолжают использовать эти, и другие, неудобные символы.
3. Нуу, дело в том, что в ней могут также попасться эти символы :)
>>(например, как проверка логина и т.п.)
а как проверка логина и т.п. на лету?
а как проверка логина и т.п. на лету?
Например после ухода с поля ввода пароля посылать асинхронный запрос к серверу для проверки того есть ли такой логин в базе. Как, например, сделано в Invision Power Board последних версий.
Тьфу, то есть конечно после ухода с поля логина.
в смысле, при выборе логина для регистрации, аяксом проверять, занят ли уже такой логин?
т.е. у бота будет не одна, а много попыток угадать каждую капчу?
т.е. у бота будет не одна, а много попыток угадать каждую капчу?
генерируется капча и одновременно генерится код, который может быть, например, как-нибудь просто зашифрован. Код можно хранить в переменной, а после подтверждения или обновления удалять/обновлять.
Зачем? Не угадали капчу — генерим новую. По сути программное нажатие кнопки «Обновить картинку».
Но при таком подходе, как мне на первый полусонный взгляд кажется, будет некоторые проблемы с интеграцией той же reCaptch'и, то есть нужно будет писать свой генератор изображений.
p.s. А кстати это идея — сделать сервис вроде recaptcha.net, только с аяксовой проверкой.
Но при таком подходе, как мне на первый полусонный взгляд кажется, будет некоторые проблемы с интеграцией той же reCaptch'и, то есть нужно будет писать свой генератор изображений.
p.s. А кстати это идея — сделать сервис вроде recaptcha.net, только с аяксовой проверкой.
может просто делать более понятные капчи?
Зачем это?
Капчи придумали для того чтобы защититься от ботов, а проверка правильности как раз облегчит им жизнь.
Капчи придумали для того чтобы защититься от ботов, а проверка правильности как раз облегчит им жизнь.
А разве это не было реализовано нигде?
например тут
Кстати на нескольких сайтах видел в работе, действительно удобно…
Больше раздражает когда нет кнопочки «обновить капчу».
например тут
Кстати на нескольких сайтах видел в работе, действительно удобно…
Больше раздражает когда нет кнопочки «обновить капчу».
На Яндекс-Вебмастере есть такая проверка на лету, при добавлении URL: webmaster.yandex.ru/
ненавижу капчи
Хоть и сам разработчик, сам применяю иногда, но технология капчи должна умереть, по моему мнению.
Мне кажется стоит думать не как улучшить капчу, а как от неё избавится.
Сам для себя этот вопрос пока не смог решить, к сожалению.
Хоть и сам разработчик, сам применяю иногда, но технология капчи должна умереть, по моему мнению.
Мне кажется стоит думать не как улучшить капчу, а как от неё избавится.
Сам для себя этот вопрос пока не смог решить, к сожалению.
в таком случае нужно пересажать всех спамеров. Но это не возможно, поэтому нужно искать способы защиты от них.
Как вариант, можно использовать «тестирование» перед регистрацией, т.е. перед тем как зарегистрироваться, пользователь должен ответить на несколько простых вопросов.
Или к примеру как на goha.ru:
Вообще, с картинками самый лучший вариант на мой взгляд.
Или к примеру как на goha.ru:
Вообще, с картинками самый лучший вариант на мой взгляд.
Такое возможно только в том случае, если:
1. Если картинок миллионы, и постоянно добавляются новые. Но в этом случае нужно как минимум собрать столько картинок, чтобы еще небыло проблем с копирайтами, систематизировать их, написать для них вопросы. Потом их нужно где-то хранить, возможно в отдельном файлохранилище или базе данных, а это все ресурсы, производительность системы…
2. Если такие картинки каждый раз генерятся налету (к базовым картинкам-шаблонам добавляются тексты, накладываются фильтры, эффекты и т.д.). Но эти операции по изменению картинок весьма медленны, а, учитывая, что при показе формы нужно сгенерировать десятки таких картинок за раз, можно поставить крест на производительности системы (или выделять выделенный сервер для генерации картинок).
В противном случае бот запросто соберет все варианты картинок (хотя бы даже по их размеру и/или CRC32), и потом будет подставлять по мере необходимости.
1. Если картинок миллионы, и постоянно добавляются новые. Но в этом случае нужно как минимум собрать столько картинок, чтобы еще небыло проблем с копирайтами, систематизировать их, написать для них вопросы. Потом их нужно где-то хранить, возможно в отдельном файлохранилище или базе данных, а это все ресурсы, производительность системы…
2. Если такие картинки каждый раз генерятся налету (к базовым картинкам-шаблонам добавляются тексты, накладываются фильтры, эффекты и т.д.). Но эти операции по изменению картинок весьма медленны, а, учитывая, что при показе формы нужно сгенерировать десятки таких картинок за раз, можно поставить крест на производительности системы (или выделять выделенный сервер для генерации картинок).
В противном случае бот запросто соберет все варианты картинок (хотя бы даже по их размеру и/или CRC32), и потом будет подставлять по мере необходимости.
И на Хабре, и в любых других местах скопления веб-кодеров уже многократно обсуждался вопрос пользы арифметических или визуальных капч.
Дело в том, что провести некоторые арифметические операции — совсем не проблема для бота. А если уж эти числа у вас еще и не на картинке, а просто рядом набраны — вообще разговоров нет.
Сличить картинки с капчи тоже сильно проще, чем распознать символы — картинки сложно исказить до той степени, когда и человеку будет понятно что там нарисовано, и бот не сможет успешно сравнить их с оригиналом.
Дело в том, что провести некоторые арифметические операции — совсем не проблема для бота. А если уж эти числа у вас еще и не на картинке, а просто рядом набраны — вообще разговоров нет.
Сличить картинки с капчи тоже сильно проще, чем распознать символы — картинки сложно исказить до той степени, когда и человеку будет понятно что там нарисовано, и бот не сможет успешно сравнить их с оригиналом.
Зато в один прекрасный день кто-нибудь сочинит такого бота, который станет захватывать изображение с экрана — и тогда на сайте резко появится на пятьдесят тысяч пользователей больше.
То же самое касается капч в формате SVG или в виде джаваскриптовых инструкций для холста <canvas>.
Рекапча радует хотя бы тем, что подсовывает те слова, которые заведомо не распозналися OCR.
То же самое касается капч в формате SVG или в виде джаваскриптовых инструкций для холста <canvas>.
Рекапча радует хотя бы тем, что подсовывает те слова, которые заведомо не распозналися OCR.
iShift, тоже была мысль про флеш, но дело в том, что, в отличие от того же JS, флеш установлен не у всех.
Сложность в том, что реализация будет далеко не такой простой, как поначалу кажется, и то что получится будет тоже не без подводных камней. Итак, нужно:
1. проверять, включен ли Javascript, если не включен — использовать только старый метод, с проверкой каптчи после сабмита формы.
2. сделать AJAX реализацию для проверки введенного пользователем текста каптчи.
3. сделать на сервере антифраудную систему, прочем она и так должна была бы быть и в старом варианте, но в новом — просто обязана быть, так как попыток для перебора вариантов теперь у ботов будет намного больше. соответственно, чтобы избежать перебора вариантов, текст на каптче нужно делать довольно длинным, желательно не менее 8 символов, а вот это уже будет весьма неудобно для пользователя (вот он, подводный камень этого метода!).
А вообще очень хорошее и правильное предложение, это удобно для больших форм регистрации, особенно многостраничных.
На некоторых сайтах я такое уже видел, действительно, очень удобно.
Аналогично имеет смысл проверять логины, почтовые индексы (для тех стран где есть полная база данных), и т.д.
А вот для небольших форм типа логин+пароль+каптча — этот метод явно избыточен IMHO, хотя даже в этом случае может быть использован для «особо быстрых» пользователей.
1. проверять, включен ли Javascript, если не включен — использовать только старый метод, с проверкой каптчи после сабмита формы.
2. сделать AJAX реализацию для проверки введенного пользователем текста каптчи.
3. сделать на сервере антифраудную систему, прочем она и так должна была бы быть и в старом варианте, но в новом — просто обязана быть, так как попыток для перебора вариантов теперь у ботов будет намного больше. соответственно, чтобы избежать перебора вариантов, текст на каптче нужно делать довольно длинным, желательно не менее 8 символов, а вот это уже будет весьма неудобно для пользователя (вот он, подводный камень этого метода!).
А вообще очень хорошее и правильное предложение, это удобно для больших форм регистрации, особенно многостраничных.
На некоторых сайтах я такое уже видел, действительно, очень удобно.
Аналогично имеет смысл проверять логины, почтовые индексы (для тех стран где есть полная база данных), и т.д.
А вот для небольших форм типа логин+пароль+каптча — этот метод явно избыточен IMHO, хотя даже в этом случае может быть использован для «особо быстрых» пользователей.
Уже более года такой метод проверки капчи на лету реализован в моей почте при регистрации О_о
Кому интересно посмотреть реализацию:
http://mail.president.org.ua/go/register.php?ru
Кому интересно посмотреть реализацию:
http://mail.president.org.ua/go/register.php?ru
P.S.
Только вот при отключении Javascript — кнопка Зарегестрировать не активна, и появляется сообщение:
Некоторые динамические элементы этой страницы не могут корректно отображаться и выполняться, из-за того что в Вашем браузере отключены функции Javascript.
Как верно заметил tvv, необходимо проверять на использование Javascript.
Только вот при отключении Javascript — кнопка Зарегестрировать не активна, и появляется сообщение:
Некоторые динамические элементы этой страницы не могут корректно отображаться и выполняться, из-за того что в Вашем браузере отключены функции Javascript.
Как верно заметил tvv, необходимо проверять на использование Javascript.
я правильно понимаю — введенные цифры отправляются на сервер, там проводится сверка и, в случае правильного ответа, отсылается подтверждение правильного ввода?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проверка правильности ввода капчи налету