it-swarm-eu.dev

Divulgare all'utente se l'account esiste?

Qualcuno mi ha detto che non dovrebbe essere possibile per qualcuno rilevare se un determinato indirizzo email viene utilizzato da un utente registrato su un sito Web. Quindi, ad esempio, quando l'utente chiede di reimpostare la password, dovresti dire "Password inviata" indipendentemente dal fatto che l'e-mail sia presente nel database. In caso contrario, le persone possono utilizzare questa funzione per verificare chi è un membro e anche per verificare la validità degli elenchi di spam, ecc.

Ma ho notato che Facebook dice "E-mail già registrata" se si tenta di registrare due volte la stessa e-mail. Questo significa che le convenzioni sono cambiate; che informare l'utente è più importante che rivelare gli account?

54
forthrin

È una tradizione piuttosto antica non dire alle persone se esistono accessi specifici o meno. Questo è il motivo per cui i sistemi Unix o Windows, quando richiedono le credenziali dell'utente, risponderanno a qualsiasi errore con un messaggio generico "nome utente o password errati". L'idea nasce da una visione degli attacchi piuttosto antiquata: immagina un cattivo che vuole entrare in un mainframe e riesce a mettere le mani su un terminale seriale collegato al sistema, o forse a un'interfaccia telnet su una linea modem. Questo utente malintenzionato sarà in una posizione di attacco dizionario online : proverà a indovinare una coppia login + password che concede l'accesso. I nomi di login amministrativi come "root" erano in genere meglio protetti rispetto ai normali account utente (l'utente "root" era più bravo a selezionare password complesse, o almeno così era ipotizzato) in modo che gli attaccanti avrebbero cercato di trovare normali account utente e, in nomi di account utente normale .

Guardare il film War Games (dal 1983) ti dà una buona idea di come stavano le cose.

Nota il punto critico: nello scenario di attacco sopra, l'attaccante vuole ottenere almeno un account, ma non potrebbe averne uno in condizioni normali, o anche sapere chi ha un account.

Ora è il 2013, tre decenni dopo quel film. Abbiamo server in cui tutti possono registrarsi gratuitamente e ottenere un account. Ottenere un account non è quindi più l'obiettivo di un attaccante. Invece, l'attaccante vorrà accedere a account specifici , con identità note. Questa non è la stessa situazione. Il contesto è cambiato Pertanto, la vecchia tradizione non è necessariamente applicabile.


Ad ogni modo, quando un utente prova a registrarsi su Facebook, si aspetta che il processo funzioni. A quel punto, il processo potrebbe non riuscire per un solo motivo plausibile, che è un indirizzo e-mail già utilizzato. Sarebbe difficile nascondere questo fatto all'utente ...

Se vogliamo "proteggere" gli indirizzi email degli utenti, il processo di registrazione deve procedere in questo modo:

  • L'utente inserisce la sua presunta e-mail.
  • Un'e-mail viene inviata a quell'indirizzo, contenente un collegamento di registrazione singolo; tuttavia, se l'e-mail è già registrata, viene inviata un'e-mail che spiega questo fatto. Nessun indizio è scritto sulla pagina Web di risposta se l'e-mail esisteva già nel sistema o meno.
  • L'utente si registra seguendo il link dall'email.

Un tale processo raddoppierebbe come un processo di verifica via e-mail, quindi è abbastanza buono. Tuttavia, ha un po 'di latenza (l'utente deve uscire dal sito Web, aprire il suo lettore e-mail e attendere l'e-mail in arrivo), quindi questo può essere problematico per i siti di shopping (gli utenti non sono pazienti e sono inclini a fare acquisti altrove se ritengono che il processo di pagamento sia troppo complicato). Inoltre, ci devono essere alcuni guardrail per evitare che questo sistema di registrazione venga abusato in una macchina spamming.


Penso che si possa dire che, per i manutentori di Facebook, rendere il processo di registrazione il più semplice e veloce possibile sia più importante della privacy dell'utente. Davvero, chi sarebbe quella sorpresa?

52
Thomas Pornin

Potrebbero essere presi in considerazione rischi di PII. È lecito ritenere che "tutti" dispongano di un account Facebook, pertanto rivelare che una determinata e-mail registrata non è un grosso problema.

Ma prendi un altro servizio, come "depression-help.com" o "it-burns-when-I-tinkle.net". Sarebbe un problema comunicare al pubblico che una determinata persona/e-mail è registrata sul sito.

Inoltre, per i piccoli servizi con una base di utenti intenzionalmente piccola, la divulgazione di nomi utente può fornire informazioni aggiuntive a un utente malintenzionato che potrebbe compromettere account come quello alcuni film del 198 .

Consiglio a @ThomasPornin, ma credo che ci siano alcuni casi, come quelli che ho suggerito, che rendono utile prendere una decisione informata sulla non divulgazione di nomi/e-mail di account utente.

39
schroeder

Non esiste davvero un modo grazioso per risolvere questo problema che può rendere tutti felici al 100%. Se imponi l'uso di indirizzi e-mail come nomi utente, rendi più semplice determinare se qualcuno che ha un determinato indirizzo e-mail è un utente (problema di privacy). Se permetti nomi utente arbitrari, non puoi davvero andare in giro alla fine rivelando se un determinato nome utente è già in uso e tutto ciò che puoi fare è prendere provvedimenti per rallentare un utente che sta cercando di scoprire nomi utente validi.

Le registrazioni di nuovi utenti sono il problema più difficile da affrontare, perché non è possibile aggirare il fatto che alla fine dovrai affrontare con garbo una collisione con il nome utente. Ecco un'opzione possibile: chiedi all'utente di inserire un indirizzo e-mail, un nome utente proposto e la password desiderata. Al momento dell'invio, convalida che la password è accettabile e invia all'utente un URL di convalida.

  • Se l'indirizzo e-mail è già in uso, ma associato a un nome utente diverso, invia un'email a quell'utente, ricordagli che ha già un account e chiedi se desidera reimpostare la password.

  • Se l'indirizzo e-mail non è già in uso, ma lo è lo username, invia all'utente un messaggio di errore che gli informa che deve scegliere un nome utente diverso e deve attendere un periodo di tempo crescente tra ogni tentativo.

  • Se l'indirizzo e-mail e il nome utente sono entrambi nuovi, inviare tramite e-mail all'utente un link di conferma che richiede una nuova autenticazione con il nuovo nome utente e password prima di renderlo ufficiale.

  • NON NON consente a due utenti di avere lo stesso nome utente presupponendo che sia possibile identificare l'uno o l'altro in base alle loro password. Tra l'altro, se due utenti possono condividere lo stesso nome utente, ciò significa che non è mai possibile bloccare il nome utente a causa di tentativi di accesso falliti senza influenzare ENTRAMBI gli utenti. E dio non voglia, se mai un giorno dovessero in qualche modo scegliere la stessa password, si scatenerà l'inferno.

  • Non utilizzare lo stesso valore per nome utente e identità pubblica. Non devi necessariamente attivamente impedire agli utenti di inserire lo stesso valore per entrambi, se lo desiderano, ma il valore predefinito dovrebbe essere consentire agli utenti ( su qualcosa come un forum di messaggi, ad esempio) per avere un nickname pubblico che non ha necessariamente a che fare con il nome utente con cui accedono.

  • Non assegnare in sequenza gli ID utente. Utilizzare almeno 31, preferibilmente 62, bit valori casuali che vengono generati e verificati come unici al momento della registrazione. La cosa bella dei valori a 31 e 62 bit è il fatto che si traducono ordinatamente in stringhe base36 a 6 e 12 caratteri. Durante il debug, è molto più facile ricordare una stringa di 6 o 12 caratteri di lettere minuscole e cifre rispetto a un valore decimale di 6-17 cifre. La parte più difficile è rispondere alle richieste che specificano un ID utente non valido con risposte false, ma che non possono essere prontamente distinte dalle risposte dell'ID utente reale con mezzi algoritmici.

Ricorda: non puoi e non riuscirai mai al 100% a impedire a un utente malintenzionato di verificare occasionalmente se un determinato ID utente o nome utente è valido. Il tuo obiettivo è renderlo il più lento e costoso possibile, senza gravare irragionevolmente sui tuoi utenti reali. Per un analogo del mondo reale, pensa ai codici regionali DVD e Blu-Ray. Quando un giocatore costava oltre $ 500, i codici regionali erano un modo efficace per impedire a quasi tutti di riprodurre film acquistati in un'altra regione. Ora che puoi acquistare un lettore Blu-Ray per $ 80 e un selettore HDMI per $ 20 e ottenere il resto, non c'è davvero nulla che impedisca a un appassionato di film di acquistare solo due o tre lettori Blu-Ray (uno per regione desiderata), impilando e eseguendoli tramite l'interruttore HDMI.

Per gli accessi di routine, sii intenzionalmente vago sul motivo per cui QUESTO tentativo di accesso fallisce, ma sii ugualmente in anticipo sui possibili motivi ... e fornisci loro informazioni di contatto concrete di qualcuno che possa aiutarli. Tenere traccia degli accessi non riusciti e bloccare l'account se vengono effettuati troppi tentativi di accesso non riusciti.

  • Non dire loro apertamente che l'account è appena stato bloccato o è attualmente bloccato ... ma non essere timido nel menzionarlo come uno dei diversi motivi per cui un tentativo di accesso potrebbe non essere riuscito. Mantenere il fatto che un account POTREBBE essere bloccato da un utente che tenta di accedere non farà nulla per aiutare la tua sicurezza.

  • Non è necessario bloccare un account in modo semi-permanente a causa di tentativi di accesso falliti. In molti casi, probabilmente non dovresti , perché POI avrai creato un utile attacco denial of service. Se un account ha troppi tentativi di accesso non riusciti, POTREBBE fare un blocco "soft" per 1, 6 o 24 ore, a quel punto il blocco si rimuoverà automaticamente. Questo è uno scenario IMHO in cui è legittimo dire a un utente di "riprovare più tardi".

Un messaggio di errore di esempio che potrebbe essere visualizzato quando un tentativo di accesso fallisce:

Il nome utente e/o la password inseriti non sono stati accettati. È possibile che sia stato inserito un nome utente non valido, utilizzato una password errata o tentato di accedere con un account che è stato bloccato a causa di eccessivi tentativi di accesso non riusciti. Se l'account è stato bloccato, puoi contattare _ __ per assistenza [ oppure attendere _ ore per sbloccare l'account da solo]. Si noti che questo messaggio di errore sarà lo stesso per tutti gli accessi non riusciti, indipendentemente dal motivo.

