Изобрёл алгоритм защиты от флуда. Покритикуйте.

Говнокод и издевательство над юзерами

Идея больная

Каптча. Хочет регать много, пусть гадает или пишет гадалку. Алгоритм генерации каптчи менять когда кто-то написал авторегалку и посыпались кучей новые аккаунты. Подозрительных отправлять на повторное прохождение каптчи.

издевательство над юзерами

То есть капча — это не издевательство над юзерами.

А потом юзер закрыл браузер…

что то в этом есть

1. В начале процедуры регистрации генерим на сервере 64КБ рандома.

Это тяжелая операция

3. Отправляем юзеру данные 64кб и забываем эти 64 кб.

Это трафик.

Тебя за (d)dos’ят.

Как называется велосипед, который я только что изобрёл, у нормальных людей.

Proof of capacity

Что можно улучшить.

Хранить только AES ключ, а «случайные числа» генерировать при надобности просто шифрованием номера блока.

Альтернативы этому подходу.

Proof of <anything-else>.

Где можно почитать про такие вещи?

В википедии. :-)

Там же из названия всё должно быть понятно. Зачем ещё что-то читать?

Proof of capacity

Я тут подумал ещё, и осознал, что обычно proof-of-something подразумевают публичность, потому что возникли в контексте криптовалют, которые распределённые. Так что термин не очень хорошо подходит. Но я не знаю более подходящего выражения.

А потом юзер закрыл браузер… И что страшного произошло?

1. Генерить медленно. Не торопясь.
2. С таким же успехом меня заддосят запрашивая какой-нибудь джипег.

Говнокод и издевательство над юзерами

Идея больная

Каптча.

Чем именно капча лучше? Могу сказать чем лучше мой способ: от юзера не требуется думать/разгадывать, а только нажать кнопку и подождать 10 сек, наблюдая за прогрессбаром.

Это куцый вариант «proof of space», но примененный не по назначению.

Недостатков примерно два:

• генерация и передача 64К рандома - это дорого и хорошая основа для DDOS (ибо write amplification).
• есть масса других задачек-загадок, которые можно потребовать решить на стороне пользователя.

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

Генерить медленно. Не торопясь.

Соединение с незарегистрированным случайным прохожим будет висеть пока будет «неторопясь генериться»?

С таким же успехом меня заддосят запрашивая какой-нибудь джипег.

Джипег генерится каждый раз или статичный файл, который может закешировать прокси?

Джипеги всем прохожим раздаешь или только зареганым пользователям?

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

Это много кто предлагал, хоть тот же MS. И не взлетело по причине, что в те времена, до криптовалют был просто стрёмно просить весь мир жечь без полезной работы электричество. Было много разговоров, что неплохо бы выполнять вычисления, полезные для мира, от поисков лекарств до внеземных цивилизаций. Вот только есть проблема — задач, которые для сервера по проверке бесплатные и легко параллелятся наделать сложно, никому не нужны задачи, когда для проверки надо проводить теже вычисления, что и провёл клиент.

Генерить медленно. Не торопясь.

Количество одновременно открытых TCP-соединений - ресурс весьма ограниченный

С таким же успехом меня заддосят запрашивая какой-нибудь джипег.

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

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

[…] Вот только есть проблема — задач, которые для сервера по проверке бесплатные и легко параллелятся наделать сложно, никому не нужны задачи, когда для проверки надо проводить теже вычисления, что и провёл клиент.

Вы видимо что-то неверно поняли или неверно додумали.

Серверу достаточно сгенерировать 3-8 псевдо-случайных байт (но неведомых для пользователя), добавить к ним 8-13 байт суффикса (его можно обновлять раз в минуту-час) и посчитать хэш от этих 16-ти байт. Соответственно при проверке ответа еще раз посчитать хеш. Это копейки.

А на стороне пользователя придется подбирать хеш, это на много порядков более сложная задача (с каждым «секретным» битом усложняется в 2 раза).

Вы видимо что-то неверно поняли или неверно додумали.

В отличии от некоторых, я внимательно читаю на комменты и пишу развёрнуто, может слишком. Я прекрасно знаю эту идею и попытался объяснить, почему она старая и не взлетела. Попробуйте перечитать внимательнее, а не по диагонали первое и последнее слово.

Речь о том, что задача подбора части хеша не приносит пользы человечеству.

Например, расчёт сворачивания белка на клиенте принёс бы пользу. Но сервер для проверки должен провести те же вычисления, что сводит на нет всю идею с асимметричной нагрузкой.

Речь о том,

Спасибо. Я действительно криво написал вот тоже самое?

Я действительно криво написал вот тоже самое?

Да. Запутанно.

Да. Запутанно.

Я всегда считал, что форум не место для идеального выражения и прочей эпистолярности. И вообще, как 5 часов спать уже бы надо было б. Но вам же удалось распарсить! А общий уровень местного парсенья удручает :(

1. Про DDOS выше отвечено: заддосить можно запрашивая 100КБ jpeg фотку.
2. sha3-и-всё-такое - оно дорого по процу. Смартфоны будут плавиться, а десктопы раскалывать за полмикросекунды.

удалось распарсить

А ещё я регулярно занимаюсь парсингом кода. Зачастую у меня получается восстановить задумку автора, но это не мешает мне говорить, что код плохо читаемый, когда он читается плохо.

Я действительно криво написал вот тоже самое?

Да. Запутанно.

Скорее неожиданно. Я действительно неверно понял ваш ответ.

Идея-то конечно (мягко-говоря) не новая, но в контексте «защиты от флуда» я честно не ожидал упоминания поиска инопланетян )

