LINUX.ORG.RU

Хочу сделать регистрацию без email, посоветуйте вычислительную задачку для браузера

 


3

1

Возникла идея сделать один мелкий сайтик с юзерами, а там регистрация. В силу того, что я не понял, зачем мне для регистрации просить email, да ещё гонять трафик и снюхиваться со всякими email-серверами, то емейла/телефона при регистрации не будет.

Но минимально защититься от спама хочется. Самодельный генератор капчи есть, написанный на крестах, который генерит капчу за 1..2 мсек, но всё же простейший ДДОС с кучей запросов на эту капчу быстро ушатает генератор и исчерпает запасы качп в базе, а завязываться на доступность гугловых рекапч не хочется, да и лишние коннекты ваять, когда генератор уже есть. Неважно насколько он крутой, важно что нейросеть у атакующего тяжелее этого генератора.

Поэтому возникла идея поставить капчу позже, а сначала попросить юзера доказать, что он выдержал некий proof-of-time алгоритм (и возможно proof-of-memory с микрокодом типа как в RandomX, но похрен). Proof-of-time - это, короче, пруф того, что ты регался не менее 5 секунд. Реализуется как 5 обменов с браузерным JS, между которыми не может быть менее секунды, причём сервер не утруждает себя хранением состояния, чтобы выдерживать SYN-flood-атаки (запустили регистрацию 100500 раз и свалили).

Посылаем браузеру структуру данных, с прошитым в ней миллисекундным timestamp, изменить который без разрушения структуры невозможно, просим прислать нам структуру обратно через секунду и забываем про факт посылки. Когда через секунду браузер присылает эту структуру назад, мы смотрим на прошитый в ней timestamp и понимаем, прошло ли достаточно времени для её возврата нам или юзер читерит. Далее генерим аналогичную структуру для второго состояния и так далее, пока не получим возврат на последнюю посылку. То есть, нужен алгоритм генерации такой структуры данных, валидность которой наступает в будущем.

На экране юзера такая регистрация будет выглядеть как прогресс-бар, который тупо доходит до 100% за 5 секунд.

Простейший вариант - тупо зашифровать своим секретным ключом AES128 строчку вида <256-bit-random-salt> и на входе расшифровывать обратно, сверяя timestamp. Но может есть чё попроще или наоборот поумнее, понадёжнее или «так же надёжно, но вычислительно сильно дешевле»?

А ещё были такие идеи на тему proof-of-memory: генерим на сервере 512 байт данных и запоминаем, а юзеру отправляем 1 МБ, где в случайных местах замешаны эти 512 байт. Потом посылаем юзеру 10 запросов в рандомные места этого 1 МБ куска, ответы на большинство из которых нас не волнуют. Пара запросов, которые попадают в «наши данные» мы проверяем, но юзер вынужден помнить весь 1 МБ, не зная где среди них лежат наши данные. Потом я прочитал про RandomX и понял, что это содомия, а нормальные чуваки просто генерят какой-то псевдомашинный код на тему перемещения блоков в памяти, который (код) юзер физически состоянии исполнить только имея, скажем, 4 гига оперативы - короче надо ещё про это почитать! Жаба конечно задушит каждому дебилу по 1 МБ рассылать. Нужно, чтобы псевдокод для исполнения у жертвы не мог вернуть верный результат без использования настоящих 16 мегабайт памяти, но чтобы результат работы кода был мизерным и был известен серверу прямо в момент генерации этого рандомного дьявольского псевдокода.



Последнее исправление: igloev (всего исправлений: 4)

Ответ на: комментарий от igloev

Опять кому-кают? ;)

Да что ж за лентяи-то такие, за вас в толковый словарь ходить? ;)

 1. кому-чему являющийся должником кого-либо, обязанный уплатить что-либо кому-либо ◆ Я вам должен три рубля. ◆ Илья Ильич вам должен десять тысяч по заёмному письму? И. А. Гончаров, «Обломов»

 2. с инф. обязан сделать что-либо ◆ Служащие должны вовремя являться на работу. ◆ Я должен был, прежде чем объясняться в любви, посвятить её в свою тайну! А. П. Чехов, «Женщина без предрассудков»

 3. с инф. о том, что непременно, неизбежно совершится, произойдёт ◆ Затмение должно наступить в три часа.

 4. с инф. служит для выражения вероятности, предполагаемой неизбежности какого-нибудь события ◆ Она должна была прийти ещё вчера. ◆ Подождите, он должен вернуться к обеду.

Сами посчитаете, в скольких пунктах здесь «кому»? ;)

mertvoprog
()
Ответ на: комментарий от aureliano15

Отсутствие http?

Да, и не только — в запущенных случаях ниже TLS1.2 вообще ничего не работает, даже сертификаты обновлять на старых системах бесполезно.

то же самое на большинстве сайтов

Массовость фашизма как-то его оправдывает? ;)

там, где есть логин/пароль или другая передача конфиденциальных данных

