it-swarm-eu.dev

Sui moduli di accesso in due passaggi, perché è il nome di accesso e non la password che viene richiesta per prima?

Esistono diversi moduli di accesso (ad es. Di Google) su Internet in cui inserisci prima il nome di accesso e poi, una volta inviato, puoi inserire la password.

Uno dei vantaggi di questo è, suppongo, che il server può estrarre un'immagine che solo conosce e mostrarla all'utente per aiutare a sventare semplici schemi di phishing.

La mia domanda è: perché nessuno lo fa al contrario: prima chiedi una password e poi il nome di accesso.

Riesco a vedere la risposta ovvia (che la password potrebbe non essere unica e quindi il server non saprebbe di chi visualizzare le immagini anti-phishing), ma ciò non mi convince. Disabilitare immediatamente gli account che condividono password o almeno forzare gli utenti a cambiare le loro password in una stringa univoca al successivo accesso potrebbe essere un modo per aggirare questo problema e, a parte questo, risolverebbe il fenomeno delle password "123456".

Un altro problema che posso vedere è che in uno scenario di phishing in cui un utente immette correttamente la sua password e poi nota che gli vengono visualizzate le immagini sbagliate, gli è già stata data la password e tutto ciò che resta da fare per il phisher è identificare chi la password appartiene a.

Quello che vorrei sapere è se la sequenza login-then-password è principalmente dovuta a considerazioni sulla convenzione o all'interfaccia utente o se ci sono altri problemi di sicurezza con l'inversione della sequenza per chiedere prima la password (oltre ai due che ho menzionato ).

23
Out of Band

Una password solitaria non è necessariamente verificabile da sola. In particolare, se il server fa le cose correttamente, non memorizza le password stesse, ma l'output di un funzione di hashing della password calcolato sulla password. Una funzione di hashing della password (al contrario di una semplice funzione di hash) include alcune funzionalità extra, tra cui un salt (per ottime ragioni legate alla sicurezza). La verifica di una password richiede quindi la conoscenza del sale corrispondente. Poiché il salt è specifico dell'istanza (il punto del salt è che utenti distinti hanno i propri sali), è richiesta l'identità dell'utente (l'identità dell'utente viene utilizzata come chiave di indicizzazione per il salt).

121
Thomas Pornin

Per prima cosa il server non avrebbe saputo se la password da sola corrispondesse ad alcun account.

In un sistema sicuro, le password vengono salate e quindi hash.

In una demo semplicistica, supponiamo che avessi tre utenti:

Username  Password
bob       foobar
alice     foobar
maggie    foobar

Quando vengono impostate queste password, viene aggiunto un salt e viene generato un hash:

Username  Salt      Value to hash     Hash result
bob       ABCDEF    ABCDEFfoobar      778f9aab91717e420e447d7e4cdd84f1
alice     123456    123456foobar      17e9191daecc5b8be26779209769b275
maggie    ZXCVBN    ZXCVBNfoobar      527cb07b112559cf9c1aff19d28074fa

Come puoi vedere, lo scopo di Salt è che non sono memorizzate due password uguali, anche se la password può corrispondere. Questo è un passo importante per la sicurezza per impedire che le tabelle Rainbow vengano utilizzate in un elenco di password estratto.

Ciò rende impossibile determinare a quale account si sta effettuando l'accesso solo sulla base della password, poiché il sale da utilizzare non è noto. Questo perché il nome utente viene utilizzato come chiave per la ricerca e senza che venga fornito al server, la password immessa al passaggio 1 non può essere abbinata senza provare ogni hash nella tabella utente fino a quando non viene trovata una corrispondenza. Su un sistema correttamente configurato questo sarebbe troppo lento, perché stai usando un algoritmo lento (vedi nota a piè di pagina).

Inoltre, sarebbe una grande perdita di informazioni sulla sicurezza se il sistema ti dicesse che la tua password è stata utilizzata da un altro.

