Nuovo sistema di accesso a Gmail, contro la saggezza convenzionale?

Per i siti più piccoli, non si vuole consentire agli hacker di elencare i propri elenchi di utenti, ma per Google, il sito è così grande, si può presumere che quasi tutti abbiano un account o più account. Quindi, il rischio è ridotto al minimo dopo una soglia di ubiquità.

È ancora una buona idea che la maggior parte dei siti non divulghi se esiste un nome utente, ma il rischio deve essere valutato rispetto al nuovo processo di registrazione dell'utente. Quello che vuoi impedire è un processo automatico dall'enumerazione dei tuoi elenchi. Il nuovo processo di registrazione dell'utente dovrebbe includere qualche forma di ritardo o gate in modo che uno script non possa provare rapidamente un dizionario di utenti. Ciò si ottiene spesso inviando un'email con i risultati della procedura di registrazione non riuscita. Sì, si potrebbe ancora enumerare, ma c'è un ritardo e un ulteriore passaggio.

Un'altra cosa da considerare è la differenza tra un sito pubblico e un sito privato. Google è un servizio pubblico e anche i nomi utente sono pubblici (divulgati con ogni e-mail inviata da un account). D'altro canto, un sito aziendale interno, a cui possono accedere solo gli attuali dipendenti, è privato e richiede controlli più rigorosi per impedire l'enumerazione.

Jeff Atwood, quando ha effettuato il login per Discourse, ha avuto questo da dire sull'argomento:

This was the source of a long discussion at Discourse about whether it made sense to reveal to the user, when they enter an email address in the "forgot password" form, whether we have that email address on file. On many websites, here's the sort of message you'll see after entering an email address in the forgot password form:

If an account matches [email protected], you should receive an email with instructions on how to reset your password shortly.

     

Si noti che la "se" è "là", che è una copertura contro tutte le implicazioni sulla sicurezza di rivelare se un determinato indirizzo email esiste nel sito semplicemente digitandolo nel modulo della password dimenticata.

     

Siamo seriamente intenzionati a scegliere le impostazioni predefinite sicure per il Discorso, così da non essere sfruttato, abusato o invaso dagli spammer. Ma dopo aver sperimentato il mondo reale "quale email abbiamo usato qui di nuovo?" stato di accesso su dozzine di istanze Discourse, ci siamo resi conto che, in questo caso specifico, essere user friendly è molto più importante che essere sicuri.

Per Gmail, puoi determinare se un account esiste semplicemente inviando un'email a un indirizzo @gmail.com . Se rimbalza, quell'account non esiste.

Questo è vero per molti provider di posta elettronica. Qui, i nomi utente non sono considerati segreti. Se un utente ha l'indirizzo email [email protected] tutti sanno che foo ha un account su example.com con nome utente [email protected] .

Tuttavia, per la maggior parte degli altri sistemi è una violazione della privacy rivelare i nomi utente. Se qualcuno può scoprire che [email protected] ha un account a nostringsattacheddating.example.org e la moglie di Bob, Alice, può provare a registrarsi con lo username [email protected] sul sito web e dice che il nome utente è già in uso, quindi è una grande violazione della privacy.

Ricorda che l'indirizzo email ha le sue radici nel provider di posta elettronica. Non c'è perdita di privacy se [email protected] è noto per avere un account in example.com , in quanto non esiste un punto di riferimento per chi è [email protected] . Lo stesso non è vero per un altro sistema che utilizza l'e-mail come nome utente - un utente con nome utente [email protected] su un sito Web non di posta elettronica avrà lo stesso [email protected] registrato su altri siti Web. C'è privacy per proteggere su quali account Mallory ha.

Inoltre, rivelare nomi utente può essere utile per un utente malintenzionato. Questo è noto come vulnerabilità di enumerazione del nome utente. Se un utente malintenzionato sa quali sono i nomi utente, quindi può eseguire un attacco indovinare la password .

As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

Consente inoltre agli aggressori di scegliere come target gli utenti del sistema tramite phishing.

È facilmente possibile progettare un sistema in cui l'enumerazione degli utenti non può essere eseguita. Ad esempio, i processi di registrazione e password dimenticati sono la stessa cosa.

I passaggi sono:

