Это принципиально в контексте рассмотрения радужных таблиц
Очевидно что да, это очень важно. Потому я и говорю, что ссылка бессмысленна, разница не просто на порядки, здесь геометрическая прогрессия сложности.
Я запутался, вы меня опровергаете или поддерживаете? :)
В плане чудовищности объёма информации скорее поддерживаю. Однако речь о теоретической возможности подобной атаки. Сейчас-то от привычных md5 и sha1 повсеместно отказываются, хотя казалось бы — добавьте энтропии, добавьте соль и проблема решена. И, к слову, существующие радужные таблицы вовсе не пригодятся при кастомном алгоритме. Однако такая атака теоретически возможна. Плюс, опять же, для реализации такой системы нужна отмена GDPR и множества других законов по защите личности, установление повсеместного тоталитарного режима и, скорее всего, какие-то другие вещи. Что очевидно не случится быстро. Вычислительные мощности подрастут, возможность атаки станет ещё выше. Концепт, скорее всего, нежизнеспособен. Если уж такое реализовывать, то через сквозное шифрование и передачу сырых данных в облако.
Очевидно, что да, не знаете. Я говорю о том, что они обсуждают алфавитные символы, 26 символов для upper- и 26 для lowercase. То есть 52 набора байт только для букв, которые перемешиваются в произвольном порядке.
Это принципиально в контексте рассмотрения радужных таблиц — 52 там варианта или 255? Для степенных функций константа, которую возводят в степень, не важна по сравнению с экспонентой. Хоть двойку туда засуньте, говоря о битах — на достаточно больших степенях (а у нас, получается, они именно такие) оно потребует совершенно космические объёмы для хранения.
То есть в контексте данного обсуждения рассуждать о паролях бессмысленно, для букв не используется и половины всего диапазона допустимых значений.
Я запутался, вы меня опровергаете или поддерживаете? :) Ссылка с паролями была взята как одна из первых по запросу «rainbow table max length», просто, чтобы продемонстрировать порядки чисел.
Хотя, может я чего-то не знаю и байты паролей чем-то отличаются от байтов любой другой информации.
Очевидно, что да, не знаете. Я говорю о том, что они обсуждают алфавитные символы, 26 символов для upper- и 26 для lowercase. То есть 52 набора байт только для букв, которые перемешиваются в произвольном порядке. Однако, скажем, движения мышью не конвертируются в буквы, это числа с плавающей запятой. Верх-вниз, влево-вправо, у нас чарсет всего 2 флоата по 4 байта. И радужные таблицы от букв здесь не сработают, ведь у этих байтов абсолютно иной диапазон значений, нежели у букв. Нужен хеш от видеопотока? Здесь чарсет будет состоять из просто титанического количества байт, впрочем, в зависимости от видеоформата количество кодируемых байт будет отличаться. Для mp4, если не ошибаюсь, это будут блоки по 188 байт. То есть в контексте данного обсуждения рассуждать о паролях бессмысленно, для букв не используется и половины всего диапазона допустимых значений. Да и даже о паролях рассуждать с точки зрения побайтовой работы нужно более конкретизировано, всё-таки даже одна буква может быть как однобайтовой, так и четырёхбайтовой.
удачи в создании подобных таблиц для длин в разы и порядки больших.
Ну, если предположить, что описанная система реально существует, вы предлагаете ей бесконечно гонять трафик по сети? О, так игры ещё и будут тормозить. Всё прекраснее.
В процессе игры, когда ты сам в эту игру играешь, многое из описанного очень даже не весело (применительно к своей собственной шкуре).
Но в целом, когда отстраняешься от собственного игрового опыта и «задним умом» анализируешь произошедшие с тобой соответствующие события, понимаешь именно безудержную комичность (!) всего произошедшего.
Абсолютно бессмысленная ссылка. На сайте считают пароли посимвольно, в то время как при работе с данными мы должны работать с байтами.
В общем-то, на этом этапе можно закончить диалог. Хотя, может я чего-то не знаю и байты паролей чем-то отличаются от байтов любой другой информации.
Смысл радужных таблиц — предвычисления хэшей всех вариантов входных строк. Вопрос к ним не только и не столько к скорости вычисления, сколько к необходимому для хранения всего этого объёму — который возрастает по степенному закону с увеличением количества символов/байт/бит во входной строке. Если 2.5 Йоттабайта для всех вариантов 12-символьных паролей по моей бессмысленной ссылке вас не впечатлили — что ж, удачи в создании подобных таблиц для длин в разы и порядки больших.
Абсолютно бессмысленная ссылка. На сайте считают пароли посимвольно, в то время как при работе с данными мы должны работать с байтами. Да, это гораздо больший чарсет, чем они там обсуждают. Ну и, видимо, они там не учитывают существование всяких freerainbowtables.com
Но главной идеи это не отменяет, весь вопрос только во времени. А вообще, вы до конца дочитали?
Roughly two years before this question was asked there existed, in 2012, 25-GPU Clusters that could run through every possible eight-character password containing upper- and lower-case letters, digits and symbols in less than 6 hours.
Всего 25 gpu, это даже не средненькая ферма для майнинга. Насколько мощными были GPU в 2012, насколько мощные они сегодня? На сколько мощными они будут, когда мы скатимся в настолько беспросветное мрачное будущее?
Зная какие именно хеши формируются и из чего именно можно создать радужные таблицы и притворяться уже не только абстрактным Васей, будучи Петей, а вполне конкретным Фёдором.
Радужные таблицы для строк длиной более одного-двух десятков символов — ну-ну, удачи. Вы точно сварщик? :)
Assuming 256bit (32 byte) hashes and assuming you want to cover all possible passwords with 80 different characters (26 lowercase, 26 uppercase, 10 numbers, 18 other characters), these are the required rainbow-table sizes. I calculated this using the formula (80 ^ length ) * (32 + length).
For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.
Я и не говорю, что проблема в РКН, хотя с законами РФ тоже есть некие шероховатости. Писалось это в контексте GDPR, который явно указывает, что customer number является personal data.
Безусловно, кто же спорит? И что?
Зная какие именно хеши формируются и из чего именно можно создать радужные таблицы и притворяться уже не только абстрактным Васей, будучи Петей, а вполне конкретным Фёдором. И, пользуясь чужим кредитом доверия, портить ему репутацию. Да, радужные таблицы дело не быстрое.
Автор может всё, что угодно, но воздерживается от этого, потому что ему не нравится ваш тон, такой уж он эстет. Раз уж молчаливого минуса оказалось недостаточно — что ж, разомкну уста, чтобы донести эту информацию в более доходчивой форме.
Да, если автор статьи не считает их персональными — это вообще ничего не говорит, закон с ним не согласен. Закон вообще говорит, что userID это персональные данные.
Ссылки в студию, ссылки. А то получается, что «это тоже ничего не говорит несмотря на то, что комментатор что-то там считает» :) Я привёл ряд подтверждений своей позиции из вполне авторитетных источников — парируйте подобным.
Кстати, по закону, мы имеем право ознакомиться с собранной информацией.
Безусловно, кто же спорит? И что?
до тех пор, пока у вас сохраняется связь никнейм-id, это будет персональными данными
Чьими персональными данными, простите? Как идентифицировать субъекта персональных данных по нику и id? Персональность-то именно в том и заключается (см. соответствующий термин в начале заметки), что данные позволяют отнести их к конкретному физическому лицу. Если уж РКН даже номер мобильного не считает ПД, то какие-то там юзерайди непременно идут лесом.
Анонимное использование интернета и использование шифрования личных данных и средств коммуникации являются неотъемлемым правом человека. Уже лет так пять.
Встречный вопрос: вы считаете описанную в заметке проблему с анонимностью в целом проблемой, которая существенно влияет на положение вещей в жанре, общую экосистему и демографию аудитории?
Да, для этого разработчикам ММО придётся договориться об интеграции с единым логин-сервисом, наподобие OpenID,
Автор может указать причину, почему разработчики должны отбросить, свои личные распри друг с другом, и пилить единую систему для всех? Или как эта система вообще должна работать? Как она будет записывать времямо проведенное в ММО?
UPD:
И кстати обращаю внимание, что на прошлый комментарий целиком и пполномтью по делу, автор поставил жирный минус без объяснения причин.
я — мелкий или не очень пакостник. Люблю делать гадости.
Это можно назвать философским убеждением и подать в суд. Сбор информации о подобных убеждениях запрещён без явного письменного разрешения. Ещё это нарушает статью 16, ведь такая система затрагивает наши права и законные интересы. Кстати, по закону, мы имеем право ознакомиться с собранной информацией. GDPR ещё строже, у нас тут данные, которые позволяют определить предпочтения и интересы, у нас есть IP, есть идентификатор сессии пользователя, есть куча других персональных данных. Да, если автор статьи не считает их персональными — это вообще ничего не говорит, закон с ним не согласен. Закон вообще говорит, что userID это персональные данные. Есть у вас таблица в базе данных, автоинкремент, новый пользователь регистрируется под каким-то ником, автоматически получает id и всё. Вы попали в правовое поле GDPR, это персональные данные. Можно шифровать id, хешировать, солить, но до тех пор, пока у вас сохраняется связь никнейм-id, это будет персональными данными.
И это самое интересное, возможность сопоставления и комбинации этих данных. А ещё GDPR рекомендует псевдонимизацию данных. Грубо говоря, если Петя создаёт второй аккаунт, система обязана не понимать, что это именно Петя. С точки зрения GDPR описанная система не только не обеспечивает анонимности, но и псевдонимности тоже. То есть всё это требует кучу подписанных бумажных документов от каждого пользователя.
Но это не имеет ни малейшего значения, раз уж хешируется всё на стороне клиента. Вносим погрешность в данные и все хеши превращаются в мусор. В первой статье шла речь вообще об опенсорс проекте, так кто мешает скачать исходник, найти функцию формирования хеша и посолить. Выносим соль в параметры запуска и у нас уже столько цифровых личностей, сколько нам нужно. Игроки, убеждённые, что не просто так заполняли формуляр с разрешением на сбор данных, свято верят в метрики. А злоумышленник давно прикрылся фальшивой личиной и пользуется необоснованным спокойствием игроков. А ещё он знает, какого вида хеши формируются и из чего именно, ведь у него есть тот самый алгоритм. То есть глубоко незаконная система вызывает ложное чувство защищённости и при этом не выполняет своих прямых функций.
Жесть конечно
В плане чудовищности объёма информации скорее поддерживаю. Однако речь о теоретической возможности подобной атаки. Сейчас-то от привычных md5 и sha1 повсеместно отказываются, хотя казалось бы — добавьте энтропии, добавьте соль и проблема решена. И, к слову, существующие радужные таблицы вовсе не пригодятся при кастомном алгоритме. Однако такая атака теоретически возможна. Плюс, опять же, для реализации такой системы нужна отмена GDPR и множества других законов по защите личности, установление повсеместного тоталитарного режима и, скорее всего, какие-то другие вещи. Что очевидно не случится быстро. Вычислительные мощности подрастут, возможность атаки станет ещё выше. Концепт, скорее всего, нежизнеспособен. Если уж такое реализовывать, то через сквозное шифрование и передачу сырых данных в облако.
Я запутался, вы меня опровергаете или поддерживаете? :) Ссылка с паролями была взята как одна из первых по запросу «rainbow table max length», просто, чтобы продемонстрировать порядки чисел.
Ну, если предположить, что описанная система реально существует, вы предлагаете ей бесконечно гонять трафик по сети? О, так игры ещё и будут тормозить. Всё прекраснее.
Но в целом, когда отстраняешься от собственного игрового опыта и «задним умом» анализируешь произошедшие с тобой соответствующие события, понимаешь именно безудержную комичность (!) всего произошедшего.
Смысл радужных таблиц — предвычисления хэшей всех вариантов входных строк. Вопрос к ним не только и не столько к скорости вычисления, сколько к необходимому для хранения всего этого объёму — который возрастает по степенному закону с увеличением количества символов/байт/бит во входной строке. Если 2.5 Йоттабайта для всех вариантов 12-символьных паролей по моей бессмысленной ссылке вас не впечатлили — что ж, удачи в создании подобных таблиц для длин в разы и порядки больших.
Но главной идеи это не отменяет, весь вопрос только во времени. А вообще, вы до конца дочитали?
Всего 25 gpu, это даже не средненькая ферма для майнинга. Насколько мощными были GPU в 2012, насколько мощные они сегодня? На сколько мощными они будут, когда мы скатимся в настолько беспросветное мрачное будущее?
security.stackexchange.com/a/61147
Я и не говорю, что проблема в РКН, хотя с законами РФ тоже есть некие шероховатости. Писалось это в контексте GDPR, который явно указывает, что customer number является personal data.
Зная какие именно хеши формируются и из чего именно можно создать радужные таблицы и притворяться уже не только абстрактным Васей, будучи Петей, а вполне конкретным Фёдором. И, пользуясь чужим кредитом доверия, портить ему репутацию. Да, радужные таблицы дело не быстрое.
Мы же говорим о сугубо добровольной системе — не хочешь, не пользуешься.
Безусловно, кто же спорит? И что?
Чьими персональными данными, простите? Как идентифицировать субъекта персональных данных по нику и id? Персональность-то именно в том и заключается (см. соответствующий термин в начале заметки), что данные позволяют отнести их к конкретному физическому лицу. Если уж РКН даже номер мобильного не считает ПД, то какие-то там юзерайди непременно идут лесом.
Автор может указать причину, почему разработчики должны отбросить, свои личные распри друг с другом, и пилить единую систему для всех? Или как эта система вообще должна работать? Как она будет записывать времямо проведенное в ММО?
UPD:
И кстати обращаю внимание, что на прошлый комментарий целиком и пполномтью по делу, автор поставил жирный минус без объяснения причин.
И это самое интересное, возможность сопоставления и комбинации этих данных. А ещё GDPR рекомендует псевдонимизацию данных. Грубо говоря, если Петя создаёт второй аккаунт, система обязана не понимать, что это именно Петя. С точки зрения GDPR описанная система не только не обеспечивает анонимности, но и псевдонимности тоже. То есть всё это требует кучу подписанных бумажных документов от каждого пользователя.
Но это не имеет ни малейшего значения, раз уж хешируется всё на стороне клиента. Вносим погрешность в данные и все хеши превращаются в мусор. В первой статье шла речь вообще об опенсорс проекте, так кто мешает скачать исходник, найти функцию формирования хеша и посолить. Выносим соль в параметры запуска и у нас уже столько цифровых личностей, сколько нам нужно. Игроки, убеждённые, что не просто так заполняли формуляр с разрешением на сбор данных, свято верят в метрики. А злоумышленник давно прикрылся фальшивой личиной и пользуется необоснованным спокойствием игроков. А ещё он знает, какого вида хеши формируются и из чего именно, ведь у него есть тот самый алгоритм. То есть глубоко незаконная система вызывает ложное чувство защищённости и при этом не выполняет своих прямых функций.