Behandla ett hemligt kontonummer som en inloggningsuppgift: granska det

Ett fält märkt kontonummer är inte automatiskt en offentlig referens, och etiketten är inte testet. Testet är vad innehavet tillåter: om kännedom om numret loggar in någon, laddar ner en anslutningsprofil eller auktoriserar en enhet, är numret en inloggningsuppgift med en livscykel. Jag kör de fem kontrollerna nedan varje gång en tjänst utfärdar en numerisk identitet och kallar den ofarlig. Var och en ger en rad i en kort rapport, och rapporten är leveransen, inte en dom över produkten.

Inventera vad innehavet faktiskt ger

Skriv ner varje åtgärd som numret låser upp, separat. Att logga in på en portal, hämta en konfigurationsfil, auktorisera en ny enhet och tillhandahålla en accepterad tunnelinloggning är olika behörigheter, och en tjänst kan implementera en utan de andra. En portal som accepterar numret som enda fält säger ingenting om hur tunneln autentiserar sin peer senare eller hur trafiknycklar härleds.

Den allmänna modellen är lätt att formulera: en bearer-inloggningsuppgift är en där innehavaren kan använda den utan att bevisa innehav av en separat kryptografisk nyckel, vilket är den distinktion som RFC 6750 drar för tokens. Det är en jämförelse, inte ett påstående att en nummerbaserad tjänst implementerar OAuth. Om innehavaren inte behöver något annat, behandla numret som en bearer-hemlighet och klassificera resten av designen därefter.

Skydda det som en hemlighet, inte som en referens

Lagringen följer av klassificeringen. Ett värde som loggar in hör hemma i en lösenordshanterare, inte i en skärmbild, en urklippshistorik, ett chattmeddelande eller en webbläsaranteckning. Skärmbilder är det vanliga läckaget: numret är kort och verkar ofarligt, så det hamnar i en supporttråd som överlever enheten det kom från.

Nätfiske är det andra felläget, och det bryr sig inte om hur slumpmässigt numret är. En bedragare som vill ha värdet ber dig klistra in det i ett formulär, och en inloggningsuppgift som aldrig löper ut och saknar andra faktor är ansträngningen värd. Nå inloggningsvägen via ett bokmärke eller en känd adress, inte via en länk i ett meddelande som också ber om numret.

Behandla återställningsmaterial som en del av hemligheten. Om operatören också utfärdade en återställningskod, en PIN-kod eller en e-postadress som kan återställa kontot, är de separata inloggningsuppgifter med samma skyddskrav. En oskyddad återställningskanal gör varje annan kontroll till dekoration.

Kontrollera gissningsmotstånd och hastighetsbegränsning tillsammans

Längd är bara meningsfull vid sidan av genereringsmetoden. Ett långt nummer från en förutsägbar sekvens är svagare än ett kort värde från en kryptografisk generator, och ett imponerande antal siffror bevisar inte oförutsägbarhet. Fråga hur värdet genereras innan du resonerar om hur svårt det är att gissa.

Enbart gissningsmotstånd överlever inte heller en obegränsad försöksfrekvens. De kontroller som betyder något är de som operatören implementerar: räknare för misslyckade försök, utelåsningar, begränsning per källa och om ett felaktigt nummer går att skilja från ett obefintligt. Om tjänsten stöder det visar ett misslyckat försök hur felet ser ut och om en återförsöksräknare visas:

# 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"

Anteckna vad svaret avslöjar. Ett separat fel för ett okänt konto är ett uppräkningsorakel även när numret är ogissbart, och den iakttagelsen hör hemma i rapporten, oavsett om du kan åtgärda den på klientsidan.

Planera rotation och återkallelse innan du behöver dem

Hitta den supportade processen för ett förlorat eller röjt nummer och skriv ner den medan allt fungerar. Kan kontots inloggningsuppgift bytas ut överhuvudtaget? Ogiltigförklarar bytet redan registrerade enheter, aktiva sessioner eller nedladdad konfiguration? Vilket återställningsmaterial kräver processen? En tjänst utan e-postberoende kan överföra mer återställningsansvar till användaren, vilket gör proceduren viktigare, inte mindre.

Separera kontobytet från återkallelsen av inloggningsuppgiften. Om numret auktoriserar nedladdning av en nyckel, ett certifikat eller en profil, kan ett byte av numret lämna det nedladdade materialet giltigt, och återkallelse av det nedladdade materialet kan vara en annan åtgärd med en annan ägare. Anta inte att ett ändrat fält avslutar alla anslutningar; kontrollera operatörens faktiska modell och anteckna var du verifierade det.

Dokumentera beslutet och kontrollera det igen senare

Håll en rapport på en sida per tjänst: vilka behörigheter numret ger, var det lagras, vem som kan återställa det, vilka bevis på användning som finns och vad du skulle göra den första timmen efter ett röjande. Den rapporten är det som förvandlar en diskussion om terminologi till ett beslut som någon kan granska.

Integritetspåståenden behöver sitt eget omfång. Ett slumpmässigt genererat nummer kan fortfarande vara en stabil identifierare som kopplar kontohändelser över tid; oförutsägbarhet är inte icke-kopplingsbarhet, och ingen av egenskaperna säger något om bevarade nätverksmetadata. Jämför kompletta designer i stället för att räkna fält på en inloggningsskärm.

Innan du arkiverar det:

• Varje behörighet som numret ger är listad, inklusive nedladdningar och enhetsauktorisering.
• Lagrings- och återställningskanaler skyddas enligt samma standard som numret självt.
• Genereringsmetoden och hastighetsgränserna är kända, inte antagna utifrån längden.
• Det finns en bytesprocedur och en återkallelseprocedur, och du vet vilken som upphäver vilken.
• Rapporten anger vem som kan återställa värdet och vilka bevis som återstår efter användning.