На педивикии это всё опционально, там просто публичные текстовые статьи. И на большинстве информационных сайтов тоже. Обычному пользователю мало где нужно регистрироваться и тем более гонять что-то конфиденциальное и при этом непубличное. Но https-фашизм навязывается абсолютно всему вебу. Не удивимся, если уже через пару лет Google начнёт ущемлять не-https-фашистские сайты в своём браузере, поисковике и марионеточном браузере (лисе).

почему это плохо, даже когда острой необходимости в шифровании нет?

Очевидно же, потому что совместимость ломается. Сайты становятся недоступны для браузеров без реализаций свежайших шифров и сертификатов. При том, что остальные-то технологии с конца прошлого века не менялись. Выглядит как подготовительный этап к тому, чтобы сломать web в корне и перевести на новый стек технологий (в принципе, WA+WebGL уже таковым являются, но для всего подряд их пока не юзают).

Что обходится?

Требование поддержки шифрования на клиенте. Запускается stunnel на удалённой машине, натравленный на определённый https-фашистский хост/порт, к нему подключается с нешифрованной стороны клиент. Также через всякие шебпрокси можно обходить, но там слишком много MitM.

mertvoprog
()
Ответ на: комментарий от mertvoprog

Да, и не только в запущенных случаях ниже TLS1.2 вообще ничего не работает, даже сертификаты обновлять на старых системах бесполезно.

TLS1.2 появился в 2008 году. Это насколько же система должна была устареть, чтобы его не поддерживать?! Как там вам в 0-х живётся? У нас в 20-х коронавирус, санкции и глобальное потепление!

На педивикии это всё опционально, там просто публичные текстовые статьи. И на большинстве информационных сайтов тоже.

Согласен. На таких сайтах можно было бы поддерживать и обычный http хотя бы для незалогинившихся. Но, с другой стороны, нет худа без добра: массовое шифрование всего и вся затрудняет слежку.

Очевидно же, потому что совместимость ломается. Сайты становятся недоступны для браузеров без реализаций свежайших шифров и сертификатов.

Т. е. выпущенных в 0-е годы и раньше. Не вижу проблемы.

Запускается stunnel на удалённой машине, натравленный на определённый https-фашистский хост/порт, к нему подключается с нешифрованной стороны клиент.

Понял. А зачем так сложно, когда можно просто обновить браузер?

aureliano15 ★★
()
Ответ на: комментарий от igloev

Электричества.

Этот цикл будет бесконечным, какой забавный бот ;)

mertvoprog
()
Ответ на: комментарий от mertvoprog

Это не идеализм, а объективная реальность.

Идеализм. В реальности почтовые клиенты юзают полтора психа, все ходят в гмейлы и мейлы. Плохо ты знаком с реальностью.

igloev
() автор топика
Ответ на: комментарий от igloev

Ну так контролируют свои данные полтора психа, остальные сидят на игле облаков и соцсетей (даже те, кто в начале 00-х ещё не сидели). И это необходимо решать, чтобы массами не манипулировали одним махом. И решать необходимо силами каждого отдельного шарящего индивидуума, иначе не взлетит.

mertvoprog
()
Ответ на: комментарий от mertvoprog

Ну так контролируют свои данные полтора психа, остальные сидят на игле облаков и соцсетей

Бывает. А ты тут при чём и зачем решил это обсудить.

igloev
() автор топика
Ответ на: комментарий от igloev

А ты тут при чём

Несём «психоз» в массы, очевидно же.

зачем решил это обсудить

Низачем, это Вы скатили обсуждение в данную степь вместо того, чтобы не мыслить субъективистски.

mertvoprog
()

Прикрутил бы какой-нибудь oauth, нахрена вообще с регистрацией и безопасностью возиться?

Dred ★★★★★
()
Ответ на: комментарий от Dred

Прикрутил бы какой-нибудь oauth, нахрена вообще с регистрацией и безопасностью возиться?

Проще. Капчу ввёл и готово. А с оаутх надо чтобы у юзера был внешний акк, чтобы он его желал светитьв нашем сервисе и т.п. Это же как через почту регать.

igloev
() автор топика
Ответ на: комментарий от Harald

email не нужен будет, и логин-пароль тоже

50-летний алканавт, водитель фуры, не осилит твои сраные сертификаты.

igloev
() автор топика
Ответ на: комментарий от Harald

зачем тебе такие юзеры :)

Хочу сделать сервис типа «вопрос-ответ», а он может шарить в дизелях или маслах. Глупо терять знания из-за неудобств простых алкашей.

igloev
() автор топика

это какой-то лютый сайферпанк. попроси браузер сгенерировать 5 случайных чисел, с сидом равным текущему времени в unixtime. алгоритм генерации чисел должен быть обратим, но генерация следующего числа должна быть тяжелее чем откат на предыдущее. когда браузер пришлёт ответ, проверь какое случайное число было 5 итераций назад, из сида равного unixtime-5 должно получаться это число.

но если ты привязываешься ко времени, то задержка в передаче от браузера к серверу сломает регистрацию - это неприятно, это во-первых. во-вторых тебе просто пришлют ответ из будущего, ну как будто ты 5 секунд назад что-то отправил браузеру, а браузер тебе только сейчас ответил. подумай про альтернативные подходы.

