Инструменты разработчика · Кодер и декодер Base64
Base64 — это не шифрование: почему закодированный секрет может прочитать любой
· Почему это важно
base64 безопасность кодирование
Base64 ничего не скрывает: любой, у кого есть строка, может мгновенно ее декодировать, не имея ключа. В этом посте объясняется разница между кодированием, шифрованием и хешированием, а также что делать, если вы обнаружите секреты Base64 в репозитории.
Значение конфигурации, которое выглядело зашифрованным и декодированным в пароль базы данных — конкретное открытие и то, как быстро оно меняется
Обнаружение Base64 в файле конфигурации создает ложное чувство безопасности. Разработчик обнаруживает пароль базы данных, который выглядит как зашифрованная последовательность, например dGlnZXJfZGF0YWJhc2VfYWRtaW4, предполагает, что он зашифрован, и фиксирует его в репозитории вместе с кодом приложения. Спустя несколько недель проверка безопасности выявила настоящий открытый текст: Tiger_database_admin.
Base64 ничего не скрывает; это кодировка, а не шифрование. Тот же измененный пароль мгновенно снова становится необработанным в браузере, без ключа, без вычислений и без задержек. В этом посте объясняется, почему кодирование вообще существует, чем оно принципиально отличается от шифрования и хеширования и что на самом деле происходит, когда кто-то находит секреты Base64 в зафиксированной истории.
Кодирование, шифрование и хеширование: три разные задачи — что каждая гарантирует и для какой нужен ключ
Путаница возникает потому, что Base64 выглядит как защита. Человек не может взглянуть на dGlnZXJfZGF0YWJhc2VfYWRtaW4 и прочитать Tiger_database_admin. Он кажется неясным, пока вы не пропустите его через декодер. Такое запутывание на поверхностном уровне кажется безопасностью, но это не так. Base64 был разработан для решения совершенно другой проблемы: перемещения произвольных двоичных данных через текстовые каналы. Электронная почта, старые веб-формы и системы линейных протоколов не могли передавать необработанные байты. Base64 преобразует байты в печатные символы ASCII, чтобы данные могли проходить через эти каналы в целости и сохранности.
Как только данные прибыли, получатель декодировал их обратно в байты. Кодирование и декодирование одинаково просты; им не нужны ни ключи, ни энтропия, ни криптографическая библиотека. Кодирование, шифрование и хеширование служат трем разным целям и предлагают три разные гарантии. Кодирование преобразует данные в другое представление, чтобы они могли проходить через определенный канал или использоваться в определенном контексте. Кодировка Base64, URL, шестнадцатеричное представление и даже экранирующие кавычки в JSON — все это кодировки. Они обратимы кем угодно и не требуют секретного ключа.
Зачем вообще существует Base64 — безопасная транспортировка байтов по текстовым каналам, а не конфиденциальность
Целью является совместимость форматов, а не конфиденциальность. Для шифрования, напротив, требуется ключ, известный только уполномоченным сторонам. Только тот, у кого есть правильный ключ, может превратить зашифрованный текст обратно в открытый текст. Без ключа сообщение остается непрозрачным даже для того, кто достаточно искушен, чтобы его взломать. Хеширование по своей природе является односторонним: криптографический хеш пароля вообще не может быть отменен. Он используется для проверки соответствия пароля сохраненному хешу без сохранения самого пароля.
Секретный пароль Kubernetes с именем «база данных-пароль», который содержит кодировку base64: dGlnZXJfZGF0YWJhc2VfYWRtaW4, на самом деле не является секретом. Base64 — это кодировка по умолчанию, которую Kubernetes использует для хранения, а не для защиты. Любой, у кого есть доступ к базе данных YAML или etcd, может расшифровать значение за считанные секунды. Переменные среды с ключами API в кодировке Base64 в сценарии запуска сталкиваются с той же проблемой. Заголовок базовой аутентификации, который отправляет Authorization: Basic base64_username:password на сервер, может быть декодирован любым прокси-сервером, инструментом мониторинга или сетевым наблюдателем между клиентом и сервером.
Рабочий пример: декодирование «секретной» строки в браузере — вставка, декодирование и открытый текст без участия сервера.
Если канал HTTP вместо HTTPS, риск еще больше. Base64 в этих контекстах является отвлекающим маневром: настоящий секрет уже был скомпрометирован, поскольку он вообще хранился или передавался в восстанавливаемой форме. Проработанный пример делает проблему конкретной. Предположим, что ключ API для сторонней службы отображается в файле конфигурации как YXBpa2V5XzEyMzQ1Njc4OTAX. Скопируйте эту строку в кодировщик и декодер Base64 в своем браузере, вставьте ее в поле ввода и нажмите «Декодировать».
Инструмент возвращает apikey_1234567890. Это произошло мгновенно, в вашем браузере, без связи с сервером, без необходимости ключа и без выполнения аутентификации. Вся операция занимает меньше секунды. Теперь предположим, что этот же ключ злоумышленник нашел в общедоступном репозитории GitHub. Они одинаково легко его декодируют любыми удобными им инструментами и используют для доступа к сервису. Независимо от того, остается ли строка скрытой в репозитории, перемещается по сети или появляется в журналах приложений, ее можно обнаружить с помощью тривиальной операции, доступной на любом языке программирования и в инструментах браузера, подобных этому.
Где проявляется эта ошибка — секреты Kubernetes, файлы .env, базовые заголовки аутентификации и ресурсы мобильных приложений.
Ошибка появляется повсюду, поскольку Base64 настолько распространен, что его ассоциируют с запутыванием из-за близости. Разработчики видят данные в кодировке Base64, делают вывод, что кто-то считает это важным, и оставляют секреты в этой форме. Файл .env, содержащий API_KEY=VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0, кажется младшему инженеру более безопасным, чем API_KEY=На самом деле это не секрет, хотя декодирование занимает одну операцию. Мобильные приложения объединяют токены в кодировке Base64 в ресурсы, которые любой декомпилятор может извлечь и декодировать. Резервные копии базы данных содержат пароли в кодировке Base64 в полях, которые предназначены для поиска, а не для защиты.
В каждом случае кто-то ошибочно принял кодировку за шифрование и создал архив секретов открытого текста, который отформатирован таким образом, что для чтения требуется один дополнительный шаг. Что делать при обнаружении секретов Base64, зависит от контекста.
Что делать вместо этого — секретные менеджеры, настоящее неактивное шифрование и ротация уже зафиксированных данных.
Если секрет представляет собой токен, ключ API или пароль и он уже передан в систему контроля версий, считайте его скомпрометированным. Отмените его, создайте новый и обновите каждое место, где он использовался. Историческая фиксация является частью постоянной записи репозитория, даже если секрет позже удаляется при новой фиксации; любой, у кого есть доступ к истории хранилища, может найти его.
Поиск в репозиториях значений в кодировке Base64 теперь является стандартной тактикой разведки, поэтому тот факт, что что-то было Base64, не делает это секретным. Никогда не кодируйте секреты с помощью Base64 в любой текущей операции и не предполагайте, что они защищены. Используйте менеджер секретов, который хранит значения в зашифрованном виде, с контролем доступа и возможностью проверки. Сохраняйте в коде и конфигурации приложения только ссылку или производную информацию, а не сам секрет. Настоящее шифрование неактивных данных означает, что данные зашифрованы ключом, хранящимся отдельно, и бесполезны для тех, у кого нет этого ключа.
Что сюда не входит — выбор алгоритма шифрования или схемы управления ключами.
База данных, которая шифрует конфиденциальные столбцы, менеджер секретов, использующий шифрование конвертов с ключами в аппаратном модуле безопасности, или менеджер паролей, который извлекает ключи шифрования из паролей пользователей, — все это обеспечивает подлинную конфиденциальность. Шифрование на уровне приложения в момент создания секретов, прежде чем они будут где-либо сохранены, еще более надежно. Смена раскрытых секретов, даже если они были закодированы только в Base64, удаляет окно возможностей для злоупотреблений. Если секрет находился в репозитории, проверьте журналы, чтобы узнать, когда к нему был осуществлен доступ и для чего он использовался во время окна раскрытия.
Для обеспечения постоянной безопасности используйте кратковременные токены, выданные службой авторизации, а не статические секреты, хранящиеся в конфигурации. Токен, срок действия которого истекает через час, менее ценен для злоумышленника, даже если он скомпрометирован. В этой статье не рассматривается выбор алгоритма шифрования, схемы управления ключами или архитектуры аутентификации. Это более глубокие инженерные вопросы со своими стандартами и компромиссами. Суть проще: Base64 не является одним из инструментов для решения любой из этих проблем. Это преобразование формата для транспортировки и хранения.
Вывод: относитесь к Base64 как к открытому тексту — как кодировщик и декодер Base64 передает информацию одним щелчком мыши, при этом секрет никогда не покидает вашу вкладку.
Не позволяйте появлению Base64 в репозитории, файле конфигурации или журнале убеждать вас в том, что данные защищены. Любой инструмент, который может читать текст, может декодировать Base64, и операция выполняется мгновенно и детерминировано. Чтение строки в кодировке Base64 как зашифрованного текста является распространенным недоразумением, и оно оставляет настоящие секреты на виду. Разработчики часто осознают это только после обнаружения секретов Base64 в производстве или в ходе аудита. Свежий взгляд появляется, когда инженер локально декодирует образец строки и мгновенно видит исходный открытый текст.
Этот инструмент делает неизбежным вывод: кодирование — это не шифрование. Как только это различие становится ясным, последующие действия становятся автоматическими. Каждый секрет Base64 в кодовой базе должен быть ротирован. Каждое место, где используется секрет, должно быть обновлено. Необходимо оценить окно воздействия. В будущем секретные менеджеры и настоящее шифрование должны заменить кодирование в этой роли. Кодер и декодер Base64 точно показывает, насколько быстро и легко происходит изменение, при этом ваш секрет никогда не покидает браузер. Считайте эту простоту реальной мерой безопасности: если вы можете расшифровать ее за секунду, то сможет и любой другой.