Il problema che stai cercando di risolvere è che il client deve essere identificato dal server (per sapere quale utente è), ma il server deve anche essere identificato in modo affidabile dal client per rilevare il phishing. Sono d'accordo sul fatto che semplicemente l'utilizzo di HTTPS per l'identificazione del server non è sufficiente, dal momento che un utente malintenzionato potrebbe semplicemente possedere un dominio simile (ad esempio paipal.com vs paypal.com) e ottenere un certificato per esso e quindi può anche fare HTTPS.
Il solito processo di identificazione del client da parte del server comporta una sorta di segreto condiviso, in cui il client invia questo segreto al server e il server lo verifica (ad esempio, accedendo con la password). Questo processo è ovviamente vulnerabile al phishing.
Le risposte esistenti su queste domande offrono così dei modi per far sì che l'utente rilevi almeno il phishing avendo un secondo segreto condiviso che viene poi presentato dal server e verificato dall'utente, cioè utilizzando il numero di telefono del cliente o qualche utente scelto immagine come secondo segreto. Ma questo secondo segreto non è sufficiente anche perché una volta che l'utente malintenzionato ha phishing l'utente per ottenere il segreto iniziale (la password) potrebbe essere in grado di determinare il secondo segreto dopo l'accesso.
Quindi l'immagine scelta dall'utente scelta da sola non è sufficiente perché l'aggressore può scoprire il segreto e riutilizzarlo. Solo la proposta basata su SMS risolve questo problema non mostrando il secondo segreto al client (e quindi all'attaccante connesso). Invece usa il segreto solo indirettamente per generare un altro (terzo) segreto (un token) e rende questo segreto noto all'utente in un modo che, si spera, non sia accessibile dall'aggressore. Il client deve presentare questo token segreto al server e quindi dimostrare la conoscenza del segreto. Naturalmente è anche possibile utilizzare un canale diverso come l'e-mail o la chat o una vera e propria telefonata (automatica) per trasmettere il terzo segreto, purché il canale stesso non sia accessibile dall'attaccante.
Ma mentre la proposta con il secondo canale suona bene, ha il problema, che dipende da questo secondo canale per sicurezza. Se questo canale viene compromesso dall'attaccante (ad esempio trojan allo smartphone che intercetta SMS), la sicurezza viene interrotta. E se questo canale non è disponibile (come nel caso di un telefono smarrito o rubato), non è possibile effettuare il login e quindi non modificare il canale protetto. Storicamente questo è un punto debole e spesso gli hacker hanno avuto accesso al sito chiamando il supporto e ingannando la persona dell'assistenza nel cambiare il numero di telefono o l'e-mail a uno controllato dagli hacker, ovviamente dopo aver risposto ad alcune domande di sicurezza in cui le risposte potevano spesso può essere facilmente scoperto.
A parte questo, nessuna di queste soluzioni risolve il problema quando l'hacker crea il proprio sito di phishing (ad es. paipal.com) e semplicemente trasmette inizialmente tutti i dati al sito originale (ad es. paypal.com) e, dopo aver ottenuto l'autorizzazione, interrompe dai clienti originali e usa la sessione stabilita per lo scopo degli attaccanti. Anche HTTPS semplice non aiuta in questo caso perché l'autore dell'attacco potrebbe ottenere anche un certificato per il suo sito di phishing.
Un modo alternativo per proteggere la comunicazione è utilizzare HTTPS insieme ai certificati client. Utilizzando la crittografia della chiave pubblica sottostante il client può essere identificato dal server e dal server dal client. L'autore dell'attacco potrebbe comunque creare un sito di phishing ma non può acquisire il segreto (ovvero la chiave privata del certificato client) necessario per il successivo riutilizzo. Perché spesso non è così ovvio per il cliente che è coinvolto un certificato client, quindi è ancora necessario un qualche tipo di rilevamento del phishing, ma in questo caso la presentazione dell'immagine scelta dall'utente potrebbe essere sufficiente. Poiché l'autore dell'attacco non è in grado di utilizzare il certificato del client reale per identificarsi rispetto al sito originale, non può né determinare l'immagine scelta dall'utente né l'attacco di inoltro descritto sopra possibile. Sfortunatamente il processo di utilizzo dei certificati client non è per lo più così user-friendly e anche il certificato deve essere incluso in ogni browser utilizzato dal client. Anche il certificato è condiviso tra tutti gli utenti del profilo del browser che potrebbero essere un problema anche se più utenti utilizzano lo stesso computer.