English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

гость
1 / ?
назад к урокам

Что делает формат хранения восстанавливаемым

Четыре формата хранения, ранжированные по восстанавливаемости:

ФорматВосстанавливаемый?ПримерМетод восстановления
Открытый текстДаpassword: hunter2Прочитать файл
Base64ДаcGFzc3dvcmQ=base64 --decode
Обратимый шифр (AES)ДаENC[AES256:...]Расшифровать с помощью ключа
Односторонний хеш (bcrypt)Нет$2b$12$...Невозможно обратить; требуется перебор

Открытый текст, base64 и обратимый шифр: всё восстанавливаемо. Одна утечка базы учётных данных даёт злоумышленнику все пароли в открытом виде для всех пользователей одновременно. Одна брешь — полная компрометация.

Пример Mailman 2.x

Mailman 2.x (менеджер списков рассылки GNU): хранил пароли подписчиков в открытом виде. Ежемесячное письмо-напоминание о пароле отправляло всем подписчикам их пароль в открытом виде. Два отдельных дефекта, оба MOAD-0006:

1. Хранение: открытый текст в базе данных списка. Компрометация сервера раскрывает все пароли подписчиков.

2. Рассылка: ежемесячное письмо отправляет пароль в открытом виде по SMTP на почтовый сервер подписчика. Письмо передаётся в открытом виде через несколько SMTP-узлов.

Команда Mailman разработала оба поведения. Восстановление было функцией: подписчики могли получить забытые пароли. Название Glass Safe происходит от этого: сейф хранит учётные данные в видимой форме. Любой, кто получает доступ к сейфу, может прочитать всё содержимое одновременно.

Принцип «Уже украдено»

Учётные данные, хранящиеся в восстанавливаемой форме, — это уже украденные учётные данные. Злоумышленник ещё не появился. Взлом ещё не произошёл. Но архитектура гарантирует: когда произойдёт взлом, все учётные данные попадут к злоумышленнику одновременно. Ни один взлом не происходит изолированно; каждая учётная запись в восстанавливаемом хранилище передаётся злоумышленнику в рамках одной операции.

MOAD-0006 vs MOAD-0004

MOAD-0004 (Logged Secret): учётные данные случайно записываются в логи. Запись в лог не была намеренной; это побочный эффект включения логирования заголовков для отладки.

MOAD-0006 (Glass Safe): учётные данные намеренно хранятся в восстанавливаемой форме. Восстановление было целью. Функция напоминания пароля требовала хранения пароля. Функция отображения пароля требовала его хранения. Архитектурное обязательство по восстановлению создало дефект.

Однострочное отличие: MOAD-0004 случайно помещает учётные данные в логи; MOAD-0006 намеренно хранит учётные данные в восстанавливаемой форме. Исправления работают на разных уровнях.

Структурное vs Случайное

Архитектурное различие между MOAD-0006 и MOAD-0004 определяет стратегию исправления. Случайная запись в лог: исправляйте слой сериализации. Хранилище, спроектированное для восстановления: перепроектируйте функцию, которая требовала восстановления.

Почему Glass Safe структурно отличается от MOAD-0004? Одной строкой опишите каждый дефект. Что это означает для исправления?

Почему bcrypt работает

Односторонняя хэш-функция принимает пароль и выдаёт дайджест фиксированной длины. По дайджесту исходный пароль восстановить невозможно. Не «сложно восстановить»: невозможно обратить. Функция работает только в одном направлении.

Три свойства, необходимые для хранения учётных данных:

1. Односторонность (устойчивость к обращению). По hash(password) невозможно восстановить password быстрее, чем перебором. bcrypt, scrypt и argon2 удовлетворяют этому свойству.

2. Соль. Случайное значение, добавляемое перед паролем перед хешированием. Один и тот же пароль с разной солью даёт разные хеши. Цель: противодействие радужным таблицам (предвычисленным словарям хешей). Без соли: злоумышленник один раз вычисляет hash('password123') и проверяет всех 1 миллион пользователей одновременно. С солью: у каждого пользователя уникальный хеш даже при одинаковом пароле.

3. Преднамеренная медлительность. bcrypt принимает коэффициент сложности. Чем выше коэффициент, тем больше итераций и времени на вычисление хеша. Вход в систему: 300 мс на один хеш — приемлемо. Перебор: 300 мс на попытку. При 1 миллиарде попыток: 9,5 лет на пароль — неприемлемо для злоумышленника. Медлительность — это не баг, а фича.

import bcrypt

# Хранить: односторонний хеш с солью
def store_password(plaintext: str) -> bytes:
return bcrypt.hashpw(plaintext.encode(), bcrypt.gensalt(rounds=12))

# Проверка: хешируем кандидата и сравниваем дайджесты
def verify_password(plaintext: str, stored_hash: bytes) -> bool:
return bcrypt.checkpw(plaintext.encode(), stored_hash)

# НИКОГДА не хранится: пароль в открытом виде
# НИКОГДА не восстановить: открытый текст из хеша
# Сброс пароля, а не напоминание пароля

Компромисс

Одностороннее хеширование делает восстановление пароля невозможным. Пользователь, забывший пароль, не может получить его обратно. Письмо с напоминанием пароля не может существовать. Пользовательский опыт меняется: «забыли пароль? сбросьте его». Это не ухудшение: это граница безопасности. Система, которая не может восстановить пароль, не может его утечь.

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

Сильного шифрования недостаточно

Аудит безопасности выявил систему хранения учётных данных. Пароли хранятся с использованием AES-256-CBC с ключом на стороне сервера. Отчёт аудита отмечает это как дефект Glass Safe.

Команда инженеров отвечает: «AES-256 — самый сильный из доступных симметричных шифров. Ключ хранится в аппаратном модуле безопасности. Ни один злоумышленник не сможет расшифровать эти пароли».

Почему это всё ещё MOAD-0006, несмотря на сильное шифрование? Какое правильное исправление?