Overgangen mellom anonym og innlogget: innlogging, glemt passord, registrering av ny bruker og tofaktor. Liten i omfang, men den delen av systemet som alle brukere møter først — og den som gjør mest skade når den svikter.
Hvem modulen er for
For alle. Det er den eneste modulen som betjener både den anonyme besøkende og den innloggede brukeren, fordi den er selve grensen mellom dem. Derfor hører den heller ikke hjemme inne i noen av de andre modulene — den er broen mellom dem.
Tilsvarende tilgangsrolle i spesifikasjonen: Selve overgangen mellom «Anonym (ikke innlogget)» og «Innlogget bruker». En tilgangsrolle er samlingen av rettigheter en bruker får — hva vedkommende har lov til å se og gjøre.
Typisk innhold
Innlogging med brukernavn og passord. Glemt passord med lenke på e-post. Utlogging, og automatisk utlogging etter inaktivitet. Registrering av ny bruker, eventuelt med bekreftelse av e-postadressen. Tofaktor (et engangsnummer på SMS eller i en app i tillegg til passordet). Ofte innlogging via en ekstern tjeneste — BankID der identiteten må være sikker, eller virksomhetens egen Microsoft- eller Google-konto for ansatte. Og en side for å endre eget passord.
Hvorfor den undervurderes
Den glemmes sjelden helt — alle vet at systemet skal ha innlogging. Det som glemmes er alt rundt selve innloggingsskjemaet. Skjemaet er en time. Glemt passord med e-post, gyldighetstid på lenken og sperre mot misbruk er noe helt annet. Registrering med bekreftelse av e-post er en egen liten flyt. Tofaktor er en tredje. Folk estimerer bildet de ser for seg, og det bildet er to felter og en knapp.
Når det bør være en egen modul
Nesten alltid eget kapittel, av to grunner. Den henger ikke naturlig sammen med noe annet fagområde, og den er stedet du ønsker at sikkerhetsspørsmålene skal samles. Unntaket er systemer helt uten brukerkonto — for eksempel et system der alle ansatte kommer inn via virksomhetens eksisterende pålogging og ingen kontoer forvaltes lokalt. Da krymper modulen til et oppsett av integrasjonen, og hører hjemme i adminsidene. Merk at det er et valg med konsekvenser, ikke bare en forenkling: da eier virksomheten identitetene et annet sted.
Fallgruver
Å ta tofaktor med «hvis vi rekker». Det er i praksis et krav i systemer med personopplysninger, og det bør stå i kravspeken fra start, ikke dukke opp i en sikkerhetsgjennomgang rett før lansering. Å bygge egen passordhåndtering fra bunnen — det er et løst problem, og hjemmelagde varianter er der lekkasjene skjer. Å glemme hva som skjer etter innlogging: skal alle til samme forside, eller skal en administrator og en kunde lande ulike steder? Og å glemme innloggingen i universell utforming — er den ikke tilgjengelig, er resten av systemet utilgjengelig, uansett hvor godt det er bygget.
AI-perspektiv
Innloggingsflyter er kjent stoff, så et AI-verktøy skriver dem raskt og troverdig. Det er akkurat derfor de bør leses ekstra nøye: generert kode ser like riktig ut enten den er sikker eller ikke, og dette er den ene modulen der en feil ikke bare gir en dårlig opplevelse, men åpner systemet. Bruk et etablert bibliotek eller en etablert tjeneste for selve påloggingen, og la AI hjelpe med det rundt.
Skal dere sette omfanget på et system? Modulene avgjør hvor stort prosjektet blir, og den største av dem er ofte den ingen har snakket om. DOPS har spesifisert og bygget systemer for norske virksomheter i over 20 år.
Be om et estimat