Come dimostrare la proprietà di un sito web?

1

Sappiamo tutti come le banche si identificano agli utenti. No, non tramite i certificati TLS. Gli utenti non prestano attenzione a quelli. No, sto parlando di branding - tutti quei loghi fantasiosi e foto stock che ti danno l'impressione che sia il tuo vero sito bancario.

Il guaio è che chiunque può copiare le immagini per se stesso e fare un falso convincente del sito di una banca e indurre gli utenti a inserire la propria password bancaria, anche se il sito su cui si trovano è il dominio sbagliato. Questo è il motivo per cui il phishing funziona.

Quindi, poiché gli utenti non controllano il nome di dominio o la catena di certificati TLS, in quale altro modo possiamo dimostrare, prima che inseriscano la loro password, che si trovano su un sito di cui dovrebbero fidarsi? (ad esempio, mostrando un'immagine che l'utente potrebbe riconoscere, ma una terza parte avrebbe problemi a falsificare, come un captcha inverso)

(P.S.) L'ovvia soluzione alternativa non è affatto la richiesta di una password, come in Google Authentication, ma sto installando una serie di siti Web e sto cercando alternative.

    
posta fluggo 19.08.2015 - 00:59
fonte

3 risposte

1

Le misure di sicurezza si rafforzano in modo inversamente proporzionale alla convenienza ... quindi probabilmente non lo farei ... e non conosco un singolo sito che faccia questo ... ma ... l'hai chiesto.

Che ne dici di un flusso di lavoro come questo:

  1. L'utente accede al sito web e inserisce il nome utente
  2. Il sito cerca il numero di telefono dell'utente e invia un codice temporale o una parola casuale come SMS.
  3. Il sito visualizza un codice temporale e chiede all'utente di verificarlo rispetto al codice / parola inviato al telefono

I phisher non conosceranno il numero di telefono dell'utente. Potrebbero in teoria innescare l'unico codice temporale (via MITM) ma l'attaccante non conoscerebbe il codice. Quindi, se un utente vede un codice sulla pagina e sul telefono, (s) sa che il sito è buono.

    
risposta data 19.08.2015 - 02:41
fonte
1

Ne conosco uno che consente agli utenti di caricare un'immagine di loro scelta al momento della configurazione dell'account. (Possono essere modificati in seguito). L'immagine viene visualizzata nella schermata della password, dopo che è stato immesso l'ID utente. Immagine sbagliata o inesistente == sito web fasullo.

Vorresti utilizzare un programma di back-end per rendere le immagini di dimensioni standard e rimuovere i metadati prima di memorizzarli.

    
risposta data 19.08.2015 - 01:33
fonte
1

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.

    
risposta data 19.08.2015 - 07:11
fonte

Leggi altre domande sui tag