Älä syytä käyttäjiä phishingistä – syyllinen on kirjautumisrakenteesi

"Älä klikkaa epäilyttäviä linkkejä" – helppo ulospääsy turvallisuuskeskustelusta

Joka vuosi sama varoitus toistuu turvallisuuskoulutuksissa: tarkista osoite, katso onko HTTPS, älä koskaan syötä salasanaa tuntemattomilla sivustoilla. Teoriassa järkevää neuvoa. Käytännössä olemme rakentaneet tunnistautumisjärjestelmiä niin monimutkaisiksi, että käytännössä pyydämme käyttäjiä ratkaisemaan pulmaa, jonka oikea vastaus muuttuu neljännesvuosittain.

Epämukava totuus on tämä: tietokalastelu ei aina ole käyttäjän epäonnistuminen. Usein se on arkkitehtuurin epäonnistuminen.

Milloin lailliset sivustot näyttävät huijauksilta

Pysähdy hetkeksi tutkimaan oman organisaatiosi kirjautumisprosessia. Jos olet kuten useimmat yritykset, tuo kirjautumisnappi ohjaa käyttäjät todennäköisesti kolmannen osapuolen identiteettipalveluntarjoajien, federoitujen todennuspalveluiden ja tokenisoitujen päätepisteiden labyrinttiin – jotka näyttävät hälyttävän samankaltaisilta kuin varsinaiset tietokalasteluyritykset.

https://sovellus.yrityksesi.com → 
https://auth.identiteettipalvelu.fi/yrityksesi →
https://sso.federoitu.fi/sessio/token →
https://verify.todennusprosessori.com/mfa

Yksikään näistä osoitteista ei sijaitse yrityksesi domainilla. Yksikään niistä ei ole muistettava. Ja yksikään niistä ei anna käyttäjille todellista mahdollisuutta erottaa aidot sivustot väärennöksistä.

Hyökkääjä tarvitsee vain kolme asiaa replikoidakseen tämän kokemuksen: vakuuttava pohja, varastettu logo ja salasanakenttä. Osoite on käytännössä menettänyt merkityksensä, koska olemme kouluttaneet käyttäjät ohittamaan sen.

Miksi URL:eja ei koskaan suunniteltu tätä varten

Ollaan rehellisiä – URL-rakenne on luonteeltaan hämmentävä, emmekä voi odottaa teknisten asioiden ulkopuolisten käyttäjien tulkitsevan sitä kuten kehittäjät.

Tarkastellaan vaikka tätä osoitetta:

https://login.staging.internal.yritys.fi/auth/verify

Useimmat käyttäjät näkevät "staging" ja "internal" ja heidän katseensa menee hämärään. He etsivät yrityksen nimeä, ja vaikka sen löytäisivätkin, he eivät pysty sanomaan, onko ympäröivä infrastruktuuri aito vai taitavasti tehty jäljennös.

Isäntänimi luetaan yleisestä yksityiskohtaiseen (login → staging → internal → yritys → fi), mikä tarkoittaa että tärkein tunniste – varsinainen domain – on hautautunut keskelle. Käyttäjät oppivat etsimään brändin nimeä mistä tahansa osoitteesta, ja juuri tätä tapaa tietokalastelijat hyödyntävät.

Protokolla → Al域 → Domain → TLD → Polku
    |          |        |       |      |
 HTTPS       login   yritys    fi    /auth

Kehittäjät ymmärtävät tämän intuitiivisesti. Tavalliset käyttäjät eivät pärjää, kun normalisoimme osoitteita kuten:

https://auth.yritys.epäilyttävä-toimittaja.io
https://yritys.auth-toimittaja.io/sso/abc123
https://auth-toimittaja.io/yritys-kirjautuminen

Kehittäjien vastuu

Tässä kohtaa asia koskettaa sinua: sinulla on valta suunnitella tunnistautumiskokemuksia, jotka suojelevat käyttäjiä automaattisesti.

Sen sijaan, että ohjaat käyttäjiä kolmannen osapuolen domainien labyrinttiin, harkitse näitä periaatteita:

1. Omista identiteettidomainisi. Ensisijaisen brändidomainisi tulisi käsitellä tunnistautuminen. Jos sinun on pakko käyttää kolmannen osapuolen identiteettipalveluntarjoajia, vaadi mukautettujen alidomainien käyttöä:

✓ https://kirjaudu.yrityksesi.com
✗ https://auth.toimittaja.com/yrityksesi

2. Johdonmukainen alidomain-hierarkia. Jos pääsovelluksesi on osoitteessa app.yritys.fi, kirjautumisesi tulisi olla osoitteessa auth.yritys.fi – ei kolmen tason syvyydessä jonkun muun infrastruktuurin alla.

3. Ohjaa fiksusti. Kun sinun täytyy linkittää ulkoisiin palveluihin (kyselyt, maksuprosessorit, tukipalvelut), käytä palvelinpuolen uudelleenohjauksia omalta domainiltasi. Tämä antaa käyttäjille yhdenmukaisen kokemuksen ja vahvistaa, että "jos se ei tule meidän domainiltamme, se ei ole meidän."

4. Kohtele SMS-viestejä ja puhelinnumeroita samalla tavalla. "Soita tähän numeroon" tai "lähetä tämä koodi" -viestit ovat yhtä vaarallisia kuin sähköpostilinkit. Sisällytä aina yhteystiedot sivulle, johon käyttäjät jo luottavat.

Turvallisuutta, joka skaalautuu käyttäjien mukana

RFC 2119:n terminologia ei ole byrokraattista jargonia – se on suunnittelufilosofia. Kun tunnistautumisturvallisuus on "PITÄISI" eikä "ON PAKKO", päädymme tilanteeseen, jossa federoitujen identiteettipalveluiden villi länsi saa lailliset sivustot näyttämään erottamattomilta huijauksilta.

Organisaatiot, jotka voittavat turvallisuudessa, ovat niitä, jotka lopettavat käyttäjien kohtelun heikoimpana lenkkinä ja alkavat rakentaa järjestelmiä, joissa turvallinen valinta on myös helppo valinta.

Koska todellisuus on tämä: et voi kouluttaa tietoturvaa ulos suunnittelusta syntyneestä ongelmasta.

Mitä tämä tarkoittaa sinun startupillesi tai yrityksellesi

Jos rakennat tai ylläpidät tunnistautumisprosesseja, nyt on aika auditoinnille. Kysy itseltäsi:

• Voiko ensikertainen käyttäjä tunnistaa kirjautumissivusi pelkän URL:n perusteella?
• Ohjaavatko kaikki todennetut kokemukset domainien kautta, jotka käyttäjät tunnistavat?
• Käytätkö kolmannen osapuolen palveluiden BYO domain -ominaisuuksia vai hyväksytkö heidän oletus-URL:nsä?

Tämä ei ole pelkkää turvallisuusteatteria – kyse on luottamuksen rakentamisesta. Käyttäjät, jotka tuntevat olonsa varmaksi tunnistautumiskokemuksessasi, ovat käyttäjiä, jotka luottavat tuotteeseesi.

NameOceanilla olemme nähneet, miten domain-strategia kohtaa turvallisuusarkkitehtuurin. Sinun domainisi ei ole pelkkä osoite – se on käyttäjäluottamuksen perusta. Varmista, että se toimii sinun eduksesi, ei sinua vastaan.