Какой длины должен быть ключ API?

Для нового непрозрачного ключа API используйте не менее 128 бит непредсказуемых случайных данных; 256 случайных битов — надежный выбор по умолчанию, если принимающая система их поддерживает. Это не означает, что каждый ключ должен содержать 256 символов. Одно и то же 256-битное значение представляется как 64 шестнадцатеричных символа, 43 символа Base64URL без дополнения, 44 символа Base64 с дополнением или 52 символа Base32 без дополнения.

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

Какова правильная длина ключа API?

Универсального количества символов не существует, поскольку символ не является фиксированной единицей безопасности. Шестнадцатеричный символ содержит 4 бита. Равномерно случайный символ Base64URL содержит около 6 бит, не считая последней частичной группы. Десятичная цифра содержит около 3,32 бита. Алфавит, метод генерации и количество независимых вариантов определяют пространство поиска.

Для практического планирования начните здесь:

Документация Python secrets называет 32 байта, или 256 бит, достаточными для типичных задач модуля, но предупреждает: необходимый объем случайных данных меняется с вычислительными возможностями и угрозами. Поэтому 256 бит — разумный выбор по умолчанию, а не универсальное правило соответствия требованиям.

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

Почему энтропия и количество символов различаются?

Энтропия отвечает на более полезный вопрос, чем внешний вид: сколько равновероятных секретов мог создать генератор? Равномерно случайное 128-битное значение имеет 2^128 вариантов, а 256-битное — 2^256. Дополнительные печатные символы помогают лишь тогда, когда добавляют независимые непредсказуемые варианты выбора.

RFC 4086 показывает, почему это важно. Длинная строка, полученная из небольшого или предсказуемого начального значения, может содержать гораздо меньше реальной информации, чем предполагает ее длина. Например, внешне 128-битное значение, полученное только из 8-битного начального значения, по-прежнему имеет лишь 256 вариантов начального значения. Длина не компенсирует слабую случайность.

Поэтому Math.random(), метки времени, последовательные идентификаторы, имена пользователей и объединенные данные устройств не подходят для создания секретов API. Для браузера MDN описывает crypto.getRandomValues() как метод получения криптографически стойких случайных значений. ClockTools требует этот API и не переходит на Math.random() при его отсутствии.

Для символьных алфавитов теоретический расчет таков:

entropy bits = character count × log2(number of distinct characters)

Для алфавита из 62 букв и цифр нужны 22 независимых символа, чтобы превысить 128 бит, и 43, чтобы превысить 256 бит. Для одних цифр нужны соответственно 39 и 78 символов. Малый алфавит не обязательно слаб: просто для того же целевого объема требуется более длинная строка.

Какова длина 256-битного ключа API в каждой кодировке?

Кодирование меняет представление, а не сами случайные байты. Действующий инструмент ClockTools и его регрессионные тесты используют 32 случайных байта для целевых 256 бит. Длина представления получается такой:

Длины соответствуют правилам кодирования RFC 4648. Шестнадцатеричный формат легко проверять, он широко поддерживается, но требует двух символов на байт. Base64URL компактнее и не использует + и /, неудобные в URL и именах файлов. Обычный Base64 может содержать эти символы и использует дополнение. Во многих сценариях Base32 нечувствителен к регистру, но длиннее.

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

Когда 128 бит достаточно?

Равномерно случайный 128-битный непрозрачный секрет дает огромное пространство вариантов для подбора через сеть. Во многих системах ограничения частоты запросов, мониторинг, изоляция учетных данных и сложность проверки вариантов делают полный перебор непрактичным. Увеличение до 256 бит дает больший запас при небольших затратах для большинства новых серверных систем.

Выбор все равно определяется моделью угроз и системным контрактом. Рассмотрите 256 бит, если вы контролируете формат, затраты на хранение незначительны, а ключ защищает ценный или длительный доступ. Корректно сгенерированный 128-битный ключ может подходить при фиксированном размере протокола, коротком сроке действия или ограниченном старом поле.

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

Делает ли префикс ключ API сильнее?

Нет, если префикс фиксирован или предсказуем. Текст вроде live_, test_ или sk_ помогает людям и сканерам секретов распознавать учетные данные, но не добавляет энтропии. 256-битное случайное значение содержит те же 256 случайных битов независимо от того, начинаются ли его печатные данные с пяти известных символов или нет.

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

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

Что еще имеет значение, кроме длины?

Длина относится лишь к этапу создания. Руководство OWASP по управлению секретами рассматривает жизненный цикл секрета: создание, ротацию, отзыв и истечение срока действия. Рекомендации Google Cloud по ключам API также выделяют ограничения, изоляцию, мониторинг, предотвращение раскрытия в клиентском коде и ротацию.

Перед выдачей ключа для рабочей системы проверьте три уровня:

1. Случайность: создайте не менее 128 непредсказуемых битов криптографически безопасным источником; для нового непрозрачного ключа выбирайте 256 бит, если это совместимо.
2. Представление: используйте поддерживаемую получателем кодировку; учитывайте только случайную часть, а не фиксированный префикс или разделитель.
3. Жизненный цикл: ограничьте права доступа, передавайте по HTTPS, храните в менеджере секретов, исключите запись открытым текстом в журналы, отслеживайте использование, задайте срок действия при необходимости и обеспечьте быстрый отзыв.

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

Как безопасно сгенерировать ключ?

Для быстрого создания локального значения в браузере откройте генератор ключей API, оставьте целевые 256 бит и выберите формат. Base64URL по умолчанию создает 32 случайных байта в виде 43 символов. Генерация и подготовка экспорта происходят локально, а секретные значения намеренно не включаются в настройки, которыми можно поделиться.

Для рабочей инфраструктуры по возможности генерируйте секрет в доверенной среде, где он будет храниться. Node.js crypto.randomBytes, Python secrets и OpenSSL позволяют обойтись без передачи через буфер обмена. ClockTools показывает команды для этих сред, не вставляя сгенерированный ключ.

После генерации зарегистрируйте значение в приложении, которое будет его проверять. Случайная строка не становится действующими учетными данными только из-за сходства с ключом API. Права, срок действия, отзыв и проверка запросов определяет принимающая система. Методика генерации ключей API ClockTools описывает браузерный источник, выборку с отбрасыванием, проверенные длины и ограничения; генератор GUID предназначен для идентификаторов, которые не являются совместно используемыми секретами.