Ho letto degli attacchi dell'omicidio IDN , e non riesco a pensare a un modo migliore per affrontarli rispetto a
C'è davvero nient'altro che posso fare?
- Tell my users not to trust emails asking for passwords, etc
Questa è una buona mossa. Potresti rafforzare questo messaggio non inviando mai alcun tipo di email contenente link. L'unica difficoltà è che molti client di posta elettronica convertiranno automaticamente stringhe che assomigliano a indirizzi web a link cliccabili. Puoi reiterare che gli utenti debbano digitare l'indirizzo nel proprio browser per accedere al proprio sito e non fare clic sul collegamento.
- Buy all domains similar to mine (expensive and difficult)
Is there really nothing else I can do?
L'articolo di Wikipedia contiene una sezione su Difesa contro l'attacco . Questi sono tutti basati sul browser. Puoi incoraggiare gli utenti a utilizzare solo i browser che proteggono dagli IDN. Ad esempio, l'approccio di Chrome è:
Google Chrome displays an IDN only if all of its characters belong to one (and only one) of the user's preferred languages.
L'autenticazione a due fattori può proteggere dal rischio che un utente malintenzionato esegua correttamente il phishing di un nome utente e una password e quindi utilizzi quelli per accedere da solo. Tuttavia, se l'utente pensa di essersi autenticati con successo con il proprio sito, questo non fa nulla per mitigare il rischio che l'utente divulga ulteriori dettagli nella sessione di accesso con il sito dell'aggressore. Inoltre, un utente malintenzionato potrebbe ottenere il proprio sito di phishing per chiedere il secondo fattore di autenticazione e inserirli semplicemente nel sito originale quando l'utente inserisce quelli sul sito di phishing (a condizione che l'autore dell'attacco effettui il phishing in tempo reale anziché controllare i log del server in una seconda volta).
Chiedere solo alcune lettere dalla password può essere facilmente aggirato. I siti di phishing in genere diranno semplicemente che le due lettere inserite non sono corrette e quindi ne chiedono altre due fino a quando non viene scoperta la password completa. Questo significa anche che non è possibile salvare l'hash della password e che i gestori di password di solito hanno problemi nel riempire campi dinamici come questi.
Un'altra soluzione per mitigare il phishing in generale è incoraggiare l'uso di gestori di password basati su browser. Questi controllano che l'URL corrisponda a quello memorizzato nel gestore password in modo che non completi la password se ci sono attacchi di omografo in corso.
Il mio suggerimento sarebbe di usare l'autenticazione a due fattori. Se scegli di non utilizzare l'autenticazione a due fattori, ti suggerirei di uscire dal gioco di autenticazione e usare "accedi con *" dove * è facebook / google / yahoo ecc., Questo sposta l'onere di prevenire attacchi di pesca alle aziende che hanno il soldi e risorse per farlo bene.
Vedi link per un esempio di un secondo facile ed economico fattore da usare.
Come ultima risorsa è possibile utilizzare uno schema a due password, noto anche come password più una domanda segreta. Se la seconda password raccoglie solo determinate lettere della password e le lettere che raccogli cambiano su ogni accesso, ad esempio:
Username: ......
Password: ......
3rd, 6th and 7th letter of secret word:
3rd .. 6th .. 7th ..
Ciò aumenterà le possibilità che l'utente noti un attacco di pesca prima che l'attaccante abbia trovato sufficienti informazioni per accedere come utente.
I gestori di password (anche le password memorizzate nei browser), che compilano automaticamente domini specifici, sono invulnerabili a tali attacchi; almeno possono aiutare a proteggere dai furti di password.
A loro non importa come viene visualizzato un dominio e se sembra simile, cercano la stringa effettiva nel loro database.
Il login basato su certificato è generalmente invulnerabile a questo attacco; mentre un utente potrebbe essere "correttamente" connesso a un sito attaccante, non non ottiene alcuna credenziale e potrebbe anche non eseguire un attacco man-in-the-middle.
Questo è principalmente un problema di formazione dell'utente. Il consiglio che preferisco è:
Save the URL for the site in your bookmarks. When logging in, open
the bookmark, then enter your login details.
Un'altra cosa che puoi fare è ottenere un certificato Extended Validation (EV). È probabile che un dominio spoofed non abbia un certificato EV, che dia una differenza visibile agli utenti.
Un approccio per utenti esperti è utilizzare un gestore di password integrato nel browser che leghi le credenziali a un determinato dominio. Poiché il gestore password esegue un confronto programmatico dei domini, non è vulnerabile allo spoofing per omografo.
Sfortunatamente gli attacchi omografici e il suo predecessore gli attacchi urf grassi sono una di quelle cose che è molto dipendente dall'utente. Potresti spingere la responsabilità verso i registrar dei nomi di dominio, gli emittenti dei certificati o ietf (cosa c'è di sbagliato con ascii :), ma avrai bisogno di un approccio a 2 poli per questo.
A seconda dell'esborso del budget, questi potrebbero diventare molto costosi.
La soluzione 2FA è ottima poiché ora hai un canale di comunicazione fuori banda per effettuare la verifica, ma dovresti fidarti anche del provider. Tutto si riduce alla gestione del rischio e se la perdita di qualsiasi dato è uno stopper.
Ho appena scoperto il seguente plug-in per chrome che codifica urls come phunycode a tutti tempo di proteggere da questo nuova forma di sfruttamento . Se qualcuno ha il tempo di controllare l'estensione di malware che sarebbe bello.