Ставтеся до таємного номера рахунку як до облікових даних: перевірте його
Якщо знання номера виконує вхід або завантажує конфігурацію, це облікові дані. Виконайте перевірки повноважень, зберігання, стійкості до підбору та ротації.
Поле з написом «номер рахунку» не є автоматично публічним посиланням, і напис — не тест. Тест — це те, що дає володіння: якщо знання номера виконує вхід, завантажує профіль підключення або авторизує пристрій, цей номер — облікові дані з життєвим циклом. Я виконую п’ять перевірок нижче щоразу, коли сервіс видає числовий ідентифікатор і називає його нешкідливим. Кожна дає рядок у короткому протоколі, і протокол — це результат, а не вирок про продукт.
Опишіть, що насправді дає володіння
Запишіть кожну дію, яку відкриває номер, окремо. Вхід на портал, отримання файлу конфігурації, авторизація нового пристрою та надання прийнятого входу в тунель — це різні повноваження, і сервіс може реалізувати одне без інших. Портал, що приймає номер як єдине поле, нічого не говорить про те, як тунель автентифікує свого партнера пізніше і про те, як виводяться ключі трафіку.
Загальну модель легко сформулювати: 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"
Запишіть, що розкриває відповідь. Окрема помилка для невідомого рахунку — оракул переліку, навіть коли номер неможливо вгадати, і цей висновок належить протоколу незалежно від того, чи можете ви виправити його на боці клієнта.
Плануйте ротацію й відкликання заздалегідь
Знайдіть підтримувану процедуру для втраченого або розкритого номера і запишіть її, поки все працює. Чи можна взагалі замінити облікові дані рахунку? Чи робить заміна недійсними вже зареєстровані пристрої, активні сеанси або завантажену конфігурацію? Який матеріал відновлення вимагає процедура? Сервіс без залежності від електронної пошти може передати користувачеві більше відповідальності за відновлення, що робить процедуру важливішою, а не менш важливою.
Відокремлюйте заміну рахунку від відкликання облікових даних. Якщо номер авторизує завантаження ключа, сертифіката чи профілю, заміна номера може залишити завантажений матеріал чинним, а відкликання завантаженого матеріалу може бути іншою операцією з іншим власником. Не припускайте, що одне змінене поле припиняє кожне з’єднання; перевірте фактичну модель оператора й зазначте, де ви її підтвердили.
Задокументуйте рішення й перевірте його згодом
Тримайте односторінковий протокол на кожен сервіс: які повноваження дає номер, де він зберігається, хто може його скинути, які свідчення використання існують і що ви зробите в першу годину після розкриття. Саме цей протокол перетворює суперечку про термінологію на рішення, яке хтось може перевірити.
Заяви про конфіденційність потребують власних рамок. Випадково згенерований номер усе ще може бути стабільним ідентифікатором, що пов’язує події рахунку в часі; непередбачуваність — не незв’язуваність, і жодна з властивостей нічого не каже про збережені мережеві метадані. Порівнюйте повні проєкти, а не рахуйте поля на екрані входу.
Перш ніж зберегти його:
- Перелічено всі повноваження, які дає номер, включно із завантаженнями та авторизацією пристроїв.
- Канали зберігання й відновлення захищені за тим самим стандартом, що й сам номер.
- Метод генерації й обмеження частоти відомі, а не припущені з довжини.
- Існують процедура заміни й процедура відкликання, і ви знаєте, яка скасовує яку.
- У протоколі зазначено, хто може скинути значення і які свідчення залишаються після використання.