È una buona idea conservare gli indirizzi di posta elettronica solo come hash?

6

Attualmente sto creando un servizio web al link simile a link che dovrebbe aiutare gli utenti ad ottenere il codice LaTeX dalle formule disegnate. Fa parte della mia tesi di laurea triennale e l'obiettivo principale di questo progetto è rendere più facile la ricerca nel campo del riconoscimento della grafia on-line. Ciò significa che voglio condividere tutti i dati che ottengo dagli utenti.

Il modo più semplice per farlo sarebbe semplicemente scaricare il database. In questo modo ho potuto fare la mia copia di backup e una discarica per i ricercatori in un solo passaggio.

Ci sono solo due pezzi in cui esisto a condividerlo con il pubblico non appena altri utenti usano il mio sistema: indirizzi e-mail e password.

password

La password è memorizzata in hash e salata (ciò significa che memorizzo md5($userpass.$salt) e $salt che è una stringa casuale di 8 caratteri con caratteri da A-Za-z0-9 - il sale è generato per ogni utente). È sufficiente per rendere pubblico questo?

La parte principale della domanda riguarda l'indirizzo e-mail: al momento, lo memorizzo come testo normale. Ma sto pensando di memorizzare solo un hash dell'indirizzo e-mail. Questo hash non può essere salato, perché la mia funzione di login funziona come segue:

L'utente inserisce $email e $password . Entrambi vengono inviati come testo normale al server. Quindi il server fa (come pseudocodice):

$pwdb, $salt = query(SELECT password, salt FROM users WHERE email = :email)
if (md5($password.$salt) == $pwdb) {
   Logged in
} else {
   Wrong password
}

Indirizzi email

Non importa se :email è $email o md5($email) o md5($email.$applicationwide_random_str) . Ma non posso fare un nuovo sal per ogni utente senza dover passare per ogni utente (il che probabilmente non sarebbe male se penso che non avrò mai più di 10.000 utenti).

Domande

  • Quanto tempo ci vorrà per "disapprovare" una sola email (ad esempio [email protected] o [email protected] ) che ha un sale casuale di 8 caratteri (ad esempio FHCJ81ru ) con hardware "standard" (< $ 1000) quando non conosci la stringa casuale? È questione di secondi, minuti, ore o giorni?
  • È brutto se le persone possono farlo? Voglio dire che potrebbero anche semplicemente inviare e-mail e vedere cosa restituiscono. Nel mio servizio, non sono coinvolti molti dati personali:
    • simboli e formule scritte a mano
    • infine la mano
    • alla fine quando / dove la persona ha imparato a scrivere
    • alla fine la lingua dell'utente
  • Perché nessun servizio ha cancellato l'indirizzo Email (ok, non so se non ci sono servizi che lo fanno, ma non l'ho mai letto - le password di hashing sono comuni, ma hashing gli indirizzi Email? Mai sentito.)
  • È una buona idea cancellare le e-mail se si desidera utilizzare l'e-mail solo se l'utente ha perso la sua password e accedere? (Ho pensato di usare OpenID, ma la maggior parte delle persone non sa cosa sia)
posta Martin Thoma 08.05.2014 - 19:43
fonte

2 risposte

17

Alla fine, ci sono due domande: cosa dovresti memorizzare e cosa dovresti condividere.

Che cosa dovresti memorizzare

La memorizzazione dell'indirizzo email ha il vantaggio di poter contattare gli utenti. Molti siti vogliono essere in grado di contattare gli utenti che non hanno attualmente effettuato il login. Ad esempio, i siti commerciali vogliono essere in grado di notificare agli utenti che il loro ordine è stato spedito o che il loro pagamento è stato rimbalzato. Molti siti hanno notifiche email configurabili. I siti potrebbero voler informare gli utenti di una violazione della privacy o della sicurezza: la gente preferisce essere informata privatamente piuttosto che apprenderla nei notiziari. E questo non conta tutti gli scopi nefandi (sendind --- spam --- "offerte promozionali").

Se decidi che non hai mai bisogno di contattare gli utenti, salva ( lento e salted ! Non has MD5 o SHA-2, ma PBKDF2 o bcrypt o scrypt.) hash delle email. Ma sii consapevole dei limiti.

Suppongo che userete gli indirizzi email come identificatori univoci dell'utente. Questo ha un aspetto negativo: a volte le persone cambiano le email. Ad esempio, nel mondo accademico (a cui molti utenti potrebbero appartenere), le persone usano spesso le loro e-mail dalla loro attuale istituzione, e quindi l'anno successivo questa e-mail diventa inutilizzabile. Questo può escluderli da account troppo legati a un indirizzo email. Assicurati di consentire un modo di transizione (che può essere complicato se hai bisogno di accedere al vecchio indirizzo email per aggiungerne uno nuovo).

Cosa dovresti condividere

Forare brutalmente un hash salante richiede enumerazione di tutte le possibilità. Il tempo necessario per provare una possibilità è un parametro di configurazione di un hash lento: dovresti renderlo lento quanto il tuo server supporta, ma non più lento. Quindi la risposta a "Quanto tempo ci vorrà per" sfogare "una sola email è letteralmente" qualunque cosa tu scelga ".

Quanto tempo ci vuole per forzare il tuo database di e-mail non è comunque la domanda decisiva. Verificare che un'e-mail sia nel tuo database è ovviamente pratica - il tuo server lo farà sempre - e questo permette a qualcuno che conosce gli hash di rispondere alla domanda "Bob ha un account?". Questa è già una violazione della privacy.

Lo stesso vale per la password: anche consentire a terze parti di verificare le loro ipotesi sulla password di Bob è sbagliata. Non male come rivelare la password di Bob, ma ancora male.

Quindi la risposta è semplice: non comunicare indirizzi email o password, né hash di essi, a terze parti. Se perdi accidentalmente anche gli hash, questa è una violazione della privacy. Quando condividi i dati, utilizza identificatori privi di significato per gli account utente, ad esempio ID sequenziali o UUID casuali.

Fai attenzione anche al creep dell'oscilloscopio nel tuo database. Se memorizzi troppe informazioni su un utente, ciò può consentire l'identificazione e l'effettuazione di connessioni. Questo è un problema comune con i database medici - se vi capita di sapere che Alice era al Riverside Hospital dal 1997-02-25 al 1997-03-03 e dal 2001-07-21 al 2001-07-28, e c'è un record del singolo paziente che è stato ammesso all'ospedale Riverside nel febbraio 1997, lasciato a marzo e ricoverato di nuovo nel luglio 2001 - Alice è stata identificata anche se il suo nome non è mai stato esposto. Questo non è probabilmente un problema con le informazioni che hai intenzione di memorizzare ora, ma tienilo a mente.

    
risposta data 08.05.2014 - 20:23
fonte
1

Non esportare mai dati utente, nemmeno in formato hash, è probabile che qualcuno comprenderà un modo per rompere la crittografia / hashing.

Quindi esportare solo le tabelle di dati rilevanti, non la tabella utente. Nei tuoi dati troverai riferimenti di chiavi estranee, in modo che tu sappia quali elementi appartengono allo stesso utente, ma sarà un account di numero anonimo a chiunque utilizzi i dati scaricati.

    
risposta data 09.05.2014 - 02:29
fonte

Leggi altre domande sui tag