Пароли: bcrypt вместо MD5

Хеш bcrypt — строка вроде $2a$10$N9qo8uLOickgx2ZMRZoMye... — и она читается слева направо как анкета. Первые четыре символа — версия алгоритма, дальше два знака стоимости: десятка из примера выше — это cost. Затем двадцать два символа соли в собственной кодировке bcrypt и тридцать один символ собственно хеша: вместе ровно шестьдесят. Соль здесь — самое важное инженерное решение: она случайна для каждого вызова GenerateFromPassword, поэтому один и тот же пароль двух пользователей даёт два разных хеша, и радужные таблицы, заранее посчитанные для миллиона популярных паролей, становятся бесполезны — нападающему пришлось бы считать их заново для каждой соли. Стоимость cost управляет медленностью: это степень двойки в раундах подготовки ключа, каждый плюс один к cost удваивает время хеширования. В пакете заданы границы: bcrypt.MinCost, bcrypt.DefaultCost и bcrypt.MaxCost; по умолчанию берётся десятая стоимость — десятки миллисекунд на типичном сервере, точное число меряйте у себя. Границы пакета защищают и от наивной экономии: cost ниже минимума или выше максимума вернёт ошибку недопустимой стоимости.

Проверка пароля не разворачивает хеш — она пересчитывает. CompareHashAndPassword читает из сохранённого хеша соль и стоимость, прогоняет присланный пароль через те же шаги и сравнивает результаты: совпало — ошибка nil, не совпало — bcrypt.ErrMismatchedHashAndPassword. Из механики пересчёта следуют три практических правила. Первое: никогда не сравнивайте хеши сами — ни строками, ни повторным хешированием с ручной сверкой: пакет сравнивает в постоянном времени, чтобы утечка по времени не подсказывала наполовину угаданные символы; собственное сравнение этот слой защиты выбрасывает. Второе: соль отдельно не хранят и не передают — она уже внутри хеша, и второй колонки в схеме таблицы не заводить. Третье: ответ на неверный логин и неверный пароль — одинаковый, «неверный логин или пароль» со статусом 401: уточнение «такого пользователя нет» превращает эндпоинт в перечислитель зарегистрированных логинов. Ошибку пакета наружу не пробрасываем — она для лога, а не для клиента; честные ответы API уже разбирались в уроке про ошибки токенов, и принцип здесь тот же.

Медленность bcrypt — не побочный эффект, а платёж за безопасность, и её стоит измерить руками: тест с GenerateFromPassword на своём железе за минуту покажет, что DefaultCost стоит у вас пятьдесят или сто миллисекунд. Отсюда два практических следствия. Первое — бюджет входа: десятки миллисекунд на логин незаметны человеку, но заметны на пике нагрузки, поэтому генерацию хеша не ставят в горячий путь каждого запроса — она живёт в регистрации и смене пароля, а логин проверяет, что тоже стоит ресурсов, и ограничивается rate limiter-ом. Второе — рост стоимости со временем: железо дешевеет, и cost, безопасный пять лет назад, сегодня слабее; рабочая схема — при успешном входе сравнивать cost сохранённого хеша с текущим стандартом команды и, если он отстал, тихо пересчитывать хеш на новом cost. У bcrypt есть и жёсткий потолок: пароль длиннее семидесяти двух байт алгоритм не принимает, современные версии x/crypto возвращают на этом ошибку ErrPasswordTooLong, так что проверку длины лучше сделать до вызова, а не ловить её на регистрации. Честная оговорка про соседей по x/crypto: argon2id там же и считается современнее — он стойче к GPU-атакам по памяти, но bcrypt остаётся рабочей классикой с двадцатилетней историей и живёт во всех легаси-схемах; менять его на argon2 стоит осознанно, а не по привычке к новизне.

Наследство встречается чаще зелёного поля: в таблице лежат старые SHA-256, а сбрасывать пароли всех пользователей разом нельзя. Рабочий мост — двойное хеширование со флагом схемы в отдельной колонке. Новые записи живут как bcrypt от sha-256-хеша пароля; при входе код сначала считает SHA-256 от присланного пароля, потом сверяет его CompareHashAndPassword с сохранённым bcrypt-хешем. Старые записи проверяются прямым сравнением SHA-256, и каждый успешный вход по ним немедленно пересчитывается на bcrypt со снятием флага. Через пару месяцев активности флаги исчезают, старый столбец удаляется, и схема становится обычной. Граница метода: это временный переход, а не архитектура — держать два механизма вечно значит удваивать поверхность проверки, поэтому срок жизни моста фиксируется в задаче, а не в воспоминаниях.