1. Il sistema richiede il proprio nome utente (email) su una singola pagina, senza altri campi di input.
2. Una volta inviato il modulo, il sistema chiede all'utente di controllare il proprio account di posta elettronica.
3. Se l'account esiste, l'email contiene un link per la reimpostazione della password.
4. Se l'account non esiste, l'email contiene un link di registrazione.

Come bonus, hai convalidato il loro indirizzo email al momento dell'iscrizione nel caso in cui fosse necessario reimpostare la password in un secondo momento. Qualsiasi errore di battitura significherà che l'utente non può registrarsi affatto, il che è positivo perché un utente non utilizza accidentalmente un account registrato su un indirizzo email diverso.

Sia la password che i link di registrazione contengono un ID casuale crittograficamente sicuro, quindi non possono essere seguiti senza ricevere l'e-mail. Solo chi ha accesso all'account può scoprire se un nome utente è registrato o meno (è meglio che Bob mantenga segrete le sue password di posta elettronica e portatile da Alice). Sarebbe saggio per lui disattivare i suoni di notifica nel caso in cui Alice provasse questo processo quando anche nella stessa stanza)

Vedi alcune delle mie altre risposte per argomenti correlati:

• Come impedire l'individuazione della posta elettronica nei moduli?
• È sicuro avere una funzione" email non più disponibile "sul modulo di registrazione?
• Dovrebbe essere verificata l'email essere seguito da un accesso basato su password? Perché?
• Best practice per il modulo per la password dimenticata, ok per segnalare che una determinata e-mail non è valida
• È sicuro generare una password per un utente durante la registrazione in un'applicazione web?

Sono sicuro che la regola si è sviluppata nei giorni del "grande ferro", quando tutti i conti erano su grandi sistemi aziendali o governativi. Dal momento che il sistema ha cancellato i nomi degli account, l'uso di una pagina di registrazione per cercare i nomi degli account non era un problema. Pertanto, mantenere l'elenco dei nomi account era fattibile e amp; utile.

Ora che abbiamo a che fare con i siti di auto-registrazione, è impossibile mantenere segreto l'elenco dei nomi degli account. Inoltre, così tante persone in questi giorni rendono pubblico il loro nome account. In queste condizioni, è inutile cercare di nascondere il fatto che era il nome che ha fallito al posto della password.

Sapere quale nome utente esiste o meno non è importante, perché un utente malintenzionato può anche controllarlo dalla pagina di registrazione. Google non ammette che un utente malintenzionato esegua un attacco come attacco a forza bruta per ottenere un elenco di nomi di utenti.

C'è un motivo più importante per richiedere prima il nome utente e quindi la richiesta di password: consente a Google di offrire un'interfaccia utente diversa per gli account che utilizzano autenticazione senza password o altri meccanismi di accesso sperimentali senza rivelare in anticipo quali account lo stanno utilizzando.

È simile a come l'UI di autenticazione di 2Factor di Google non viene visualizzata fino a quando non viene immessa la password: un utente malintenzionato non sarà nemmeno a conoscenza del fatto che un secondo fattore è coinvolto fino a dopo aver scoppiato il primo fattore.

In combinazione con ciò che altre risposte stanno dicendo in merito al non rischio relativo di perdite di nomi utente, questo mi sembra un miglioramento della sicurezza.

Gli indirizzi email non sono uguali ai nomi utente. Un nome utente è informazioni semi-private (potenzialmente), ma un indirizzo e-mail è pubblicamente divulgabile e rinviabile pubblicamente. Pensa alla posta ordinaria, l'indirizzo postale se spesso è ben noto, ma l'attuale elenco di destinatari validi non è necessariamente progettato per essere pubblico, anche se ci sono spesso modi per vederlo anche online. Nel caso di qualcosa come Google, hanno Google+, YouTube, Google Gruppi, ecc. Che rendono già noti molti degli indirizzi.

È anche banale interrogare un server di posta elettronica e determinare se esiste un determinato indirizzo di posta elettronica, utilizzando telnet o molti siti Web lo faranno per te . C'è poco da guadagnare dalla protezione delle informazioni che è facilmente accessibile in altri modi. Questo è il motivo per cui alcuni siti separano l'indirizzo email per il nome utente. Nel caso di un provider di posta elettronica, non ha senso avere un nome di accesso diverso e quindi un indirizzo di posta elettronica per l'utente medio (forse quelli di noi che sono più paranoici della sicurezza vorrebbero che quella funzione).