Количество одновременно открытых TCP-соединений - ресурс весьма ограниченный

Нам пофигу, на что они тратятся. Клиент - это всегда 2-4 keep-alive соединений, которые держит chrome. Что он через них делает уже не важно - регистрируется, сидит на форуме и т.п.

Алгоритм повышения стоимости операций для клиента с сохранением низкой стоимости для сервера.

но по факту всё наоборот, генерить 64кб настоящего рандома на каждого клиента это очень затратная операция без аппаратного генератора, а клиенту хранить 64кб ничего не стоит

что код плохо читаемый, когда он читается плохо.

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

У меня по теме есть презабавная история и даже не оффтопик, как я сломал Линуксом вот такую задачу, где авторы клялись и божились, что они считают рендер для мультика. На целую статью тянет.

генерить 64кб настоящего рандома

Что вы привязались к этому «настоящему рандому»? Вроде ТС об этом не педалировал.

Клиент - это всегда 2-4 keep-alive соединений, которые держит chrome

Браузер будет держать столько keep-alive соединений, сколько ему дадут, в случае атаки веб-сервер позакрывает лишние

Ненастоящий рандом можно предсказать

1. Про DDOS выше отвечено: заддосить можно запрашивая 100КБ jpeg фотку.

Нет, это разные вещи.

jpeg у вас статический и будет в кеше. А 64К рандома нужно генерировать, т.е. выделить память, записать в память, отдать клиенту, отследить конец передачи и освободить. Это выйдет в ~10 раз дороже, т.е. у вас первые шаги дороже для сервера, и растет эта стоимость с обоих сторон одинаково и линейно.

2. sha3-и-всё-такое - оно дорого по процу. Смартфоны будут плавиться, а десктопы раскалывать за полмикросекунды.

В примере с SHA3 вы можете просить подобрать N бит (даже всего 1). Таким образом, регулируя стоимость по степени двойки. Ну и есть масса других дорогих по-вычислениям «загадок».

Кроме этого, подбор на стороне клиента может предполагать построение rainbow-таблиц (по префиксу или другим параметрам генерируемых сервером).

Фишка капчи именно в том что ее прохождение нельзя (сложно) автоматизировать, а у тебя автоматизация лежит в основе.

64кб очень мало, на фоне питона их даже не заметят :)

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

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

генерация и передача 64К рандома - это дорого и хорошая основа для DDOS (ибо write amplification).

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

Если же это сайт на хостинге и доступа к звуковой карте или аппаратному генератору нет, то рандом можно генерировать на отдельном ПК откуда он будет забираться сервером по мере надобности.

Я действительно криво написал вот тоже самое?

А главное оффтопное, потому что твой это не техническое возражение на предложенную идею.

Это выйдет в ~10 раз дороже, т.е. у вас первые шаги дороже для сервера, и растет эта стоимость с обоих сторон одинаково и линейно.

У ТС видимо та идея, что ‘‘стоимость’’ времени меньше ‘‘стоимости’’ ОЗУ.

Сервер расходует время и только на короткое время ОЗУ, которое к стати можно съэкономить пересылая тестовую последовательность блоками.

А вот клиент будет расходовать И время и ОЗУ, которого у него не 64 ГБ.

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

Тоже вариант :)) Только тут вот какая проблема, если крипту клиент будет майнить, то что помешает сделать ддос с вайниванием всего пула крипты атакующим.

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

А главное оффтопное, потому что твой это не техническое возражение на предложенную идею.

Если идея старая и не юзается, то надо объяснять причину. Вот вы знаете, ртутный градусник — очень хорош, а ртутный выпрямитель так вообще...

Если что то ртутный и сейчас используется в энергетике.

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

Например, расчёт сворачивания белка на клиенте принёс бы пользу. Но сервер для проверки должен провести те же вычисления

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

Если что то ртутный и сейчас используется в энергетике.

Ну а криптовалюты тоже не умерли.

А приведённая тобой причина имеет сугубо историчнское значение,

Доо, и потому надо назло дидам сделать ровно наоборот. Впрочем, типичненько в расуждениях на данном ресурсе.

из неё ни как не следует что обсуждаемый способ борьбы с ддомом плох сам по себе как таковой.

Я всё никак не пойму, вы действительно тупите, или просто так хочется чего-то возразить, что на подумать время не остаётся. Что трудного понять в том, что если некоторая идея известна давно, но не применяется (для тупых — это слово в настоящем времени), то полезно узнать почему?

Что трудного понять в том, что если некоторая идея известна давно, но не применяется (для тупых — это слово в настоящем времени), то полезно узнать почему?

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

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

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

Ты сказал почему.

Имеенно, причину, а не своё отношение к этому. А вы всё тупите.

Ладно, ты действительно указал на исторический факт, но сделал это немного неакуратно и по этому это было воспринято как возражение.

Очевидные проблемы:

1. 64 кб данных для клиента — это очень мало.
2. Обход твоего алгоритма легко автоматизируется.

64 кб данных для клиента — это очень мало.

В каком смысле-- мало? Ну попробуйте взломать хотя бы из 8 символов пароль. Хорошая и полезная задача :)

Так речь идёт же не о взломе, а именно о хранении.

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

Я не понял, что ты опроверг. Я прав, короче?

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

А если рассчёты с таймаутами? Т.е. юзеру нужно будет сделать 10 простых рассчётов, но каждый раз в секунду и не чаще.

а именно о хранении.

Ах, ну да. Зато можно сделать, что каждый топик форума — отдельный мусорный блок для хранения.