Come al meglio memorizzare le informazioni utente e utente e password

Question

sto utilizzando Mysql e stavo assumendo che era meglio separare un'utenti informazioni personali e la loro login e password in due tabelle diverse e poi semplicemente riferimento tra i due .

Nota: Per chiarire il mio post, comprendo le tecniche di protezione della password (hash, sale, ecc.). So solo che se seguo pratiche provenienti da altre parti della mia vita (investimenti, backup dei dati, persino archiviazione personale) che nella peggiore delle ipotesi (compresa tabella o incendio) che avere informazioni divise tra tabelle offre il potenziale per proteggere il tuo dati aggiuntivi.

Answer 1

Non memorizzare password. Se è mai seduto su un disco, può essere rubato. Invece, memorizza gli hash delle password. Use the right hashing algorithm, come bcrypt (che include un sale).

EDIT: Il PO ha risposto che capisce il problema di cui sopra.

Non c'è alcuna necessità di memorizzare la password in una tabella fisicamente diverso da quello di login. Se una tabella di database viene compromessa, non è un grande salto accedere ad un'altra tabella in quello stesso database.

Se siete sufficientemente preoccupati per la sicurezza e la sicurezza in profondità, si potrebbe considerare la memorizzazione delle credenziali utente in un archivio dati completamente separato dai vostri dati di dominio. Un approccio, comunemente fatto, è quello di memorizzare le credenziali in un server di directory LDAP. Questo potrebbe anche essere d'aiuto con qualsiasi lavoro single-sign-on che svolgerai in seguito.

Answer 2

Non c'è niente di sbagliato nel metterli nello stesso tavolo. In effetti, sarebbe molto più veloce, quindi lo consiglio vivamente. Non so perché tu voglia dividerlo.

Answer 3

Dovresti memorizzarli nella stessa tabella, e utilizzare la crittografia a senso unico. MD5 funzionerà, ma è debole, quindi potresti prendere in considerazione qualcosa come SHA1 o un altro metodo. Non c'è alcun vantaggio nel memorizzare i 2 oggetti in tabelle separate.

Answer 4

Cercherò di rispondere alla tua domanda originale. Avere tutto in una tabella va bene a meno che non si abbiano solo un sacco di informazioni personali da raccogliere. In tal caso potrebbe essere sensato dividerlo. Tale decisione dovrebbe essere presa in base alla quantità di informazioni personali con cui si ha a che fare e alla frequenza con cui è necessario accedervi.

direi che la maggior parte del tempo mi piacerebbe fare qualcosa di simile in una singola tabella:

UserID, FirstName, LastName, Email, Password, TempPassword 

Ma ... se si sta raccogliendo molto di più. Supponiamo che tu stia raccogliendo telefono, fax, data di nascita, biografia, ecc. Ecc. E se la maggior parte di queste informazioni è raramente accessibile, probabilmente la inserirò nella sua tabella e la collegherò con una relazione uno a uno. Dopo tutto, meno colonne hai su un tavolo, più veloce sarà la tua query su quel tavolo. E a volte ha senso semplificare le tabelle a cui si accede maggiormente. C'è un riscontro di prestazioni con il JOIN anche se è necessario accedere a tali informazioni personali, quindi è qualcosa che devi considerare.

EDIT - Sai cosa, ho solo pensato a qualcosa. Se si crea un indice sul nome utente o sul campo di posta elettronica (a seconda di quale si preferisce), eliminerà quasi completamente l'inconveniente di prestazioni nella creazione di così tante colonne in una tabella utente. Dico questo perché ogni volta che accedi alla clausola WHERE sarà estremamente veloce trovare il nome utente se ha un indice e non importa se hai 100 colonne in quella tabella. Quindi ho cambiato la mia opinione. Metterei tutto in un solo tavolo.;)

In entrambi i casi, poiché la sicurezza sembra essere un argomento popolare, la password dovrebbe essere un valore hash. Suggerirei SHA1 (o SHA256 se ne sei veramente preoccupato). TempPassword dovrebbe anche usare un hash ed è solo lì per la funzionalità della password dimenticata. Ovviamente con un hash non è possibile decodificare e inviare all'utente la loro password originale. Quindi, invece, si genera una password temporanea con cui è possibile accedere e quindi si costringe a cambiare nuovamente la password dopo l'accesso.

Answer 5

Innanzitutto, per dichiarare (si spera) ovvio, se è possibile in alcun modo evitare di memorizzare nomi utente e password; è una grande responsabilità e se il tuo negozio di credenziali viene violato potrebbe fornire l'accesso a molti altri luoghi per gli stessi utenti (a causa della condivisione delle password).

Se è necessario archiviare le credenziali:

