Comments 74
Больше похоже на CSRF защиту, чем на каптчу.
Интересная штука. Но такое решение - довольно легко обойти кодом.
Мы использовали более интересный алгоритм внутри WASM. Изначально идею взяли из этой библиотеке, но изменили алгоритм.
А как обойти кодом?
А какая разница, где его считать? Время же все равно для этого потребуется. Нет, ну ясно, что можно считать на квантовом компьютере в МГУ :) Но я и пишу, что это защита не от суперхакера с супероборудованием, а лишь для простых случаев.
Про headless браузеры не в курсе, если честно. На сервер же все равно контрольное число должно прийти, хоть какой браузер. Можно просто сокет с помощью С на клиентской стороне открыть и послать запрос на сервер вообще без всякого браузера, это не важно.
Смысл теряется, когда хакер, вычислив алгоритм, в своем скрипте генерирует необходимые пары str + pow заранее, а потом без ожидания отправляет.
Против этого хорошо работает отправка инициализирующего значения с сервера (с записью его в сессию), как и в случае традиционной капчи. Даже в таком варианте PoW будет удобнее для пользователя, потому что ему не надо будет ничего вводить.
Rainbow tables, да.
Но если варьировать позицию подстроки, то это не поможет.
Прошу прощения, хабр запретил мне отвечать на прошлые темы( причин не знаю)У вас есть статья про изготовление эцп( не квалифицированной) подскажите пожалуйста вот я сгенерировал приватный и публичный ключи как потом этим пользоваться, просить отразить это в каком то акте, договоре? Чтобы не квалифицированная эцп имело юридическую силу?Интересует пример устройства на работу удаленно, как мне пользоваться такой подписью при докумобороте.Буду признателен если дополните сведения.Спасибо.
Начну с конца: как пользоваться. В статье, собственно, про это написано. Размещаете на своем сайте страничку, с помощью которой ваш контрагент может проверить подпись. Для изготовления подписи сначала хешируете документ, а потом подписываете хеш (возможно, с некоей дополнительной информацией) приватным ключом. Сам документ и полученную таким образом подпись отсылаете контрагенту. Он заходит на страничку проверки на вашем сайте, загружает документ и подпись. Ваш сервер расшифровывает подпись с помощью открытого ключа, делает хеш загруженного документа и сверяет его с расшифрованным хешем. В случае успеха сообщает, что подпись подлинная.
Теперь о юридической стороне. В соответствии с пунктом 2 статьи 6 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» неквалифицированная электронная подпись признается равнозначной собственноручной подписи в случае достигнутого соглашения между участниками электронного взаимодействия. Думаю, что вы с контрагентом должны заключить некое письменное соглашение, в котором написано, что вы взаимно признаете электронные подписи друг друга и описан механизм, который я изложил выше.
Особенно хороша она будет на baterry-powered устройствах. С которых нынче сидит большая часть пользователей интернета.
Смысл капчи это проверить что на той стороне человек а не вычислительная система, и это PoW решить ни как не сможет.
То что вы предложили, это просто таймауты при валидации, но таймауты в разных вариациях уже везде используют.
У капчи много смыслов, проверка «человечности» ведь важна не сама по себе, а для решения какой-то конкретной задачи. Про таймаут согласен, я просто предложил одно из решений реализации таймаута на клиентской стороне, которое не обходится кодом на клиенте.
Пожалуй, одна из самых популярных целей капчи -- ограничить автоматическую использования формы (создание аккаунтов, рассылка сообщений, защита от спама и т.п.).
То есть, в данном случае такая "капча" эту проблему не решает.
Честно говоря, я прикинул и не знаю какие другие проблемы может решить этот вариант.
Ну почему, время тайматуа, обеспечиваемое этим скриптом, сопоставимо со временем решения традиционной капчи человеком (или взлома ее клиентским софтом). А другие проблемы — это брутфорс логина/пароля.
Верно. Проблема не в скорости создания левых аккаунтов, а в автоматизации процесса.
Если сотню аккаунтов можно создать за 10 минут или за 15 минут, то это не так критично. Фишка в том, что бы это автоматизировать.
Потом можно этими аккаунтами рассылать спам на форуме или до чего ещё руки дотянутся. Пароли ведь известные.
А чем это лучше таймаута на серверной стороне? Он тоже не обходится кодом на клиенте.
На серверной стороне таймаут организовывать не всегда удобно, особенно в асинхронных средах типа nodejs, можно нечаянно затормозить основной цикл событий. Кроме того, на серверной стороне придется сначала лезть в базу, аутентифицировать клиента и только потом (в случае неудачи) делать паузу, в то время как на клиенте пауза методом PoW делается до отправки запроса и не нагружает сервер.
самая простая и тупая капча - "какой сейчас год" и 4 цифры ввода - но длину ввода не ограничивать.. и в поле ввода образец "1913"
90% ботов понимают вариант "сколько будет 2+3" и не понимают полностью текстовый вопрос без цифр. это уже ИИ нужен или бота заранее на такой вопрос настроить.
но у меня работает. за два года ни одного бота не прошло. 50% ботов тупо берут ответ из подсказки в форме :) я их потом в логах вижу.
1913
11111
1111111
12345
123456
так сказать - решение на коленке.
и да - после третьей попытки fail2ban отправляет IP в бан на неделю.
Так не только в ботах же решаемая моим вариантом проблема, а и в людях-хакерах, перед которыми стоит задача написать клиентский код, брутфорсящий сервис авторизации, например. Ваш вариант отсеивает ботов, но не отсеивает злонамеренных людей.
согласен.
если стоит вопрос сломать вход в конкретном сайте - то с привлечением людей быстро сломают.
а вот если вопрос - написать универсальный код для взлома - тут на порядок сложнее. вопрос текстовый, ответ цифровой, подсказка цифровая. стандартный бот анализирует что может - и получает бан.
но конечно - вопрос времени. пока ни одного бота не прошло. все-таки это не 22 порт, где китайские сервера дают 10-20 запросов в секунду.
У меня в 2005 году на форуме была подобная самописная защита, сложить все красные числа и задачка вида 5+3*2-1, при этом некоторые цифры были зеленые и черные, но две красные. Очень успешно все это работало года 3-4, потом сломали! Форум не очень популярный, так что сломали не прицельно (да и спам не был прицельным).
Предложенный в статье метод целей своих не достигнет, потому как спамеры заплатят компьютерным временем. Они платят и индусам за прохождение капчей. До кучи некоторые антивирусы скрипты похожие на майнинг прибивают, люди просто не смогут зайти.
КМК капча скоро умрет сама собой, потому что ИИ сравнялся уже по капчеразгадывательным возможностям с человеком, и сделать капчу проходимую всеми людьми и непроходимую ботами невозможно.
Сейчас спамеры платят порядка 2р за капчу, это 3 цента. Будут ли пользователи платить за регистрацию хотя бы 10р, не везде, но пусть. Сервиса на такие микротранзакции пока что, общедоступного (чтобы у всех уже был) и общеудобного (чтобы оплатить было быстрее и удобнее чем разгадывать) нет.
А так, пайвол это тема будущего.
Если надо просто решить проблему брут-форса, то достаточно сделать задержку на стороне сервера при неудачных попытках.
Иначе js можно обойти обычным POST-запросом через тот же curl.
Задержка на стороне сервера не всегда удобно реализуема, например, на nodejs (в отличие от php, где можно синхронно любую паузу делать).
Про post-запрос не понял, на сервер ведь надо будет в любом случае отправлять контрольное число, вычисленное по алгоритму PoW, а вычисление этого числа на клиенте потребует времени. Тут не важно, curl'ом мы отправляем или браузером: сервер при неверном контрольном числе просто отвергнет такой запрос.
Я про то, что можно отправлять одно и то же число, которое было вычислено уже заранее один раз.
Иначе надо будет хранить использованные варианты на стороне сервера.
P.S.: уже не помню как делать серверную часть на NodeJS. Но разве там нет того же setInterval, который через callback отправит 200? Или там совсем всё по-другому? Я просто плохо знаком с этим.
Смысл брутфорса же в том, что мы перебираем разные пароли. Тогда и контрольные числа будут разные, ломать с одним и тем же контрольным числом не получится. Если речь о защите от автоматических постов, можно, как вы пишете, с сервера (как и при реализации традиционной капчи) отправлять некую соль, записывая ее одновременно в сессию. При проверке контроьного числа брать эту соль из сессии.
На ноде можно, конечно, запустить что-то на пару секунд, и по окончании этих секунд вызвать коллбэк, но зачем такой геморрой? Пауза на клиенте с идеей PoW гораздо проще, мне кажется.
Там соль/hash от полей ввода зависит, получается. Я этот момент пропустил.
Пожалуй, такой use-case ещё куда ни шло. Но тут проще по IP блок поставить на мой взгляд. Разница в том, что в варианте PoW можно всё сделать на клиенте.
Пауза на клиенте с идеей PoW гораздо проще, мне кажется.
Пауза — это открытое соединение, ценный ресурс. Гораздо проще по достижении лимита вплоть до исчерпания времени паузы все запросы отбивать с кодами 429 или 503 и установкой заголовка Retry-After для индикации оставшегося времени ожидания, а особо упорных (которые продолжают слать запросы до его истечения) — банить жёстко.
Хотя, честно говоря, все эти ожидания и прочие лимиты, включая PoW мало помогают против "продвинутых" ломателей — ко мне приходили целые полчища ботов, притворялись полноценными клиентами (js, все дела) — в логах это видно как один-два запроса в секунду на логин, с одного IP пробуют ровно одну пару, максимум две — и он не пытается больше в ближайшие сутки. Да, скорость перебора так себе, но оно ж кушать не просит и не торопится, а банить — по какому критерию? Настоящие пользователи тоже ошибаются, в час обычно парочка пробует с пяток имен-паролей к своим аккаунтам — потому что забывают либо пароли либо как именно зарегистрированы.
Интересная идея!
Я в своё время по примеру этой статьи сделал поле <input name="email"> и скрыл его через CSS. Человеческие посетители оставляли его пустым, а боты заполняли.
Подобные решения, хоть и легко обходятся при желании, но зато хорошо защищают автоматизированных ботов. Я на своём сайтике делал капчу из двух галок - для её прохождения нужно было поставить только одну (там прям написано было, какую ставить). Боты ставили или обе или ни одной. После этого кол-во спамных комментариев от ботов сократилось почти до нуля.
Помимо ботов это может сделать автозаполнение форм. В приведенной статье используется поле с другим названием.
уже не работает в 50% случаев
бот анализирует (что увидит пользователь) и не заполняет скрытые поля
ps
50% - из моих логов видно статистику
у меня до сих пор работает <input name=url /> скрытый в css от хуманов, лог ботов уже километровый за 7 лет. как перестанет работать, воткну капчу
можно вопрос картинкой сделать :)
конечно - человек и вопрос прочитает и ответ правильный сделает.
а как бот вопрос прочитает? да, OCR есть. как именно бот узнает, в какой картинке вопрос?
прогонять все картинки через OCR.....замучается пыль глотать ©
надо целый модуль спамерам уже писать - что вот в этой картинке вопрос, его надо через OCR прогнать и вытащить этому вопросу правильный ответ из своей базы
ps
все-таки надо разделять спамеров и взломщиков. спамеры в основном по площадям работают и иногда дописывают своего бота, что бы % размещения был выше.
а взлом - другое дело. тут уже целевая атака на конкретную защиту.
pss
и да - у меня ответ на вопрос 1го января ежегодно сам меняется :)
Проблема все же не столько в ботах (от них защититься более или менее понятно как), а в живых людях, которые поставили себе задачу сломать вашу капчу. Написать программу, распознающую вашу картинку, под силам даже школьнику (ну ладно, первокурснику). А уж один и тот же ответ на вопрос в течение года вообще от хакера никак не защищает. Ну вы и сами это понимаете.
:)
там мы же с не хакерами боремся. а с тупыми программерами, которые создают тупых ботов.
мой рекорд - 500 писем в час (через форму) на тему открытия торгового центра в Пекине (Китай), текст на иероглифах (перевел через гугль), email случайно сгенерирован, IP каждый раз разный.
там реальный был только адрес и телефон в Китае. кто-то запустил рекламную компанию с таргетингом по всем миру и без анализа, куда он её уже отправил. и пошел пиво пить.
пришлось ваять защиту на коленке.
и защиту от наличия иероглифов в тесте сообщения добавил, сообщение в форме на иероглифах теперь в принципе не отправляется
Идея интересная, но в текущем виде защита только от script kiddies
Основная проблема - разница в производительности недорогого смартфона 3-4 летней давности и современных ASIC майнеров "числодробилок", тут либо на смартфоне будет задержка в несколько минут и несколько процентов батареи, либо защита очень слабая.
Можно, например, в цикле while в моем скрипте опрашивать время, прошедшее с начала его выполнения, и при превышении времени более 5 с, например, выдавать традиционную капчу. Ну и понятно, что подбор количества бит, совпадения которых мы требуем в итоговом хеше, будет меняться со временем, ориентируясь на средние по производительности клиентские девайсы. Но я согласен с вами, предложена лишь идея, которую можно дорабатывать.
Я так и не понял как это защищает от ботов.
Я завожу Selenium, через селекторы заполняю поля, нажимаю "отправить". Что не сработает то?
Идея-то интересная, но если уж всё равно надо ждать N секунд, то проще банально сделать sleep(N) на сервере :)
Не всегда это удобно, особенно в асинхронных средах типа nodejs. На клиентской стороне проще.
sleep не получится - так как бот умеет динамически IP менять, пока один IP будет ждать, с другого зайдут.
тут именно задержка на клиентской машине от ввода данных до возможности их отправить. - придется ждать в любом случае.
а если еще кнопку "отправить" рисовать JS через 1 сек = то 90% ботов вообще выпадет, они тупо через парсинг html работают, без запуска JS и кнопку они вообще не увидят
Могу дополнить, что данный механизм можно усовершенствовать, повысив производительность вычислений для "нормального" клиента делая их внутри WASM. Скорость вычислений будет в разы выше, а значит можно поднять сложность алгоритма и добавив тем самым сложности недобросовестным переборщикам.
Также хорошей практикой будет вынести вычисления в отдельный воркер, что бы не блокировать основной поток.
Согласно моему опыту, лучшая капча - это отслеживание браузерных событий. Запись событий должна соответствовать определенному паттерну: прокрутка вниз, движения мыши, клики по полям ввода.
Мне кажется или капча лучше отсеивает ботов чем ваше решение
С такой инновацией я со своего старого бука никуда не зайду. Или зайду, но полчаса будет хеш считать :)
Есть готовые решения Proof of Work? Вы что-то искали? Можете поделиться вариантами если что-то нашли?
Вот что мне удалось найти: https://github.com/sequentialread/pow-captcha пока только этот вариант
Если честно, я обзор имеющихся аналогичных решений не делал. За ссылку спасибо, посмотрел, но мне кажется, у меня решение значительно проще (при той же функциональности), разве что прогресс-бара нет, как у них, но его не проблема добавить :)
Вот еще одна капча найдена https://github.com/jsavoie/proof-of-work-login
У всех у них один недостаток они работают по типу POW что потребляет процессор, быстрые процессоры вычисляют намного быстрее, чем медленные. И в итоге на старом ПК POW работает 1 минуту, а на новом 1 секунду. Но есть другие POW с упором на память и называются Memory-bound function, функция с привязкой к памяти https://dev.abcdef.wiki/wiki/Memory-bound_function Вот таких алгоритмов мне пока для php и js не удалось найти. Если что-то найдете дайте мне знать.
PoW вместо капчи