Phishing? Problem nie w użytkowniku, a w waszym logowaniu

Dlaczego "nie klikaj w podejrzane linki" to za mało

Co roku szkolenia z bezpieczeństwa powtarzają to samo: sprawdź adres URL, szukaj HTTPS, nigdy nie wpisuj hasła na nieznanych stronach. Teoretycznie to rozsądna rada. W praktyce jednak zbudowaliśmy systemy uwierzytelniania tak pokrętne, że w zasadzie prosimy użytkowników o rozwiązywanie zagadek, których poprawna odpowiedź zmienia się co kwartał.

Oto niewygodna prawda: phishing to często nie porażka użytkownika, tylko błąd w architekturze.

Kiedy legalne strony wyglądają jak oszustwa

Przyjrzyj się przez chwilę własnemu procesowi logowania w firmie. Jeśli jest podobna do większości, ten przycisk logowania prawdopodobnie przekierowuje użytkowników przez labirynt zewnętrznych dostawców tożsamości, sfederowanych usług autoryzacyjnych i ztokenizowanych endpointów, które podejrzanie przypominają prawdziwe próby phishingu.

https://aplikacja.twojafirma.pl → 
https://auth.dostawca-tozsamosci.io/twojafirma →
https://sso.usluga-federacyjna.com/sesja/token →
https://weryfikacja.procesor-autoryzacji.com/mfa

Żaden z tych adresów nie znajduje się na domenie twojej firmy. Żaden nie jest łatwy do zapamiętania. Żaden nie daje użytkownikom szansy na odróżnienie prawdziwego od fałszywego.

Atakujący potrzebuje zaledwie trzech rzeczy, żeby odtworzyć to doświadczenie: przekonującego szablonu, skradzionego logo i pola na hasło. Sam URL stał się bez znaczenia, bo nauczyliśmy użytkowników go ignorować.

Dlaczego URL-e nigdy nie były do tego projektowane

Bądźmy szczerzy — struktura URL jest z natury myląca i nie powinniśmy oczekiwać, że nietechniczni użytkownicy będą ją analizować jak programiści.

Weźmy taki adres:

https://logowanie.srodowisko.wewnetrzne.przykladowa-firma.pl/auth/weryfikuj

Większość użytkowników widzi "srodowisko" i "wewnetrzne" i ich oczy szkła przechodzą. Szukają nazwy firmy, a nawet gdy ją znajdą, nie potrafią ocenić, czy otaczająca infrastruktura jest legalna, czy sprytnym podszywaniem się.

Nazwa hosta czyta się od szczegółu do ogółu (logowanie → srodowisko → wewnetrzne → przykladowa-firma → pl), co oznacza, że najważniejszy identyfikator — prawdziwa domena — jest zakopany gdzieś pośrodku. Użytkownicy uczą się szukać nazwy marki gdziekolwiek w adresie, a to jest dokładnie ten nawyk, który phisherzy wykorzystują.

Protokół → Subdomeny → Domena → Rozszerzenie → Ścieżka
    |          |           |       |      |
  HTTPS    logowanie   przykladowa  pl    /auth

Programiści rozumieją to intuicyjnie. Zwykli użytkownicy nie mają żadnych szans, gdy normalizujemy takie adresy:

https://auth.firma.podejrzany-dostawca.io
https://firma.dostawca-autoryzacji.io/sso/abc123
https://dostawca-autoryzacji.io/logowanie-firmy

Odpowiedzialność programistów

Oto gdzie dochodzimy do sedna: masz moc projektowania doświadczeń uwierzytelniania, które chronią użytkowników domyślnie.

Zamiast przekierowywać użytkowników przez labirynt zewnętrznych domen, weź pod uwagę te zasady:

1. Bądź właścicielem domeny tożsamości. Twoja główna domena marki powinna obsługiwać uwierzytelnianie. Jeśli musisz korzystać z zewnętrznych dostawców tożsamości, wymuś użycie własnych subdomen:

✓ https://logowanie.twojafirma.pl
✗ https://auth.dostawca.pl/twojafirma

2. Spójna hierarchia subdomen. Jeśli główna aplikacja jest pod adresem app.firma.pl, logowanie powinno być pod auth.firma.pl — nie zakopane trzy poziomy głębiej pod infrastrukturą kogoś innego.

3. Przekierowuj mądrze. Kiedy musisz linkować do zewnętrznych usług (ankiety, bramki płatności, portale wsparcia), używaj przekierowań serwerowych z własnej domeny. To daje użytkownikom spójne doświadczenie i utrwala, że "jeśli nie pochodzi z naszej domeny, to nie jest nasze".

4. Traktuj SMS-y i numery telefonów tak samo. Wiadomości "zadzwoń pod ten numer" czy "wyślij ten kod" są równie niebezpieczne jak linki w emailach. Zawsze dołączaj kontakt do strony, której użytkownicy już ufają.

Budowanie bezpieczeństwa, które rośnie razem z użytkownikami

Terminologia z RFC 2119 to nie tylko biurokratyczny żargon — to filozofia projektowania. Kiedy bezpieczeństwo uwierzytelniania jest "SHOULD" zamiast "MUST", dostajesz sytuację, którą mamy dziś: dziki zachód sfederowanych usług tożsamości, gdzie legalne strony są nie do odróżnienia od oszustw.

Organizacje, które wygrają na bezpieczeństwie, to te, które przestaną traktować użytkowników jako najsłabsze ogniwo i zaczną budować systemy, gdzie bezpieczny wybór jest po prostu łatwym wyborem.

Bo oto rzeczywistość: nie da się wytrenować bezpieczeństwa z problemu projektowego.

Co to oznacza dla twojego startupu lub firmy

Jeśli budujesz lub utrzymujesz procesy logowania, teraz jest czas na audyt. Zadaj sobie pytania:

• Czy użytkownik pierwszy raz może zidentyfikować twoją stronę logowania tylko po URL-u?
• Czy wszystkie doświadczenia wymagające autoryzacji prowadzą przez domeny, które użytkownicy rozpoznają?
• Czy korzystasz z funkcji "bring your own domain" w usługach zewnętrznych, czy akceptujesz ich domyślne adresy?

To nie jest tylko kwestia teatru bezpieczeństwa — to kwestia budowania zaufania. Użytkownicy, którzy czują się pewnie w procesie logowania, ufają twojemu produktowi.

W NameOcean widzieliśmy, jak strategia domenowa przecina się z architekturą bezpieczeństwa. Twoja domena to nie tylko adres — to fundament zaufania użytkowników. Upewnij się, że pracuje dla ciebie, nie przeciwko tobie.