• Non conservare una forma reversibile; memorizzare un hash utilizzando un algoritmo riconosciuto come SHA-256. Usa il software di crittografia da una fonte attendibile e affidabile - NON TENTARE DI ROLLARE I TUOI PROPRIETÀ, POTRESTI OTTENERLO SBAGLIATO.
• Per ogni set di credenziali, memorizzare un salt insieme ai dati hash; questo è usato per "innescare" l'hash in modo tale che due password identiche non producano lo stesso hash - dal momento che dà via che le password sono le stesse.
• Utilizzare un generatore casuale sicuro. La casualità debole è la causa numero uno degli errori di sicurezza relativi alla crittografia, non degli algoritmi di cifratura.

Se è necessario archiviare reversibili credenziali:

• scegliere un buon algoritmo di crittografia - AES-256, 3DES (datato), o di un cifrario a chiave pubblica. Usa il software di crittografia da una fonte attendibile e affidabile - NON TENTARE DI ROLLARE I TUOI PROPRIETÀ, POTRESTI OTTENERLO SBAGLIATO.
• Per ogni set di credenziali, memorizzare un valore salt (non crittografato) insieme ai dati crittografati; questo è usato per "innescare" il codice di crittografia in modo tale che due password identiche non producano lo stesso testo cifrato - dal momento che dà via che le password sono le stesse.
• Utilizzare un generatore casuale sicuro. La casualità debole è la causa numero uno degli errori di sicurezza relativi alla crittografia, non degli algoritmi di cifratura.
• Memorizzare le chiavi di crittografia/decrittografia separatamente dal proprio database, in un file protetto O/S, accessibile solo per il profilo runtime delle applicazioni. In questo modo, se il tuo DB viene violato (ad es. Tramite SQL injection) la tua chiave non è automaticamente vulnerabile, poiché ciò richiederebbe l'accesso all'HDD in generale. Se il tuo O/S supporta la crittografia dei file legata a un profilo, usalo - può solo aiutare ed è generalmente trasparente (ad esempio la crittografia NTFS).
• Se possibile, memorizzare le chiavi stesse crittografate con una password primaria. Questo di solito significa la tua app. avrà bisogno di quella chiave digitata all'avvio - non è utile fornirla in un parametro da uno script poiché se l'HDD viene violato è necessario presumere che sia il file chiave sia lo script possano essere visualizzati.
• Se il nome utente non è necessario per individuare il record dell'account, crittografare sia il nome utente che la password.

Answer 6

Le password devono essere memorizzate come hash crittografico, un'operazione non reversibile che impedisce la lettura del testo normale. Quando si autenticano gli utenti, l'immissione della password viene sottoposta allo stesso processo di hashing e gli hash vengono confrontati.

Evitare l'uso di un hash veloce ed economico come MD5 o SHA1; l'obiettivo è rendere costoso per un utente malintenzionato calcolare le tabelle arcobaleno (in base alle collisioni hash); un hash veloce contrasta questo. L'uso di un costoso hash non è un problema per gli scenari di autenticazione, poiché non avrà alcun effetto su una singola esecuzione dell'hash.

Oltre all'hashing, salare l'hash con un valore generato casualmente; un nonce, che viene quindi memorizzato nel database e concatenato con i dati prima dell'hash. Ciò aumenta il numero di combinazioni possibili che devono essere generate durante il calcolo delle collisioni, e quindi aumenta la complessità complessiva nel tempo della generazione di tabelle arcobaleno.

La colonna dell'hash della password può essere una lunghezza fissa; il tuo hash crittografico dovrebbe produrre valori che possono essere codificati in una lunghezza fissa, che sarà la stessa per tutti gli hash.

Ove possibile, evitare di attivare il proprio meccanismo di autenticazione della password; utilizzare una soluzione esistente, ad esempio bcrypt.

Un'eccellente spiegazione di come gestire le password e di cosa è necessario preoccuparsi è disponibile al numero http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes.

Come nota finale, si ricorda che se un utente malintenzionato ottiene l'accesso al proprio database, la sua preoccupazione immediata dovrebbe probabilmente riguardare qualsiasi informazione sensibile o di identificazione personale a cui possa avere accesso e qualsiasi danno possa aver fatto.

Answer 7

Nella mia esperienza personale, archiviare le informazioni personali e le informazioni di accesso nei singoli database è la migliore pratica in questo caso. La ragione per cui dovrebbe verificarsi un'iniezione SQL è limitata (a meno che l'infiltrato non conosca il layout interno del/i database/i) alla tabella a cui appartengono i dati, invece di fornire l'accesso all'intero conglomerato di dati.

Tuttavia, si noti che ciò potrebbe comportare la necessità di eseguire più query, quindi un impatto sulle prestazioni.

Answer 8

Tutti questi dati hanno sempre una relazione 1: 1 con l'utente? Se riesci a consentire agli utenti di disporre di più indirizzi, numeri di telefono e così via, potresti voler suddividere le informazioni personali in una tabella separata.