Behandle et hemmelig kontonummer som en påloggningsopplysning: revider det

Et felt merket kontonummer er ikke automatisk en offentlig referanse, og etiketten er ikke testen. Testen er hva besittelsen tillater: hvis kjennskap til nummeret logger noen inn, laster ned en tilkoblingsprofil eller autoriserer en enhet, er nummeret en påloggningsopplysning med en livssyklus. Jeg kjører de fem kontrollene nedenfor hver gang en tjeneste utsteder en numerisk identitet og kaller den ufarlig. Hver av dem gir en linje i en kort rapport, og rapporten er leveransen, ikke en dom over produktet.

Kartlegg hva besittelsen faktisk gir

Skriv ned hver handling nummeret låser opp, hver for seg. Å logge på en portal, hente en konfigurasjonsfil, autorisere en ny enhet og levere en akseptert tunnelpålogging er forskjellige myndigheter, og en tjeneste kan implementere én uten de andre. En portal som godtar nummeret som eneste felt, sier ingenting om hvordan tunnelen autentiserer sin peer senere, eller hvordan trafikknøkler utledes.

Den generelle modellen er lett å formulere: en bearer-påloggningsopplysning er en der innehaveren kan bruke den uten å bevise besittelse av en egen kryptografisk nøkkel, som er skillet RFC 6750 trekker for tokens. Det er en sammenligning, ikke en påstand om at en nummerbasert tjeneste implementerer OAuth. Hvis innehaveren ikke trenger noe annet, behandle nummeret som en bearer-hemmelighet og klassifiser resten av designet deretter.

Beskytt det som en hemmelighet, ikke som en referanse

Lagringen følger av klassifiseringen. En verdi som logger på, hører hjemme i en passordbehandler, ikke i et skjermbilde, en utklippstavlehistorikk, en chatmelding eller et nettlesernotat. Skjermbilder er den vanlige lekkasjen: nummeret er kort og virker ufarlig, så det ender i en støttetråd som overlever enheten det kom fra.

Nettfiske er den andre feilmodusen, og det bryr seg ikke om hvor tilfeldig nummeret er. En bedrager som vil ha verdien, vil be deg lime den inn i et skjema, og en påloggningsopplysning som aldri utløper og ikke har en andre faktor, er innsatsen verdt. Nå påloggingsveien via et bokmerke eller en kjent adresse, ikke via en lenke i en melding som også ber om nummeret.

Behandle gjenopprettingsmateriale som en del av hemmeligheten. Hvis operatøren også utstedte en gjenopprettingskode, en PIN-kode eller en e-postadresse som kan tilbakestille kontoen, er det separate påloggningsopplysninger med samme beskyttelseskrav. Én ubeskyttet tilbakestillingskanal gjør enhver annen kontroll til dekorasjon.

Kontroller gjettemotstand og hastighetsbegrensning sammen

Lengde er bare meningsfull ved siden av genereringsmetoden. Et langt nummer fra en forutsigbar sekvens er svakere enn en kort verdi fra en kryptografisk generator, og et imponerende antall sifre beviser ikke uforutsigbarhet. Spør hvordan verdien genereres før du resonnerer om hvor vanskelig den er å gjette.

Gjettemotstand alene overlever heller ikke en ubegrenset forsøksrate. Kontrollene som betyr noe, er de operatøren implementerer: tellere for mislykkede forsøk, låser, begrensning per kilde og om et feil nummer kan skilles fra et ikke-eksisterende. Hvis tjenesten støtter det, viser ett mislykket forsøk hvordan feilen ser ut og om en ny forsøksteller vises:

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

Noter hva svaret avslører. En egen feil for en ukjent konto er et enumereringsorakel selv når nummeret ikke kan gjettes, og den observasjonen hører hjemme i rapporten, enten du kan rette den på klientsiden eller ikke.

Planlegg rotasjon og tilbakekalling før du trenger dem

Finn den støttede prosessen for et tapt eller avslørt nummer og skriv den ned mens alt fungerer. Kan påloggningsopplysningen til kontoen i det hele tatt erstattes? Ugyldiggjør erstatningen allerede registrerte enheter, aktive økter eller nedlastet konfigurasjon? Hvilket gjenopprettingsmateriale krever prosessen? En tjeneste uten e-postavhengighet kan overføre mer gjenopprettingsansvar til brukeren, noe som gjør prosedyren viktigere, ikke mindre.

Skill utskifting av kontoen fra tilbakekalling av påloggningsopplysningen. Hvis nummeret autoriserer nedlasting av en nøkkel, et sertifikat eller en profil, kan en utskifting av nummeret la det nedlastede materialet være gyldig, og tilbakekalling av det nedlastede materialet kan være en annen operasjon med en annen eier. Ikke anta at ett endret felt avslutter alle tilkoblinger; kontroller operatørens faktiske modell og noter hvor du verifiserte det.

Dokumenter beslutningen og kontroller den på nytt senere

Hold en rapport på én side per tjeneste: hvilke myndigheter nummeret gir, hvor det lagres, hvem som kan tilbakestille det, hvilke bevis på bruk som finnes, og hva du ville gjort den første timen etter en avsløring. Den rapporten er det som forvandler en diskusjon om terminologi til en beslutning noen kan revidere.

Personvernpåstander trenger sitt eget omfang. Et tilfeldig generert nummer kan fortsatt være en stabil identifikator som kobler kontoopplevelser over tid; uforutsigbarhet er ikke ikke-kobling, og ingen av egenskapene sier noe om lagrede nettverksmetadata. Sammenlign komplette design i stedet for å telle felt på en påloggingsskjerm.

Før du arkiverer det:

• Hver myndighet nummeret gir, er listet, inkludert nedlastinger og enhetsautorisasjon.
• Lagrings- og gjenopprettingskanaler er beskyttet etter samme standard som nummeret selv.
• Genereringsmetoden og hastighetsgrensene er kjente, ikke antatt ut fra lengden.
• Det finnes en utskiftsprosedyre og en tilbakekallingsprosedyre, og du vet hvilken som opphever hvilken.
• Rapporten navngir hvem som kan tilbakestille verdien og hvilke bevis som gjenstår etter bruk.