Если честно, я обзор имеющихся аналогичных решений не делал. За ссылку спасибо, посмотрел, но мне кажется, у меня решение значительно проще (при той же функциональности), разве что прогресс-бара нет, как у них, но его не проблема добавить :)
Начну с конца: как пользоваться. В статье, собственно, про это написано. Размещаете на своем сайте страничку, с помощью которой ваш контрагент может проверить подпись. Для изготовления подписи сначала хешируете документ, а потом подписываете хеш (возможно, с некоей дополнительной информацией) приватным ключом. Сам документ и полученную таким образом подпись отсылаете контрагенту. Он заходит на страничку проверки на вашем сайте, загружает документ и подпись. Ваш сервер расшифровывает подпись с помощью открытого ключа, делает хеш загруженного документа и сверяет его с расшифрованным хешем. В случае успеха сообщает, что подпись подлинная.
Теперь о юридической стороне. В соответствии с пунктом 2 статьи 6 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» неквалифицированная электронная подпись признается равнозначной собственноручной подписи в случае достигнутого соглашения между участниками электронного взаимодействия. Думаю, что вы с контрагентом должны заключить некое письменное соглашение, в котором написано, что вы взаимно признаете электронные подписи друг друга и описан механизм, который я изложил выше.
На серверной стороне таймаут организовывать не всегда удобно, особенно в асинхронных средах типа nodejs, можно нечаянно затормозить основной цикл событий. Кроме того, на серверной стороне придется сначала лезть в базу, аутентифицировать клиента и только потом (в случае неудачи) делать паузу, в то время как на клиенте пауза методом PoW делается до отправки запроса и не нагружает сервер.
PoW на клиенте производится до отправки запроса на сервер, никакого открытого соединения. По поводу того, что против лома нет приема — так оно, с этим никто не спорит.
Кстати насчет ботов. Я уже давно не использую тег <form>, а просто отправляю значения всех полей на сервер fetch-запросом. И все боты нервно курят в сторонке.
Проблема все же не столько в ботах (от них защититься более или менее понятно как), а в живых людях, которые поставили себе задачу сломать вашу капчу. Написать программу, распознающую вашу картинку, под силам даже школьнику (ну ладно, первокурснику). А уж один и тот же ответ на вопрос в течение года вообще от хакера никак не защищает. Ну вы и сами это понимаете.
Трудно сказать. Смотря какая капча (насколько она поддается взлому с помощью ИИ), смотря какая реализация моего решения (алгоритмы PoW могут быть очень и очень разными). Масштабного сравнительного тестирования же никто не делал.
Хоть Selenium, хоть другие средства автоматизации — предложенное решение резко снижает количество попыток брутфорса или авторегистраций в секунду. Полной защиты от ботов это не дает, конечно (впрочем, как и капча, которая сегодня взламывается за сопоставимое время).
Против этого хорошо работает отправка инициализирующего значения с сервера (с записью его в сессию), как и в случае традиционной капчи. Даже в таком варианте PoW будет удобнее для пользователя, потому что ему не надо будет ничего вводить.
А какая разница, где его считать? Время же все равно для этого потребуется. Нет, ну ясно, что можно считать на квантовом компьютере в МГУ :) Но я и пишу, что это защита не от суперхакера с супероборудованием, а лишь для простых случаев.
Про headless браузеры не в курсе, если честно. На сервер же все равно контрольное число должно прийти, хоть какой браузер. Можно просто сокет с помощью С на клиентской стороне открыть и послать запрос на сервер вообще без всякого браузера, это не важно.
Смысл брутфорса же в том, что мы перебираем разные пароли. Тогда и контрольные числа будут разные, ломать с одним и тем же контрольным числом не получится. Если речь о защите от автоматических постов, можно, как вы пишете, с сервера (как и при реализации традиционной капчи) отправлять некую соль, записывая ее одновременно в сессию. При проверке контроьного числа брать эту соль из сессии.
На ноде можно, конечно, запустить что-то на пару секунд, и по окончании этих секунд вызвать коллбэк, но зачем такой геморрой? Пауза на клиенте с идеей PoW гораздо проще, мне кажется.
Задержка на стороне сервера не всегда удобно реализуема, например, на nodejs (в отличие от php, где можно синхронно любую паузу делать).
Про post-запрос не понял, на сервер ведь надо будет в любом случае отправлять контрольное число, вычисленное по алгоритму PoW, а вычисление этого числа на клиенте потребует времени. Тут не важно, curl'ом мы отправляем или браузером: сервер при неверном контрольном числе просто отвергнет такой запрос.
Ну почему, время тайматуа, обеспечиваемое этим скриптом, сопоставимо со временем решения традиционной капчи человеком (или взлома ее клиентским софтом). А другие проблемы — это брутфорс логина/пароля.
Можно, например, в цикле while в моем скрипте опрашивать время, прошедшее с начала его выполнения, и при превышении времени более 5 с, например, выдавать традиционную капчу. Ну и понятно, что подбор количества бит, совпадения которых мы требуем в итоговом хеше, будет меняться со временем, ориентируясь на средние по производительности клиентские девайсы. Но я согласен с вами, предложена лишь идея, которую можно дорабатывать.
Так не только в ботах же решаемая моим вариантом проблема, а и в людях-хакерах, перед которыми стоит задача написать клиентский код, брутфорсящий сервис авторизации, например. Ваш вариант отсеивает ботов, но не отсеивает злонамеренных людей.
Если честно, я обзор имеющихся аналогичных решений не делал. За ссылку спасибо, посмотрел, но мне кажется, у меня решение значительно проще (при той же функциональности), разве что прогресс-бара нет, как у них, но его не проблема добавить :)
Начну с конца: как пользоваться. В статье, собственно, про это написано. Размещаете на своем сайте страничку, с помощью которой ваш контрагент может проверить подпись. Для изготовления подписи сначала хешируете документ, а потом подписываете хеш (возможно, с некоей дополнительной информацией) приватным ключом. Сам документ и полученную таким образом подпись отсылаете контрагенту. Он заходит на страничку проверки на вашем сайте, загружает документ и подпись. Ваш сервер расшифровывает подпись с помощью открытого ключа, делает хеш загруженного документа и сверяет его с расшифрованным хешем. В случае успеха сообщает, что подпись подлинная.
Теперь о юридической стороне. В соответствии с пунктом 2 статьи 6 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» неквалифицированная электронная подпись признается равнозначной собственноручной подписи в случае достигнутого соглашения между участниками электронного взаимодействия. Думаю, что вы с контрагентом должны заключить некое письменное соглашение, в котором написано, что вы взаимно признаете электронные подписи друг друга и описан механизм, который я изложил выше.
На серверной стороне таймаут организовывать не всегда удобно, особенно в асинхронных средах типа nodejs, можно нечаянно затормозить основной цикл событий. Кроме того, на серверной стороне придется сначала лезть в базу, аутентифицировать клиента и только потом (в случае неудачи) делать паузу, в то время как на клиенте пауза методом PoW делается до отправки запроса и не нагружает сервер.
PoW на клиенте производится до отправки запроса на сервер, никакого открытого соединения. По поводу того, что против лома нет приема — так оно, с этим никто не спорит.
Как раз моя статья посвящена борьбе именно с хакерами, а не с ботами.
Кстати насчет ботов. Я уже давно не использую тег
<form>, а просто отправляю значения всех полей на сервер fetch-запросом. И все боты нервно курят в сторонке.Так можно вообще всю форму отправки сообщения нарисовать с помощью createElement(). Но не в ботах основная проблема.
Проблема все же не столько в ботах (от них защититься более или менее понятно как), а в живых людях, которые поставили себе задачу сломать вашу капчу. Написать программу, распознающую вашу картинку, под силам даже школьнику (ну ладно, первокурснику). А уж один и тот же ответ на вопрос в течение года вообще от хакера никак не защищает. Ну вы и сами это понимаете.
Трудно сказать. Смотря какая капча (насколько она поддается взлому с помощью ИИ), смотря какая реализация моего решения (алгоритмы PoW могут быть очень и очень разными). Масштабного сравнительного тестирования же никто не делал.
Так не придумал, а позаимствовал :)
Не всегда это удобно, особенно в асинхронных средах типа nodejs. На клиентской стороне проще.
Хоть Selenium, хоть другие средства автоматизации — предложенное решение резко снижает количество попыток брутфорса или авторегистраций в секунду. Полной защиты от ботов это не дает, конечно (впрочем, как и капча, которая сегодня взламывается за сопоставимое время).
Против этого хорошо работает отправка инициализирующего значения с сервера (с записью его в сессию), как и в случае традиционной капчи. Даже в таком варианте PoW будет удобнее для пользователя, потому что ему не надо будет ничего вводить.
А какая разница, где его считать? Время же все равно для этого потребуется. Нет, ну ясно, что можно считать на квантовом компьютере в МГУ :) Но я и пишу, что это защита не от суперхакера с супероборудованием, а лишь для простых случаев.
Про headless браузеры не в курсе, если честно. На сервер же все равно контрольное число должно прийти, хоть какой браузер. Можно просто сокет с помощью С на клиентской стороне открыть и послать запрос на сервер вообще без всякого браузера, это не важно.
Смысл брутфорса же в том, что мы перебираем разные пароли. Тогда и контрольные числа будут разные, ломать с одним и тем же контрольным числом не получится. Если речь о защите от автоматических постов, можно, как вы пишете, с сервера (как и при реализации традиционной капчи) отправлять некую соль, записывая ее одновременно в сессию. При проверке контроьного числа брать эту соль из сессии.
На ноде можно, конечно, запустить что-то на пару секунд, и по окончании этих секунд вызвать коллбэк, но зачем такой геморрой? Пауза на клиенте с идеей PoW гораздо проще, мне кажется.
Ну моя идея решает задачу не столько защиты от ботов (скрытое поле это классическое решение), сколько защиты от хакера и брутфорса.
Задержка на стороне сервера не всегда удобно реализуема, например, на nodejs (в отличие от php, где можно синхронно любую паузу делать).
Про post-запрос не понял, на сервер ведь надо будет в любом случае отправлять контрольное число, вычисленное по алгоритму PoW, а вычисление этого числа на клиенте потребует времени. Тут не важно, curl'ом мы отправляем или браузером: сервер при неверном контрольном числе просто отвергнет такой запрос.
Ну почему, время тайматуа, обеспечиваемое этим скриптом, сопоставимо со временем решения традиционной капчи человеком (или взлома ее клиентским софтом). А другие проблемы — это брутфорс логина/пароля.
Можно, например, в цикле while в моем скрипте опрашивать время, прошедшее с начала его выполнения, и при превышении времени более 5 с, например, выдавать традиционную капчу. Ну и понятно, что подбор количества бит, совпадения которых мы требуем в итоговом хеше, будет меняться со временем, ориентируясь на средние по производительности клиентские девайсы. Но я согласен с вами, предложена лишь идея, которую можно дорабатывать.
Так не только в ботах же решаемая моим вариантом проблема, а и в людях-хакерах, перед которыми стоит задача написать клиентский код, брутфорсящий сервис авторизации, например. Ваш вариант отсеивает ботов, но не отсеивает злонамеренных людей.