Поле, обозначено като номер на сметка, не е автоматично публична референция и обозначението не е тестът. Тестът е какво позволява притежанието: ако знанието на номера вписва някого, изтегля профил за връзка или упълномощава устройство, този номер е идентификационни данни с жизнен цикъл. Изпълнявам петте проверки по-долу всеки път, когато услуга издава числов идентификатор и го нарича безобиден. Всяка създава ред в кратък протокол, а протоколът е резултатът, а не присъда за продукта.

Опишете какво всъщност дава притежанието

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

Общият модел е лесен за формулиране: 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"

Запишете какво разкрива отговорът. Отделна грешка за непозната сметка е оракул за изброяване дори когато номерът е неотгатваем, и това наблюдение принадлежи в протокола, независимо дали можете да го поправите от страна на клиента.

Планирайте ротация и отнемане, преди да ви потрябват

Намерете поддържаната процедура за изгубен или разкрит номер и я запишете, докато всичко работи. Може ли идентификационните данни на сметката да бъдат заменени изобщо? Прави ли замяната невалидни вече регистрирани устройства, активни сесии или изтеглена конфигурация? Какъв материал за възстановяване изисква процедурата? Услуга без зависимост от имейл може да прехвърли повече отговорност за възстановяване на потребителя, което прави процедурата по-важна, а не по-малко.

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

Документирайте решението и го проверете отново по-късно

Водете протокол от една страница за всяка услуга: какви права дава номерът, къде се съхранява, кой може да го нулира, какви доказателства за използване съществуват и какво бихте направили в първия час след разкриване. Този протокол превръща спора за терминология в решение, което някой може да одитира.

Твърденията за поверителност се нуждаят от собствен обхват. Случайно генериран номер може все още да бъде стабилен идентификатор, който свързва събития на сметката във времето; непредвидимостта не е несвързаност и нито едно от свойствата не казва нищо за запазените мрежови метаданни. Сравнявайте цели дизайни, вместо да броите полета на екрана за вход.

Преди да го съхраните:

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

Подобни статии