I campi username e password su pagine diverse sono più sicuri?

1. Da una prospettiva di controllo della sicurezza , tutto ciò che fa veramente è rallentare la capacità del software di verifica password automatico di eseguire il proprio compito di provare più password. Il sito spera che un utente malintenzionato possa scegliere un target "più morbido" anziché il proprio sito. Come un vero controllo di sicurezza, questa tecnica non è particolarmente efficace.
   • Inoltre, specificamente per le banche, questo è uno dei numerosi settori approvato "miglioramenti della sicurezza" che il settore bancario statunitense richiede banche membro tra cui scegliere. Negli Stati Uniti nel 2011, tutte le banche e le unioni di credito sono state informate della nuova politica di sicurezza informatica dal Consiglio federale d'esame delle istituzioni finanziarie ( link ), insieme con le presentazioni di guida di autenticazione ( link ). Ricordo la banca che utilizzo per convertire le pagine di accesso nel 2012 e 2013 per soddisfare i nuovi standard prima dell'audit annuale, incluso lo spostamento della password in una pagina separata dal userid.
   • Dato tutto il elenchi di password rubate, gli elenchi di indirizzi di posta elettronica rubati separati, il Infatti la maggior parte degli utenti usa la stessa password su tutti i siti che hanno account, e il fatto che la maggior parte dei siti stupidamente (da una sicurezza prospettiva) costringono gli user-id a essere indirizzi email, ci sono nuovi tipi di password "over-the-web" altamente selettiva "low-and-slow" sistemi di sondaggio che sfruttano tutto quanto sopra. Il sito spera quindi che la sequenza di login più lenta per eseguire il rilevamento automatico delle password possa far sì che gli aggressori si arrendano prima.
2. Da una prospettiva di progettazione dell'interfaccia utente di sicurezza , questo modello di progettazione dell'interfaccia utente offre alcuni vantaggi utili. Consente ai siti che lo adottano di aggiungere passaggi di autenticazione condizionale. Ad esempio, un sito può offrire ai propri utenti l'opzione per un token di messaggi di testo per creare un'autenticazione a due fattori. Per gli utenti che hanno fornito un numero di cellulare, la sequenza potrebbe essere: pagina1 = immettere id utente, pagina2 = immettere token, pagina3 = immettere password. Per quegli utenti che non hanno fornito un numero di cellulare, è solo page1 = inserire userid, page2 = inserire la password.
   • Questo modello di progettazione dell'interfaccia utente consente anche la conversione graduale della loro base di utenti a un'autenticazione più recente e più strong sia a intervalli di tempo che utente per utente , che sono entrambe considerazioni fondamentali per un sito con migliaia o più di utenti.
   • Un altro esempio, la banca che uso nel 2012 ha convertito le loro pagine di accesso per chiedermi prima l'id utente, poi mi chiede di confermare un'immagine che ho selezionato nel mio profilo da una serie di immagini, quindi alla fine chiede la mia password, tutto su pagine separate. Il fatto di scegliere o meno un'immagine da una serie di immagini aggiunge davvero l'efficacia dell'autenticazione è un problema separato dalla domanda relativa al modello di progettazione dell'interfaccia utente di accesso.
   • Un ulteriore esempio, alcune banche hanno scelto di implementare una "UI Keyboard" pertentarediostacolareikeylogger(useridèinseritosuunapaginaconunnormalecampoditestodell'interfacciautente,quindiunasecondapaginavienevisualizzataconla"tastiera dell'interfaccia utente". Si può discutere se una tastiera su schermo sia o non sia efficace in termini di sicurezza, ma il modello di progettazione dell'interfaccia utente configurabile e sequenziale su pagine separate consente ai siti questa libertà di innovare.
   • La maggior parte dei siti non interrompe prematuramente la sequenza di accesso se qualcosa viene inserito in modo errato. L'utente finale inserisce tutte le informazioni nelle varie pagine della sequenza e solo alla fine apprende se l'autenticazione ha avuto successo o meno. Alcuni siti escono presto, il che crea alcuni rischi residui istituzionali in termini di rilevamento della validità dell'account.
   • Quali passaggi di autenticazione specifici vengono mostrati possono anche variare a seconda del particolare ID utente dato ciò che l'utente ha selezionato nel proprio profilo. Quindi i siti che lo fanno non sono più costretti a offrire solo una sequenza di autenticazione fissa per tutti i loro utenti finali.
   • Anche i sistemi di accesso più avanzati di questo stile possono persino variare i passaggi di autenticazione per lo stesso utente finale che fallisce una prima autenticazione o accede da un computer / dispositivo sconosciuto o da un indirizzo IP che è significativamente fuori -area, o se il software IDS automatizzato del sito ritiene che sia in corso un attacco di rilevamento password.
   • La separazione dell'IDENTIFICAZIONE da AUTENTICAZIONE (ovvero user-id da password e altri passaggi) nell'interfaccia utente di accesso offre ai siti maggiore libertà e flessibilità nell'evoluzione dei processi di accesso nel tempo. I siti che cambiano le loro pagine di accesso a questo nuovo modello possono ulteriormente adattare o modificare la sequenza di accesso in futuro, ma i loro utenti finali non si sentono come se il processo di accesso stia cambiando molto.

Ho visto che questo usato da molti fornisce un modo per fare la scoperta del Realm a casa, quando sono coinvolti molti IDP.

Quando un utente digita il suo indirizzo email, la schermata successiva sarà l'IDP o, in caso di molte scelte possibili, un elenco di selezione, seguito da un reindirizzamento.

Un'altra possibilità è che questa tecnica confonde i gestori delle password, o le funzionalità incorporate in chrome "remember my password". Ci sono probabilmente modi migliori per farlo e, se fatto per questo solo motivo, può causare teatro della sicurezza .

Alcuni siti potrebbero consentire agli utenti di associare un'immagine o una frase non confidenziale con il proprio nome utente e mostrarlo prima che l'utente inserisca la propria password. A seconda dei meccanismi utilizzati per prevenire situazioni man-in-the-middle, un simile approccio potrebbe rendere più difficile per un phisher creare una pagina che, dato un nome utente, richiamerebbe rapidamente e facilmente l'immagine / frase associata a tale utente. In assenza del codice di riconoscimento MITM, nulla impedirebbe a un phisher di inserire una falsa schermata "nome utente", inviando il nome utente da quello nel modulo della banca e quindi rinviando la foto / frase dal sistema della banca, ma una banca i sistemi potrebbero incorporare vari meccanismi per cercare di impedirlo. Forse la più grande difficoltà sarebbe ottenere la compatibilità con il software di "sicurezza" che cerca di inserirsi da solo come man-in-the-middle sulle connessioni https: //.

Sospetto che non sia stato fatto per un vero motivo di sicurezza, invece questi due scenari potrebbero spiegarlo:

• Questo è semplicemente un artefatto su come il sistema è stato sviluppato piuttosto che qualcosa che sarebbe necessariamente reimplementato se stessero ricostruendo il sistema oggi.
• È stato suggeriva nelle risposte precedenti che le banche amano rendere i loro processi di autenticazione unici e più complicati dei tipici account online. Questo per far capire agli utenti che accedere alla loro banca è più sicuro che accedere a Facebook.

Potrebbe essere stato fatto per separare l'identificazione dell'account dai passaggi di verifica della password, ma se questo è il caso, posso solo concludere che ciò è stato fatto per qualche motivo diverso dalla sicurezza. Se l'identificazione del conto positivo viene indicata all'utente, si creerebbe una vulnerabilità di enumerazione dell'account e rendere il sistema meno sicuro piuttosto che più.

Alcuni sistemi di autenticazione hanno un "sigillo del sito personale" che dovresti identificare prima di inserire la tua password per prevenire il phishing, tuttavia questi sistemi di solito hanno qualche altra forma di autenticazione (ad esempio il nome da nubile della tua mamma) prima di mostrare il sigillato per te - che impedisce che gli account vengano enumerati e ai phisher di conoscere il sigillo del sito senza dover conoscere alcuni dettagli su di te. Questo è non considerato molto efficace però.

Un approccio a più fattori è raccomandato da ISO 27k e OWASP. Ma se si separa solo un campo ID utente e un campo password su pagine separate, ci sono alcune cose da considerare.

1. Un simile processo di login non ha nulla a che fare con la separazione dall'autenticazione dall'autorizzazione. Esiste solo l'autenticazione sotto forma di reclamo (il nome dell'account) e proof (la password). Per i siti regolari, l'autorizzazione è legata alle identità, quindi l'autorizzazione è automaticamente implicata da qualsiasi utente che sia in grado di dimostrare la propria identità.