Il passaggio a un accesso in due fasi riduce la probabilità che la password di un utente venga inserita in un campo di ricerca o nel campo del nome utente. Questi campi vengono spesso registrati e i registri vengono correlati in tutto il luogo e hanno meno probabilità di essere protetti. Quindi, se i registri vengono attaccati da un hacker o da uno stato nazione, l'utente malintenzionato potrebbe essere in grado di correlare l'indirizzo IP dell'utente con il proprio nome utente e quindi notare qualcosa come "m7p @ 55w0rd !!!!" che sporge e assume una sua password.

In termini di gestione del rischio, il rischio di esposizione della password è molto maggiore del rischio di enumerazione di username. Google probabilmente ha un solido monitoraggio anti-frode e anomalie per affrontare i rischi associati ai nomi utente conosciuti.

Penso che un buon modo per capire questo è l'esempio di Tire Swing nella introduzione di FAIR (pdf) . Il calcolo del rischio di un nome utente conosciuto è influenzato dagli altri controlli e fattori. Arresti gli attacchi di forza bruta, richiedono l'autenticazione a più fattori, in che altro modo è possibile ottenere queste informazioni? Nello scenario, in pratica stai scambiando tra un rischio che hai sotto controllo (monitoraggio di tutti gli accessi) rispetto a qualcosa sul vecchio modulo che è più difficile da controllare (la password viene digitata dall'utente nell'area sbagliata).

Ho intenzione di uscire su un ramo e dire che probabilmente hanno alcuni meccanismi in atto per garantire che non sia un repository aperto di utenti.

Abbiamo implementato un sistema simile su il nostro piccolo sito utilizzando una soluzione redis backed.

Gli utenti sono inizialmente presentati con una semplice email / pass con un pulsante per l'accesso e la registrazione. Dopo aver inserito la loro e-mail e andare avanti è controllato per una partita e se abbinato il pulsante di registro viene rimosso. In caso contrario vengono presentati con il modulo di registrazione completo.

Monitoriamo il numero di tentativi da subnet ip e blacklist dopo una determinata soglia. La blacklist non ha alcun impatto sulla loro capacità di utilizzare il sito, ma semplicemente ritorna al comportamento standard delle opzioni di login / registrazione.

Sì, hanno sistemi in atto per prevenire gli abusi. Google ha estesi meccanismi di "rilevamento delle anomalie" che servono errori o captcha quando la tua attività è sospetta: gli esempi più noti sono i blocchi della ricerca Google e del ReCaptcha NoCaptcha.

Il fatto che tu sia stato permesso di sapere se quell'account esiste non significa che tutti lo farebbero né che potresti effettivamente indovinare il nome utente di qualcun altro. Prova e facci sapere per quanto tempo prima che tu sia bloccato, è un test interessante.

Praticamente tutti già stanno facendo questo

I noticed that the new gmail login asks for username first, and then confirms if such username exists, before asking for password input.

Google ha già questa funzione. Quando provi a registrarti per un nuovo account Google, deve verificare se il nome utente esiste già o meno.

Does this not go against conventional security wisdom to not divulge information about whether an username exists, to thwart the class of attacks that tries many possible usernames?

Se non hanno controllato, come si autenticherà correttamente? Più persone con lo stesso nome utente sono cattive notizie per l'integrità del sito web. Naturalmente, in molti casi, potresti utilizzare indirizzi email univoci e consentire a più persone di avere lo stesso nome.

Come ho detto prima, praticamente tutti lo stanno già facendo in qualche modo. Non c'è nulla di cui preoccuparsi qui. Se vuoi rallentare l'enumerazione di massa dei nomi utente, includi solo un captcha dopo alcuni tentativi.

I captcha non possono in realtà impedire i trucchi per la spedizione di massa

Gli spammer inviano spesso grandi quantità di spam agli indirizzi e-mail. Mentre Google può spingere l'email nella cartella spam, ciò non impedisce l'enumerazione tramite e-mail non rimbalzanti.

È banale creare un mass mailer che utilizza migliaia di indirizzi IP diversi e quindi tentare di enumerare non ricevendo un'e-mail rimbalzata. Potresti anche inviare rifiuti casuali. Ricorda che se il tuo obiettivo è verificare se esiste o meno un indirizzo email, sarà sufficiente non ricevere un'email di errore dopo alcuni giorni.