Относитесь к секретному номеру счёта как к учётным данным: проверьте его

Поле с подписью «номер счёта» не является автоматически публичной ссылкой, и подпись — не тест. Тест — это то, что даёт владение: если знание номера выполняет вход, загружает профиль подключения или авторизует устройство, этот номер — учётные данные с жизненным циклом. Я выполняю пять проверок ниже всякий раз, когда сервис выдаёт числовой идентификатор и называет его безобидным. Каждая даёт строку в коротком протоколе, и протокол — это результат, а не вердикт о продукте.

Опишите, что на самом деле даёт владение

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

Общую модель легко сформулировать: bearer-учётные данные — это те, которые держатель может использовать, не доказывая владение отдельным криптографическим ключом; именно это различие RFC 6750 проводит для токенов. Это сравнение, а не утверждение, что сервис на основе номера реализует OAuth. Если держателю больше ничего не нужно, относитесь к номеру как к bearer-секрету и классифицируйте остальную конструкцию соответственно.

Защищайте его как секрет, а не как ссылку

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

Фишинг — второй режим отказа, и ему всё равно, насколько номер случайный. Мошенник, которому нужно значение, попросит вставить его в форму, а учётные данные, которые никогда не истекают и не имеют второго фактора, стоят усилий. Добирайтесь до пути входа через закладку или известный адрес, а не через ссылку в сообщении, которое тоже просит номер.

Относитесь к материалам восстановления как к части секрета. Если оператор также выдал код восстановления, PIN или адрес электронной почты, позволяющий сбросить счёт, это отдельные учётные данные с тем же требованием защиты. Один незащищённый канал сброса превращает все остальные меры в украшение.

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

Длина имеет смысл только рядом с методом генерации. Длинный номер из предсказуемой последовательности слабее короткого значения от криптографического генератора, а внушительное число цифр не доказывает непредсказуемость. Спросите, как генерируется значение, прежде чем рассуждать о том, насколько его трудно угадать.

Одна лишь стойкость к подбору тоже не выдерживает неограниченной частоты попыток. Важны те меры, которые реализует оператор: счётчики неудачных попыток, блокировки, ограничение на источник и то, отличим ли неверный номер от несуществующего. Если сервис это поддерживает, одна неудачная попытка показывает, как выглядит ошибка и появляется ли счётчик повторов:

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

Запишите, что раскрывает ответ. Отдельная ошибка для неизвестного счёта — оракул перечисления, даже когда номер невозможно угадать, и этот вывод принадлежит протоколу независимо от того, можете ли вы исправить его на стороне клиента.

Планируйте ротацию и отзыв заранее

Найдите поддерживаемую процедуру для утраченного или раскрытого номера и запишите её, пока всё работает. Можно ли вообще заменить учётные данные счёта? Делает ли замена недействительными уже зарегистрированные устройства, активные сеансы или загруженную конфигурацию? Какой материал восстановления требует процедура? Сервис без зависимости от электронной почты может передать пользователю больше ответственности за восстановление, что делает процедуру важнее, а не менее важной.

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

Задокументируйте решение и перепроверьте его позже

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

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

Прежде чем сохранить его:

• Перечислены все полномочия, которые даёт номер, включая загрузки и авторизацию устройств.
• Каналы хранения и восстановления защищены по тому же стандарту, что и сам номер.
• Метод генерации и ограничения частоты известны, а не предположены из длины.
• Существуют процедура замены и процедура отзыва, и вы знаете, какая отменяет какую.
• В протоколе указано, кто может сбросить значение и какие свидетельства остаются после использования.