Miért nem elég azt mondani a felhasználóknak, hogy "ne kattints gyanús linkekre"?

Évente visszatérő jelenet: a kávégép mellett valaki elmagyarázza a kollégáknak, hogyan ellenőrizzék a böngésző címsorát, mire figyeljenek a HTTPS-nél, és miért ne írják be a jelszavukat ismeretlen oldalakon. Elméletben rendben van ez a tanács. A gyakorlatban viszont olyan hitelesítési rendszereket építettünk, ahol a felhasználó szó szerint rejtvényt fejt, és a megoldás negyedévente változik.

Az igazság fájdalmasan egyszerű: a phishing nem mindig a felhasználó hibája. Gyakran a rendszer tervezési hibája.

Amikor a valódi oldalak is átverésre emlékeztetnek

Gondolj bele a saját céged bejelentkezési folyamatába. Ha nálad is minden úgy működik, mint a legtöbb helyen, akkor a bejelentkezés gomb valószínűleg átirányítja a felhasználót egy harmadik féltől származó identitásszolgáltató, összevont hitelesítés és tokenizált végpontok labirintusán keresztül – ami gyanúsan hasonlít egy phishing támadásra.

https://app.ceged.hu → 
https://auth.identitasszolgaltato.hu/ceged →
https://sso.osszevont-szolgaltatas.com/session/token →
https://verify.mfa-meggyozodes.com/2fa

Ezek egyike sem a saját céges domaineden fut. Egyik sem emlékezetes. Egyik sem ad esélyt a felhasználónak, hogy megkülönböztesse a valódit az utánzattól.

Egy támadónak három dologra van szüksége ehhez: meggyőző sablon, ellopott logó és egy jelszómező. A URL maga értelmetlenné vált, mert megtanítottuk a felhasználókat, hogy ne foglalkozzanak vele.

A címek sosem erre lettek tervezve

Őszintén szólva – a URL-ek szerkezete eleve zavaros, és nem várhatjuk el egy nem technikai felhasználótól, hogy úgy elemezze őket, mint egy fejlesztő.

Vegyük például ezt:

https://bejelentkezes.tesztelodes.belso.example-ceg.hu/auth/ellenorzes

A legtöbb felhasználó meglátja a "tesztelodes" és "belso" szavakat, és elájul. A cégnevét keresi, és még ha megtalálja, nem tudja eldönteni, hogy a körülötte lévő infrastruktúra legitim-e vagy ügyes utánzat.

A hostname specifikusból az általános felé halad (bejelentkezes → tesztelodes → belso → example-ceg → hu), vagyis a legfontosabb azonosító – a tényleges domain – a közepére van temetve. A felhasználók megtanulják, hogy bárhol keressék a márkanevet a URL-ben, és épp ez az a szokás, amit a phisherek kihasználnak.

Protokoll → Aldomain(ek) → Domain → TLD → Elérési út
    |          |           |       |      |
  HTTPS     bejelentkezes example   hu   /auth

Fejlesztőként ez evidens. Átlagfelhasználóként esélytelen, amikor normalizáljuk az efféle címeket:

https://auth.ceg.gyanus-szolgaltato.io
https://ceg.auth-szolgaltato.io/sso/abc123
https://auth-szolgaltato.io/ceg-bejelentkezes

A fejlesztő felelőssége

Itt jön a lényeg: te képes vagy olyan bejelentkezési élményt tervezni, ami alapból védi a felhasználókat.

Ahelyett, hogy átirányítanád a felhasználókat harmadik fél domainjein keresztül, gondolkodj ezen az elveken:

1. Legyen saját identity domain-ed. Az elsődleges márkád domainjének kell kezelnie a hitelesítést. Ha muszáj külső szolgáltatót használnod, kényszerítsd ki az egyedi aldomaineket:

✓ https://bejelentkezes.ceged.hu
✗ https://auth.szolgaltato.com/ceged

2. Következetes aldomain hierarchia. Ha a fő alkalmazásod a app.ceg.hu-n van, a hitelesítés legyen a auth.ceg.hu-n – ne három szinttel mélyebben, más infrastruktúrája alatt.

3. Okos átirányítás. Amikor külső szolgáltatáshoz kell linkelned (felmérések, fizetési felületek, támogatási portálok), használj szerveroldali átirányítást a saját domainodról. Ez konzisztens élményt ad, és megerősíti: "ha nem a mi domainünkről jön, az nem a miénk."

4. Az SMS-t és telefonszámokat is így kezeld. "Írja be ezt a kódot" vagy "hívja ezt a számot" üzenetek éppoly veszélyesek, mint az email linkek. Mindig adj meg elérhetőséget egy olyan oldalon, amit a felhasználóid már ismernek és bíznak benne.

Biztonság, ami a felhasználókkal együtt nő, nem ellenük

Az RFC 2119 terminológiája nem bürokratikus szöveg – tervezési filozófia. Amikor a hitelesítési biztonság "AJÁNLOTT" és nem "KÖTELEZŐ", oda jutunk, ahol most vagyunk: egy vadnyugathoz hasonló helyzet, ahol a legitim oldalak nem különböztethetők meg az átverésektől.

Azok a szervezetek fognak nyerni a biztonságban, amelyek abbahagyják, hogy a felhasználókat tekintik a leggyengébb láncszemnek, és elkezdik olyan rendszereket építeni, ahol a biztonságos választás a könnyű választás.

Mert a valóság ez: nem lehet kiképezni a felhasználókat egy tervezési probléma megoldására.

Mit jelent ez neked, ha startupot vagy vállalkozást viszel?

Ha hitelesítési folyamatokat építesz vagy karbantartasz, itt az ideje az ellenőrzésnek. Kérdezd meg magadtól:

• Fel tudja-e egy új felhasználó egyedül az URL alapján azonosítani a bejelentkezési oldaladat?
• Minden hitelesített felület olyan domaineken fut-e, amit a felhasználóid ismernek?
• A külső szolgáltatók BYO domain funkcióját használod, vagy elfogadod az alapértelmezett címeket?

Ez nem csak biztonsági színház – ez bizalomépítés. Azok a felhasználók, akik magabiztosnak érzik magukat a hitelesítési folyamatodban, megbíznak a termékedben is.

A NameOcean-nál látjuk, hogy a domain stratégia és a biztonsági architektúra összefonódik. A domain-ed nem csak egy cím – a felhasználói bizalom alapja. Gondoskodj róla, hogy neked dolgozzon, ne ellened.