L'esempio sopra è solo a scopo illustrativo e utilizza MD5. Non utilizzare mai MD5 per eseguire l'hashing delle password: utilizzare bcrypt, scrypt o pbkdf2.

82
SilverlightFox

Non stai praticamente chiedendo "C'è qualche motivo per cui non abbiamo password pubbliche e nomi utente privati?"

Sono entrambi solo stringhe di testo. La tua idea di imporre password uniche sta davvero solo dicendo che i nomi utente sono unici. L'etichetta che applichi a una casella di testo non è importante. Chiamiamo la stringa privata che è una password e quella unica un nome utente o ID utente perché è unica.

Dal punto di vista della sicurezza e osservandolo nel normale ordine di Login/Password: se si richiedesse entrambi di essere univoci, si aprirà un attacco al database, poiché ogni password verificata verrebbe confrontata con ogni utente nel database perché hai richiesto che le tue password siano univoche. Quindi entrambi non funzionano. Entrambi non unici non funzionano perché non sai a quale account si accede. Quindi questo lascia solo una stringa unica. Se stai creando una singola stringa di testo univoca, potresti anche renderla un dato pubblico e verificarlo prima (e noi chiamiamo questi dati Login/ID/Nome utente).

25
Black

Immaginiamo un'analogia ...

Sono un messaggero inviato dal mio re per consegnare un messaggio a un certo castello nella Valle dei Castelli. So com'è il castello in cui voglio andare e mi è stata data una passphrase per dire alla guardia in modo che potessi entrare nel castello.

Ho due opzioni su come farlo:

  1. Come ci si aspetterebbe senza dubbio, il modo convenzionale per farlo è quello di andare al castello in cui sono stato inviato e quindi dire loro la passphrase per entrare. Questo è prima di tutto usando le mie informazioni pubbliche (il castello, visibili a chiunque voglia per guardarlo) per accedere con le mie informazioni private (la passphrase).

  2. Ma c'è un modo inverso per farlo. Posso prendere un corno e gridare la mia passphrase in tutta la valle per essere ascoltata dal pubblico. Dal momento che il castello che intendo visitare ha sentito la mia passphrase (insieme a tutti gli altri castelli e agli abitanti potenzialmente nefasti della valle), il castello che sto visitando dovrebbe sapere di aspettarmi.

    Procedo quindi a cavallo verso il castello corretto e attraverso il ponte levatoio aperto. Ma avrebbero lasciato entrare chiunque attraverso questo ponte levatoio aperto! Ora che le mie informazioni private sono state condivise con il mondo, chiunque può cavalcare tra i castelli ed entrare in quello con il cancello aperto.

    Se non sono qui per urlare questo in un corno, i residenti della valle potrebbero stare in cima a una collina con il proprio corno, urlando senza parole attraverso la valle fino a sentire il tonfo di un ponte levatoio aperto; sapendo di aver indovinato correttamente una passphrase, devono semplicemente cavalcare tra i castelli fino a quando non ne trovano uno aperto.

La prima opzione è come di solito viene eseguita. Non c'è motivo di cambiare quella convenzione. L'alternativa è possibile, ma condividendo prima le tue informazioni private, rendi molto più facile indovinare la password di tutti in una volta prima di autenticarti con informazioni pubbliche, cioè andare in ogni castello o provare tutto il pubblico nomi degli account. Con migliaia di castelli in questa valle o account su un sito Web, è molto probabile che qualcuno indovinerà una password semplice e quindi è molto più semplice abbinarla semplicemente con una delle poche migliaia di castelli o nomi di account pubblici.

12
Keavon

Google non ti ha inserito prima nella tua e-mail per nessun motivo di sicurezza. Ti ha inserito la tua e-mail/nome utente, quindi se stai accedendo a un dominio di lavoro o di istruzione che vuole avere la propria landing page per SSO/SAML

9
Doryx

