Il tranello del "Non cliccare link sospetti"

Ogni anno, i corsi sulla sicurezza digitale ripetono la stessa storia: verifica l'URL, cerca HTTPS, non inserire mai la password su siti sconosciuti. In teoria è ottimo consiglio. Ma nella pratica? Abbiamo costruito sistemi di autenticazione talmente contorti che l'utente medio si trova a risolvere un rebus dove la risposta corretta cambia ogni tre mesi.

Ecco la verità che nessuno vuole ammettere: il phishing non è sempre colpa dell'utente. Spesso è un fallimento dell'architettura.

Quando i siti legittimi sembrano truffe

Fermati un attimo e guarda il flusso di login della tua azienda. Se somiglia alla maggior parte delle realtà là fuori, quel pulsante "accedi" probabilmente reindirizza gli utenti attraverso un labirinto di provider di identità terzi, servizi di autenticazione federata e endpoint tokenizzati che hanno un aspetto inquietantemente simile a un tentativo di phishing.

https://app.tuapiattaforma.com → 
https://auth.fornitoreidentita.io/tuapiattaforma →
https://sso.serviziofederato.com/sessione/token →
https://verifica.elaboratoreautenticazione.com/mfa

Nessuno di questi URL risiede sul dominio della tua azienda. Nessuno è memorabile. Nessuno dà all'utente la benché minima possibilità di distinguere il vero dal finto.

Un attaccante per replicare questa esperienza ha bisogno di sole tre cose: un template convincente, un logo rubato e un campo password. L'URL stesso è diventato inutile perché abbiamo insegnato agli utenti a ignorarlo.

Perché gli URL non sono mai stati progettati per questo

Siamo onesti: la struttura degli URL è intrinsecamente confusionaria, e non dovremmo pretendere che utenti non tecnici li analizzino come sviluppatori.

Guarda questo URL:

https://login.staging.interno.esempio-corp.com/auth/verifica

La maggior parte degli utenti vede "staging" e "interno" e le si spegne il cervello. Cercano il nome dell'azienda, e anche quando lo trovano, non riescono a capire se l'infrastruttura circostante sia legittima o un'imitazione ben congegnata.

Il nome host si legge dal specifico al generale (login → staging → interno → esempio-corp → com), il che significa l'identificatore più importante—il dominio effettivo—è sepolto proprio nel mezzo. Gli utenti imparano a cercare un nome brand ovunque nell'URL, ed è esattamente l'abitudine che i phisher sfruttano.

Protocollo → Sottodomini → Dominio → TLD → Percorso
    |           |           |       |      |
  HTTPS      login      esempio   com   /auth

Gli sviluppatori capiscono questo intuitivamente. Gli utenti normali non hanno alcuna possibilità quando normalizziamo URL come:

https://auth.azienda.fornitore-sospetto.io
https://azienda.auth-fornitore.io/sso/abc123
https://auth-fornitore.io/accesso-azienda

La responsabilità degli sviluppatori

Ecco dove diventa rilevante per te: hai il potere di progettare esperienze di autenticazione che proteggono gli utenti di default.

invece di reindirizzare gli utenti attraverso un labirinto di domini di terze parti, considera questi principi:

1. Possiedi il tuo dominio di identità. Il tuo dominio brand principale dovrebbe gestire l'autenticazione. Se devi per forza usare provider di identità terzi, imponi l'uso di sottodomini personalizzati:

✓ https://login.tuapiattaforma.com
✗ https://auth.fornitore.com/tuapiattaforma

2. Gerarchia dei sottodomini coerente. Se la tua app principale sta su app.azienda.com, la tua autenticazione dovrebbe stare su auth.azienda.com—non sepolta tre livelli sotto l'infrastruttura di qualcun altro.

3. Reindirizza intelligentemente. Quando devi per forza linkare a servizi esterni (sondaggi, processor di pagamento, portali di supporto), usa reindirizzamenti lato server dal tuo stesso dominio. Questo dà agli utenti un'esperienza coerente e rafforza il messaggio: "se non viene dal nostro dominio, non è nostro."

4. Tratta SMS e numeri di telefono allo stesso modo. Messaggi tipo "chiama questo numero" o "invia un SMS con questo codice" sono altrettanto pericolosi dei link email. Inclui sempre informazioni di contatto su una pagina che i tuoi utenti già si fidano.

Costruire sicurezza che scala con gli utenti, non contro di loro

La terminologia RFC 2119 non è solo gergo burocratico—è una filosofia di progettazione. Quando la sicurezza dell'autenticazione è un "DOVREBBE" piuttosto che un "DEVE", ottieni la situazione che abbiamo oggi: un far west di servizi di identità federata dove i siti legittimi sono indistinguibili dalle truffe.

Le organizzazioni che vinceranno sulla sicurezza sono quelle che smetteranno di trattare gli utenti come l'anello debole e inizieranno a costruire sistemi dove la scelta sicura è quella facile.

Perché questa è la realtà: non puoi risolvere un problema di design con un corso di formazione sulla sicurezza.

Cosa significa per la tua startup o azienda

Se stai costruendo o manutenendo flussi di autenticazione, è il momento di un audit. Chiediti:

• Un utente che si collega per la prima volta può identificare la tua pagina di login solo guardando l'URL?
• Tutte le tue esperienze autenticate passano attraverso domini che i tuoi utenti riconoscono?
• Stai usando funzionalità BYO domain dei servizi di terze parti, oppure accetti i loro URL di default?

Non stiamo parlando di sicurezza teatrale—stiamo parlando di costruire fiducia. Gli utenti che si sentono sicuri nell'esperienza di autenticazione sono utenti che si fidano del tuo prodotto.

In NameOcean abbiamo visto come la strategia sui domini si intrecci con l'architettura della sicurezza. Il tuo dominio non è solo un indirizzo—è il fondamento della fiducia degli utenti. Assicurati che il tuo lavori per te, non contro di te.