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

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

Per prima cosa il server non saprebbe se la password corrisponde a qualsiasi account.

In un sistema sicuro, le password vengono salate e quindi sottoposte a hashing.

In una demo semplicistica, supponiamo di avere 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 ci sono due password memorizzate uguali, anche se la password potrebbe corrispondere. Questo è un passo importante per la sicurezza da adottare per evitare che le tabelle arcobaleno vengano utilizzate in un elenco di password estratto.

Ciò rende impossibile determinare a quale account si sta effettuando l'accesso sulla base della sola password, poiché il sale da usare non è noto. Questo perché il nome utente viene utilizzato come chiave per la ricerca e senza che venga fornito al server, la password immessa nel passaggio uno non può essere confrontata senza provare ogni hash nella tabella utente fino a quando non viene trovata una corrispondenza. Su un sistema configurato correttamente 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'altra.

_{L'esempio sopra è solo a scopo illustrativo e utilizza MD5. Non usare mai MD5 per le password di hash: usa bcrypt, scrypt o pbkdf2.}

In sostanza non stai chiedendo "C'è qualche ragione per cui non abbiamo password pubbliche e nomi utente privati?"

Sono entrambi solo stringhe di testo. La tua idea di applicare password univoche sta solo dicendo che i nomi utente sono unici. L'etichetta applicata a una casella di testo non ha importanza. Chiamiamo la stringa che è una password privata e l'unica un nome utente o ID utente perché è unica.

Sicurezza e guardandolo nel normale ordine di Login / Password: se richiedeste entrambi di essere unici allora avreste aperto un attacco al database, perché ogni password controllata sarebbe stata controllata contro ogni utente nel database perché hai richiesto che le tue password fossero uniche . Quindi entrambi unici non funzionano. Entrambi non univoci non funzionano perché non si sa a quale account si sta accedendo. Quindi questo lascia solo una sola stringa unica. Se stai creando una singola stringa di testo, potresti anche renderla pubblica e controllarla prima (e definiamo questi dati Login / ID / Nome utente).

Immaginiamo un'analogia ...

Sono un messaggero inviato dal mio re per consegnare un messaggio a un certo castello nella Valle dei Castelli. So a cosa assomiglia il castello a cui voglio andare e mi è stata data una passphrase per dirlo alla guardia in modo da poter entrare nel castello.

Ho due opzioni su come fare questo:

1. Come senza dubbio ti aspetti, il modo convenzionale per farlo è andare al castello in cui sono stato inviato e poi dire loro che la passphrase deve essere inserita. Questo è il primo utilizzo delle mie informazioni pubbliche (il castello , visibile a chiunque voglia guardarlo) per accedere con le mie informazioni private (la passphrase).

2. Ma c'è un modo inverso per farlo. Posso ottenere un corno e urlare la mia frase segreta in tutta la valle perché il pubblico ascolti. Dato che il castello che intendo visitare ha ascoltato la mia frase segreta (insieme a tutti gli altri castelli e ai potenzialmente nefandi residenti della valle), il castello che sto visitando dovrebbe sapere aspettarmi.

   Quindi procedo a cavallo verso il castello corretto e cavalco attraverso il suo ponte levatoio aperto. Ma lascerebbero 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 e entrare in quello con il cancello aperto.

   Se non sono qui per urlare questo in un corno io stesso, gli abitanti della valle potrebbero stare in cima a una collina con il loro corno, urlando senza senso attraverso la valle finché non sentiranno il rumore di un ponte levatoio che si apre; sapendo di aver indovinato una passphrase, devono semplicemente cavalcare tra i castelli finché non ne trovano uno aperto.

La prima opzione è come solitamente si fa. Non c'è motivo di cambiare quella convenzione. L'alternativa è possibile, ma prima condividendo 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 di account. Con migliaia di castelli in questa valle o account su un sito web, è molto probabile che qualcuno indovini una password facile e quindi è molto più semplice abbinarlo semplicemente con uno dei pochi migliaia di castelli o nomi di account pubblici.

Google non ha inserito prima l'e-mail per motivi di sicurezza. Ti ha inserito nella tua email / nome utente, quindi se stai effettuando l'accesso a un dominio di lavoro o istruzione che desidera avere una propria pagina di destinazione per SSO / SAML

Se chiedi prima la password, devi mantenere il valore "segreto" in qualche stato mentre aspetti il nome utente. Con un'app Web, in genere è necessario eseguire tale archiviazione in un modo che consenta a un nuovo processo di leggere il valore, in quanto il nome utente verrà inserito in una seconda richiesta. Ciò aumenta la finestra di opportunità per la stringa di password da divulgare, sia in termini di tempo che in termini di modi per ottenere i dati.

Chiedendo prima il nome utente, la verifica della password che utilizza hashing salato (o meno) può già avere accesso a tutto il necessario per verificare immediatamente la password e il sistema deve solo avere la password stessa disponibile per un minimo di tempo. Generalmente è meglio avere i dati sensibili disponibili per il minor tempo possibile.

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

Non farlo. :)

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

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

    1:many - match against all results in the DB

I nomi utente come Gmail sono unici. Questo non è obbligatorio per tutte le applicazioni, ma sicuramente rende la vita più semplice per l'algoritmo di verifica rispetto all'algoritmo di identificazione.

Considera il nome utente popolare, quindi l'autenticazione della password per gmail:

1. inserisci il nome utente;

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

2. Inserisci password.

   gmail corrisponde semplicemente al 1 nome utente con la 1 password memorizzata in qualsiasi formato; Nessuna corrispondenza, autenticazione fallita. Sì alla partita, accedi alla tua posta.

IMHO piuttosto semplice.

Prendendo l'altro lato, identificazione (1: molti), il processo di corrispondenza di Gmail sarebbe simile a questo:

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

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

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

2. Inserisci il nome utente;

Se i nomi utente sono unici o possono essere uguali, deciderà su quanto tempo più verrà eseguito il processo di autenticazione e quante corrispondenze verranno trovate. Se più di una corrispondenza, dovremo implementare l'autenticazione di accesso in 3 fasi.

L'autenticazione in due passaggi semplifica la vita allo sviluppatore e all'algoritmo.

In caso di google e gran parte della configurazione dell'autenticazione divisa, il sistema utilizza fondamentalmente l'id utente per identificare il rischio associato e determinare il processo di accesso appropriato che deve essere eseguito per l'utente.

In caso di molte di queste situazioni, l'ID utente inserito da una persona è considerato come un solo input. Insieme a 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 passato a un motore di determinazione del rischio (nella maggior parte delle banche ma potrebbe non essere sempre utilizzato) che potrebbe fornire una procedura di accesso suggerita. Oltre a questo sistema controlla la politica di accesso associata all'utente (ad esempio se è abilitato a più fattori, ad esempio). In base alla determinazione finale, la maggior parte delle volte potresti semplicemente ottenere una schermata con una password semplice, ma in alcuni casi ti potrebbe essere richiesto di eseguire più processi di autenticazione (ad esempio OTP basato su telefono, ecc.).