Se si richiede prima la password, è necessario mantenere il valore "segreto" in alcuni stati mentre si attende il nome utente. Con un'app Web, in genere è necessario eseguire tale archiviazione in qualche modo in modo che un nuovo processo possa leggere il valore, poiché il nome utente verrebbe inserito in una seconda richiesta. Ciò aumenta la finestra di opportunità per la divulgazione della stringa di password, sia in termini di tempo che in termini di modi per accedere ai dati.

Richiedendo prima il nome utente, la verifica della password che utilizza l'hash salato (o meno) può già avere accesso a tutto il necessario per verificare immediatamente la password e il sistema deve solo disporre della password stessa per un minimo di tempo. In genere è meglio avere dati sensibili disponibili il meno tempo possibile.

Ed è una convenzione. Chiedendo prima la password, finirai per addestrare gli utenti a digitare accidentalmente la loro password nei campi nome utente altrove, probabilmente con conseguente divulgazione attraverso i registri.

Non farlo. :)

7
dannysauer

Da aggiungere; il meccanismo di identificazione vs autenticazione/verifica viene deciso durante lo sviluppo dell'applicazione. L'identificazione è 1: molti, la verifica/autenticazione è 1: 1

    1:1 - match against one pre-selected result set;

    1:many - match against all results in the DB

Nomi utente come Gmail sono unici. Questo non è obbligatorio per tutte le applicazioni, ma sicuramente semplifica la vita dell'algoritmo di verifica rispetto all'algoritmo di identificazione.

Considera il nome utente popolare quindi l'autenticazione password per Gmail:

  1. inserisci il nome utente;

    gmail corrisponde al nome utente univoco mentre tutti gli altri nomi utente univoci; Sì abbina, inserisci la password; Nessuna corrispondenza, nessun accesso.

  2. Inserire la password.

    gmail corrisponde solo al nome utente 1 con la password 1 memorizzata in qualsiasi formato; Nessuna corrispondenza, autenticazione non riuscita. Sì abbina, accedi alla tua posta.

IMHO abbastanza semplice.

Dall'altro lato, l'identificazione (1: molti), il processo di abbinamento di Gmail sarebbe così:

  1. inserire la password; e come indicato chiaramente da @SilverlightFox, molti account possono avere la stessa password.

    matching algorithm matches password to ALL usernames registered in gmail database.
    

    Un set di risultati troppo prudente può essere 10 nomi utente.

  2. Inserire username;

Se i nomi utente sono univoci o possono essere uguali, deciderà per quanto tempo più verrà eseguito il processo di autenticazione e quante corrispondenze vengono rilevate. Se più di 1 corrispondenza, dovremo implementare l'autenticazione dell'accesso in 3 passaggi.

L'autenticazione in due passaggi semplifica la vita dello sviluppatore e dell'algoritmo.

1
Ombongi Moraa

Nel caso di google e della maggior parte delle impostazioni di autenticazione divisa, il sistema utilizza sostanzialmente l'id utente per identificare il rischio associato e determinare il processo di accesso appropriato che dovrebbe essere eseguito per l'utente.

Nel caso della maggior parte di queste situazioni, l'id utente inserito dalla persona è solo un input preso in considerazione. Insieme ad esso molte altre informazioni (come l'indirizzo IP da cui si accede, il dispositivo che l'utente sta utilizzando - c'è una firma del dispositivo generata e passata insieme all'ID utente) viene passata a un motore di determinazione del rischio (nella maggior parte delle banche ma potrebbe non essere sempre utilizzato) che potrebbe fornire la procedura di accesso suggerita. Oltre a quel sistema controlla la politica di accesso associata all'utente (ad esempio se ha multi-factor abilitato per esempio). In base alla determinazione finale, la maggior parte delle volte potresti semplicemente ottenere una semplice schermata di password, ma in alcuni casi ti potrebbe essere chiesto di avviare un processo di autenticazione multipla (ad esempio OTP basato su telefono, ecc.).

1
jhash