Pull to refresh
4
0
Alexander@awawa

Android-разработчик

Send message

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

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

Спасибо за замечание :) Коненчо, я согласен с тем, что, преследуя цели популяризации, необходимо было бы выбирать другой подход, с большим погружением в контекст области и объяснением определений. Вообще говоря, я думаю, что при написании любого текста следует держать в уме уровень осведомлённости целевого читателя материала и упрощать до терминов, ему понятных.

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

Именно поэтому я нарочно опускаю определение кольца, не говорю об алгоритме НОД, не говорю почему я использую символы = и \equiv и т. п. И конечно я совершенно не касаюсь ключевой для популяризации темы - "а зачем это нужно?"

Проверил свой пароль до 20 символов на password.kaspersky.com

Тут говорится о подборе на среднестатистическом домашнем компьютере, а что это за компьютер такой среднестатистический? Они ж не сказали конкретную скорость перебора
К слову о скорости перебора паролей. Написанная мной на скорую руку программка на C++ генерирует 1 млн. 16 символьных паролей за 0.089 секунды. При этом у меня далеко не современное железо и далеко не лучшим образом написанная программа. Всё это дело можно ускорить во много раз. Добавим сюда хеширование, проверку по украденной базе и получим очень даже неплохую скорость перебора.
На современном железе вполне себе реально перебрать пароль длиной до 20 символов. Тут нужно учитывать, что задача не ставится перебрать пароль за ночь, можно на это дело потратить хоть год. Кто меняет пароли каждый месяц? Да никто. В лучшем случае каждый год, а некоторые и вовсе никогда не меняют. К тому же не обязательно подбирать пароль по одному пользователю за раз. Можно перебирать пароли и сразу проверять на соответствие со всеми пользователями. И тут уже пароли в 10 символов сломаются гораздо раньше, чем в 20. Но переусердствовать тоже ни к чему, пароля символов в 20-25, который меняется раз в год вполне достаточно.

Ну и вообще не стоит считать пароль надёжной защитой, какой бы длины он ни был, однозначно нужно предпринимать дополнительные меры, например в виде двух- или даже трехфакторной аутентификации.
Ну иногда злоумшленникам удаётся украсть базы данных с паролями с какого-то сервиса. Пароли, конечно, захешированы (чаще всего), и тут как раз подбором паролей можно и заняться. Другое дело, что перебирать 20 символьный пароль никто не будет (но если сильно надо, то можно), но проверить пароли до 8-10 символов длиной по словарю и простым перебором, в общем-то, почему бы и нет?
Вот тоже 48 символов прям глаз режет. Ведь с учётом того, что пароли не хранятся в открытом виде, а хранится их хеш и зачастую это md5/sha1, иногда sha256. Получается количество возможных хешей меньше, чем количество возможных 48 значных паролей. Не в коня корм как бы.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

Разработчик мобильных приложений
Средний
Разработка под Android
Kotlin
Android SDK
MVVM
Coroutines
Room
Разработка мобильных приложений
Клиент-серверные приложения