NON dire loro "Qualcosa è andato storto, per favore riprova più tardi" a meno che il problema non si risolva letteralmente da solo. Non ingannerà un attaccante e infastidirà seriamente gli utenti legittimi. Questo è uno dei miei ultimi animali da compagnia, e vicino alla cima della mia lista di "cose ​​orribili che gli sviluppatori fanno in nome del teatro della sicurezza". Oltre ad essere incredibilmente fastidioso, se l'account di qualcuno è stato compromesso, l'ultima cosa che vuoi che facciano è aspettare fino a dopo prima di portarlo all'attenzione di qualcuno.

7
Bitbang3r

È un comportamento standard di Facebook che puoi cercare un account se hai l'indirizzo email corrispondente. In questi giorni molte persone hanno disattivato questa opzione, ma è ancora il luogo in cui sta arrivando Facebook.

Durante la moderazione del forum, ho spesso utilizzato questa funzione per raccogliere informazioni sul fatto che un account appena registrato sia un account registrato di un utente vietato.

I siti Web che indicano se gli indirizzi e-mail o i nomi utente sono reali è un modo per attaccare l'anonimato. Ricordo un caso in cui qualcuno ha registrato nuovamente chi utilizzava l'IP di un nodo di uscita TOR. Sono stato in grado di dire alla persona il nome di sua madre attraverso le informazioni che ha condiviso su Facebook. La strada per l'informazione passava attraverso quattro cerchi di soprannomi che erano associati tra loro.

La divulgazione di informazioni come questa semplifica il funzionamento di aziende come http://www.spokeo.com/ .

Quando si tratta di proteggere la privacy, è necessario considerare anche tutti i dati sensibili. Partecipa a un forum con 1000 utenti. Gli utenti pubblicano informazioni innocue con un soprannome. Un utente ha effettuato l'accesso al forum con un indirizzo email associato alla sua vera identità.

Con 1000 utenti c'è una buona possibilità che io possa identificare con la stetometria e le informazioni divulgate quale dei 1000 utenti è la persona che sto cercando. Se riesco in questo compito, ho un soprannome segreto.

Ora posso eseguire ricerche su Google su quel nickname e anche cercare [email protected] in altri database. Ho anche ottenuto un campione di testo più grande per rendere più semplice l'esecuzione di futuri attacchi di stylometria.

Un aggressore di livello governativo che vuole trovare dissidenti ha le risorse per interrogare molti servizi web per verificare se esistono determinati indirizzi e-mail e può anche investire in buoni sistemi di stylometria.

Se si desidera proteggere la privacy, ha senso nascondere gli indirizzi e-mail registrati.

4
Christian