Атаки по времени и сравнение секретов за постоянное время

Что это такое

Побочный канал по времени возникает, когда длительность операции зависит от секретных данных. Классический пример — сравнение переданного значения с хранимым секретом обычной проверкой равенства: она возвращает результат, как только различается один байт, поэтому попытка с верным первым байтом занимает немного больше времени, чем с неверным. Повторные измерения усредняют шум и позволяют атакующему восстанавливать значение побайтово. Стандартные библиотеки предоставляют сравнения, длительность которых не зависит от содержимого: Python hmac.compare_digest использует «подход, предназначенный для предотвращения анализа времени путём исключения досрочного завершения в зависимости от содержимого»; Node crypto.timingSafeEqual сравнивает исходные байты алгоритмом постоянного времени и документирован как подходящий для дайджестов HMAC, аутентификационных cookie и URL, предоставляющих доступ самим фактом владения ими; Go subtle.ConstantTimeCompare выполняется за время, зависящее от длин, но не от содержимого.

Почему это важно

Это касается всего, что сервер сравнивает с секретом: подписей вебхуков, API-ключей, токенов сброса пароля, идентификаторов сессий, CSRF-токенов, HMAC-тегов подписанных cookie. Возможность использовать утечку через шумную сеть — вопрос числа измерений, а не принципа; функция постоянного времени обходится дёшево и снимает этот вопрос.

Как применять

• Сравнивайте каждое значение, содержащее секрет, функцией постоянного времени платформы, а не через == или равенство строк. Не ищите запись по токену в открытом виде (WHERE token = ?): сравнение в базе данных не является сравнением постоянного времени. Ищите по несекретному ID или хешу токена, затем сравнивайте за постоянное время.
• Учитывайте правило длин. Все три функции особо обрабатывают различающиеся длины: в примечании Python сказано, что несовпадение может раскрыть длины, но не значения; Node выбрасывает исключение; Go немедленно возвращает 0. Сравнивайте дайджесты фиксированной длины или хеши входов, чтобы длины всегда совпадали.
• Поддерживайте одинаковый путь обработки целиком, а не только сравнение: если пользователя не существует, всё равно проверяйте пароль по фиктивному хешу, чтобы случаи «неизвестный пользователь» и «неверный пароль» занимали одинаковое время.
• Храните серверные bearer-токены как хеши и сравнивайте хеши; тогда и утёкшая таблица не будет содержать пригодных для использования токенов.

Подводные камни

Сравнение постоянного времени не исправляет предшествующий шаг переменной длительности, например ветвление по префиксу секрета или декодер с ранним отказом. Документация Node прямо указывает: использование timingSafeEqual не гарантирует, что окружающий код защищён от анализа времени. Ограничение частоты сокращает число доступных атакующему измерений, но является вторым рубежом защиты, а не заменой. Самописный цикл сравнения компилятор или среда выполнения могут преобразовать так, что зависимость времени от данных появится вновь; используйте библиотечную функцию.