Dit login-system fejler, ikke dine brugere

Sikkerhedstræning er ikke løsningen

Hvert år fortæller sikkerhedskurser brugerne det samme: tjek URL'en, se efter HTTPS, og del aldrig din adgangskode på ukendte sider. Det lyder fornuftigt nok. Men sandheden er, at vi har bygget login-systemer så indviklede, at vi reelt beder brugerne om at løse en gåde – hvor svaret ændrer sig hvert kvartal.

Den ubekvemme sandhed: phishing er ikke altid brugerens fejl. Det er ofte en arkitekturfejl.

Når legitime sider ligner svindel

Tag et øjeblik og kig på din egen organisations login-flow. Hvis du er som de fleste virksomheder, navigerer den login-knap sandsynligvis brugerne gennem en labyrint af tredjeparts-identitetsudbydere, federerede authentication-services og tokeniserede endpoints, der ligner mistænkelige forsøg på phishing.

https://app.dinvirksomhed.dk → 
https://auth.identitetsudbyder.io/dinvirksomhed →
https://sso.federeretservice.com/session/token →
https://verify.authentication-processor.com/mfa

Ingen af disse URL'er hører til på din virksomheds domæne. Ingen af dem er til at huske. Og ingen af dem giver brugerne en chance for at skelne det ægte fra det falske.

En angriber behøver kun tre ting for at efterligne denne oplevelse: en overbevisende skabelon, et stjålet logo og et kodefelt. Selve URL'en er blevet meningsløs, fordi vi har trænet brugerne til at ignorere den.

URLs var aldrig designet til sikkerhed

Lad os være ærlige – URL-struktur er forvirrende i sin natur, og vi kan ikke forvente, at ikke-tekniske brugere kan parse den som udviklere.

Overvej denne URL:

https://login.staging.intern.example-corp.com/auth/verify

De fleste brugere ser "staging" og "intern", og så mister de interessen. De leder efter virksomhedsnavnet, og selv når de finder det, kan de ikke afgøre, om den omkringliggende infrastruktur er legitim eller en snedig efterligning.

Værtsnavnet læses fra specifikt til generelt (login → staging → intern → example-corp → com), hvilket betyder at det vigtigste identifikationspunkt – selve domænet – er begravet i midten. Brugere lærer at kigge efter et brandnavn hvor som helst i URL'en, og det præcis den vane, som phishere udnytter.

Protokol → Subdomæne(r) → Domæne → TLD → Sti
    |          |           |       |      |
 HTTPS      login      example   com    /auth

Udviklere forstår dette instinktivt. Almindelige brugere har ingen chance, når vi normaliserer URLs som:

https://auth.virksomhed.suspicious-vendor.io
https://virksomhed.auth-vendor.io/sso/abc123
https://auth-vendor.io/virksomhed-signin

Dit ansvar som udvikler

Her kommer det relevante: du har magten til at designe authentication-oplevelser, der beskytter brugerne som standard.

I stedet for at sende brugere gennem en labyrint af tredjeparts-domæner, så overvej disse principper:

1. Ej dit eget identitetsdomæne. Dit primære brand-domæne skal håndtere authentication. Hvis du absolut skal bruge tredjeparts-identitetsudbydere, så gennemtving brugen af tilpassede subdomæner:

✓ https://login.dinvirksomhed.dk
✗ https://auth.leverandør.com/dinvirksomhed

2. Konsistent subdomæne-hierarki. Hvis din hovedapp er på app.virksomhed.dk, skal dit auth være på auth.virksomhed.dk – ikke begravet tre niveauer dybt under en andens infrastruktur.

3. Redirect intelligent. Når du skal linke til eksterne services (undersøgelser, betalingsløsninger, supportportaler), så brug server-side redirects fra dit eget domæne. Det giver brugerne en konsistent oplevelse og forstærker, at "hvis det ikke kommer fra vores domæne, er det ikke vores."

4. Behandl SMS og telefonnumre på samme måde. "Ring til dette nummer" eller "sms denne kode" er lige så farlige som e-mail-links. Inkluder altid kontaktinformation på en side, dine brugere allerede stoler på.

Sikkerhed der skalerer med brugerne

RFC 2119-terminologien er ikke bare bureaukratisk jargon – det er en designfilosofi. Når sikkerhed i authentication er et "BØR" snarere end et "SKAL", ender du med den situation, vi har i dag: et lovløst vesten af federerede identitetsservices, hvor legitime sider er umulige at skelne fra svindel.

De organisationer, der vinder på sikkerhed, er dem der holder op med at behandle brugere som den svageste del og begynder at bygge systemer, hvor det sikre valg er det nemme valg.

For sandheden er: du kan ikke træne dig ud af et designproblem.

Hvad det betyder for din virksomhed

Hvis du bygger eller vedligeholder authentication-flows, er det nu tid til et tjek. Stil dig selv disse spørgsmål:

• Kan en førstegangsbruger genkende din login-side alene ud fra URL'en?
• Ruter alle dine godkendte oplevelser gennem domæner, dine brugere kender?
• Bruger du BYO-domæne-funktioner fra tredjeparts-services, eller accepterer du deres standard-URL'er?

Dette handler ikke kun om sikkerhedsteater – det handler om at opbygge tillid. Brugere, der føler sig trygge ved din authentication-oplevelse, er brugere, der stoler på dit produkt.

Hos NameOcean har vi set, hvordan domænestrategi går hånd i hånd med sikkerhedsarkitektur. Dit domæne er ikke bare en adresse – det er fundamentet for brugerens tillid. Sørg for, at dit arbejder for dig, ikke imod dig.