2. Un tale processo di login non è ciò che si intende per ISO o OWASP, perché non esiste un processo multifattore per provare il reclamo, nessun canale extra come un servizio di messaggistica o un'impronta et cetera . In questo senso, non migliora la sicurezza.

3. Un simile processo di login ha pro e contro, a seconda delle aspettative dell'utente. Chiedendo prima solo il nome dell'account, gli utenti abituali non possono mescolare accidentalmente il nome dell'account con la password. Ma gli utenti più esperti che usano password lunghe e veramente casuali che non riescono a ricordare da soli, sperimenteranno un vero fastidio. Perché quegli utenti utilizzano la funzionalità di accesso automatico da gestori di password come KeePass e troveranno che non funzionerà quando i campi si trovano in pagine separate. Devono effettuare il login a mano, inserendo il nome dell'account e la password separatamente con ogni tentativo di accesso.

4. C'è un argomento secondo cui un simile processo di accesso potrebbe essere tecnicamente più sicuro, perché gli sviluppatori possono prendere altre misure per rallentare gli attacchi di forza bruta. D'altra parte, un metodo ibrido può essere implementato tramite AJAX, in modo che gli accessi automatici dai gestori di password funzionino ancora, i token CRSF possono essere utilizzati e gli ID di sessione non devono essere rilasciati prima che un utente sia completamente autenticato. In altre parole, gli argomenti tecnici e UX non devono necessariamente dipendere l'uno dall'altro.

5. È importante ricordare che i nomi degli account e le password saranno condivisi tra gli utenti. È prassi comune che un singolo utente abbia più account univoci e / o non univoci per lo stesso sistema. L'identificazione identifica sempre il account , piuttosto che un individuo vivo e unico. Le misure di sicurezza dovrebbero essere implementate pur essendo consapevoli di questo fatto della vita.

6. Molti siti comuni utilizzano un indirizzo e-mail per il reclamo di identità. Ma gli utenti possono cambiare gli indirizzi e-mail velocemente come i numeri di cellulare prepagati. E ogni volta che gli utenti usano più indirizzi, l'argomento che un utente ricorderà sempre i mailadres svanirà. Per UX, è un fastidio quando non è possibile modificare facilmente l'indirizzo e-mail con un nome di account corretto. Un nome account scelto avrà un vettore di attacco molto più piccolo perché è meno noto e può variare da un sistema o sito a un altro. Pertanto migliorerà la sicurezza dell'utente.