anonymous
()
Ответ на: комментарий от anonymous

это какой-то лютый сайферпанк.

Что именно и какая аргументация?

igloev
() автор топика

Я тут поразмыслил насчёт капчи. Поулчается так, что любой программист сможет её сломать. Как только поймёт её принцип. И если делать что-то «на века», то всё упирается в вычилительную мощность. Т.к. получится фигня типа reCapcha (а это отстой).

В итоге как выход менять капчу (простенькую на простенькую) через определённый приемлемый период. Иначе чем руками это сделать вероятно нельзя.

Получается, что это всего лишь набор задачек в базе с датой истечения. Котрая пополняется каждый раз руками и имеет соотв. ответы (варианты или функцию).

Целенаправленный и упорный взлом это никак не исправит. Но вялые попытки автоматизировать регистрацию фейков частично пресечёт. Тем не менее, ломанув один из вариантов за период можно нарегать определённое кол-во фейков. И тут уже встаёт вопрос – добавить ограничение на кол-во регистраций на вариант капчи? Тогда хакерская атака будет атакой на отказ в регистрации – хотя если там набор вариантов, то не вс так плохо. В общем как-то так.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

Это всё известно. А тред не об этом.

igloev
() автор топика

Весь тред не читал. А заставлять клиента майнить криптовалюту уже предлагали? А что, задача вычислительно сложная, да и прибыль хостеру какая-никакая будет.

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Да чего уж там. Регистрация только после перевода 1 BTC. А уж как ты там его добыл - намайнил или на бирже наторговал, дело твое.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

Есть вариант попробовать вместо капчи развести пользователя на лоха. Машина вряд ли поведётся. А человек может.

Флоу примерно следующий

  1. Генерируешь UUID и сохраняешь у себя и у клиента в local storage.
  2. К форме регисрации добавляешь картинку и ссылку (с обработкой), там должно быть что-то типа «Бесплатно, пока не удалили».
  3. При переходе по ссылке отправляешь запрос UUID -> approved.
  4. Дальше чел с этого устройства сможет зарегаться без капчи.
kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

А можно развести и не регистрировать при этом? Это ж ведь какая экономия получается, сплошная выгода.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

Да чего уж там. Регистрация только после перевода 1 BTC.

Разница между предупреждением «для защиты от ботов мы заставим ваш компьютер пройти капчу» и «заплатите нам» все же есть. И, в отличие от исходного посыла запоминать сколько-то рандомных данных, с хоть какой-то пользой.

Хотя… криптовалюта… с «пользой» это я погорячился

COKPOWEHEU
()
Ответ на: комментарий от COKPOWEHEU

Хотя… криптовалюта… с «пользой» это я погорячился

Погорячился значит удоли. Зачем нам видеть как ты погорячился.

igloev
() автор топика
Ответ на: комментарий от kostyarin_

любой программист сможет её сломать

Огромная база вопросов + пермабан IP после n (большого!) неудачных попыток — сильно затянут этот процесс.

Но составлять её в любом случае дольше, чем ломать ;)

mertvoprog
()
Ответ на: комментарий от mertvoprog

пермабан IP

Никто же не будет делать гадости со своего белого IP. Этого вообще лучше не делать. CloudFlare и так лезет со своими капчами, когда заходишь с мобильного. Бесячие типы )

kostyarin_ ★★
()
Ответ на: комментарий от mertvoprog

Банальный паук тупо обойдёт все ссылки и эту капчу непроизвольно пройдёт :P

Там есть штуки типа

<meta name="robots" content="noindex, nofollow">

И в головах

X-Robots-Tag: noindex

Чтобы гугл аккаунтов не нарегал. А ссылку лучше делать на реальную рекламу – заодно и бабла поднять. Не биток кончено, но хоть какой-то выхлоп от поделки.

kostyarin_ ★★
()
Последнее исправление: kostyarin_ (всего исправлений: 1)
Ответ на: комментарий от kostyarin_

А ссылку лучше делать на реальную рекламу – заодно и бабла поднять.

С реальной рекламой еще договариваться надо, а то еще в суд подадут

COKPOWEHEU
()
Ответ на: комментарий от kostyarin_

со своего

А речь и не об этом, речь о том, чтобы пул проксей истощать на порядки раньше подбора всех правильных ответов ;)

mertvoprog
()
Ответ на: комментарий от mertvoprog

Вы ж понимаете, что спам-пауки болт кладут на robots.txt и прочие костыли? ;) — они для добросовестных ботов.

«Ну это просто».

Добавляешь скрытую ссылку mailto:collect-%uuid%@mysite.com. При этом UUID для каждого свой. Спам-паук обязательно отправит письмо и его UUD, приняв почту, тут же можно блокировать.

Тут есть пробелма таймингов. Ну, будет некоторый лаг. Как почтовый сервер родит, напрмиер. Или если паук собирает почтовые адреса, а рассылкой занимается уже другой чел, которому эти адреса проданы, через вермя. Тогда лаг будет ощутимый.

https://twitter.com/i/status/1333115413291552769

kostyarin_ ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.