technological supremacy

Ну вы поняли, да? Злом пороля занял четыре часа, одну минуту: четыре часа пыхтения с докой по непривычному языку, минута работы брутфорсера в одно ~~рыло~~ ядро, который ничтоже сумляшеся ломает пароль длиной в пятьдесят ASCII-символов, и всё это исключительно подсчётом количества наносекунд, сравнимого с ликвидным балансом фнб.

Злом злома

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

Что делать

В первую очередь, перекладывать ответственность за проверку паролей на чужие библиотеки и коллег. Если же работы не избежать никак, то стоит взять constant time comparison function, которая вообще не будет проверять длину, а просто будет итерироваться по всей длине инпута и выполнять одинаковое количество операций вне зависимости от совпадения или несовпадения строк. Звучит приятно, но на деле это абсолютно нетривиальная задача (эй, костевички! мы уже передавали вам привет?) - любой if может сыграть свою роль с предиктором, некоторые операции в процессоре итеративные сами по себе, какие-то вещи могут вызвать лишние походы в память, etc., etc. - вы без труда найдёте в интернете пейперы, в которых ломают алгоритмы криптографии за счёт разных side channel.

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

Вне зависимости от этого, количество попыток входа нужно ограничивать. Мой любимый пример проблемы, тоже слегка связанный со статистикой - это шестизначные коды подтверждения. Они тоже на первый взгляд выглядят абсолютно неподбираемой историей, но если код действует пятнадцать минут, и мошейник успевает делать 1.1 запросов в секунду, то он проверяет 1000 рандомных кодов, с вероятностью успеха в 1/1000. В одном дне 96 таких пятнадцатиминутных отрезков, приводящих к вероятности устоять 0.999^96 = 0.908, а в неделе - 672, или 0.999^672 = 0.51.

Как строить из себя невиноватого

Да никак уже

И почему это на самом деле так просто не работает

Данный пример раскололся настолько тривиально по очень простой причине. Любой вменяемый человек ~~но что вы тогда здесь делаете~~ осуществит проверку содержимого следующим образом:

fun theKingdomHasFallen(password: ByteArray): Boolean {
    return Arrays.equals(password, Secret)
}

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

i = vectorizedMismatch(
        a, Unsafe.ARRAY_BYTE_BASE_OFFSET,
        b, Unsafe.ARRAY_BYTE_BASE_OFFSET,
        length, LOG2_ARRAY_BYTE_INDEX_SCALE);

и то если не будет вообще выпилена интринсиком

...что будет сравнивать байты сразу чанками и что означает, что для выявления корректного паттерна нужно совпадение не одного дополнительного байта, а сразу всей длины страйда, в котором может валяться и 64 байта за раз. Обычно, конечно, сравнивают вообще строки, и в сорцах String.equals() использует наивный алгоритм, но он же помечен IntrinsicCandidate; времени копаться в этом дальше и переписывать просто нет, увы.

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

❤1

35 views06:14