Come fornire sicurezza per le password memorizzate nel database? [duplicare]

Puoi iniziare usando un meccanismo di hashing più strong come SHA-2 invece di MD5. Inoltre è possibile rendere più sicuro il database delle password hash con l'hashing delle password salate. Ho fatto una presentazione nella mia classe una volta sull'hash delle password e ho trovato questo link e questo anche per essere molto informativo (a parte la Wikipedia). Spero che questo aiuti anche te.

1. Usa un hash migliore. Abbiamo molte domande relative a questo, ma si riduce a bcrypt, PBKDF2 o scrypt con iterazioni sufficienti (almeno 10'000 per PBKDF2, valori equivalenti per gli altri) e un salt casuale. L'unica iterazione SHA-2 non è accettabile, anche con un salt.

2. Cripta l'hash con una chiave memorizzata in qualche forma di file di configurazione. La scelta esatta dipende dalla tua piattaforma, potrebbe essere il web.config crittografato di .net, o qualche tipo di keystore, o anche solo una normale configurazione di file di testo.

   Questo aiuta gli aggressori che possono visualizzare il database, ma non quel file di configurazione. Ma ovviamente non aiuta contro un compromesso completo.

Hai la possibilità di aggiungere un salt alle tue password?

link

Credo che ciò renderebbe tali database meno efficaci per la decrittografia degli hash.

La prima "crittografia" e "hashing" sono cose diverse. L'operazione a senso unico che descrivi è hashing.

L'attacco che descrivi sembra un attacco da tavolo arcobaleno. In genere devi aggiungere un salino al tuo hash della password per impedirlo, ma se utilizzi una funzione di hashing debole (come MD5), lo schema sarà comunque vulnerabile.

Devi stare attento a quale funzione usi per farlo. È facile scegliere la funzione sbagliata e non guadagnare molta sicurezza. Dai un'occhiata a questa domanda . L'idea generale è di usare una funzione di hash adattiva, come bcrypt, per prendersi cura di tutti questi dettagli di sicurezza per te.

A seconda della piattaforma di database (e delle licenze potenzialmente extra) esistono meccanismi che impediscono ad altri utenti (anche agli amministratori di database) di vedere determinate colonne. In Oracle, ad esempio, si chiama Virtual Private Database

link

Si consiglia l'utilizzo di sali, una funzione di derivazione chiave e una politica di password applicata dal sistema.

• I sali di lunghezza sufficiente prevengono efficacemente l'uso di tabelle arcobaleno e attacchi dizionario
• L'uso di una funzione di derivazione della chiave come scrypt, bcrypt o PBKDF2 (visualizza anche ) rallenterà un eventuale attacco di forza bruta anche se il sale potrebbe essere noto. Questo funziona perché quelle funzioni di derivazione chiave sono progettate con l'obiettivo di funzionare intenzionalmente lentamente su CPU, memoria o entrambi (scrypt). Si noti che il tempo di calcolo per ciascuna password può essere personalizzato mediante l'uso di parametri. Questo approccio è altamente preferito rispetto all'utilizzo di una funzione di hash standard come MD5. A proposito, MD5 è incline a attacchi di collisione trovati da Boer, Bosselaers e Dobbertin e il suo uso non è consigliato.
• Poiché le password sono uno degli input di una funzione di derivazione di questo tipo, le password deboli possono compromettere la sicurezza del sistema. Per verificare ciò, lasciare che il sistema controlli le nuove password prima di memorizzarle nel database. Le password complesse dovrebbero avere una lunghezza minima, dovrebbero contenere caratteri e numeri maiuscoli e minuscoli (speciali). Anche se la tua politica di sicurezza del database non può escludere i tuoi amministratori dalla lettura delle chiavi derivate e dai loro corrispondenti valori salt, non sarebbero in grado di fare alcun uso di questo

@CodeInChaos: 1. Hai dimenticato le tabelle arcobaleno basate sul dizionario. 2. L'OP dice che usa MD5 per l'hashing delle password e io gli ho semplicemente consigliato di non farlo. OP non vuole che gli amministratori che hanno accesso al database con i valori hash possano ricavarne una conoscenza da password. Quello che intendevo con incline agli attacchi di collisione è più precisamente noto come resistenza pre-immagine e quindi raccomandare un'alternativa più sicura in generale è assolutamente valido. Forse il mio collegamento è fuori tema, però. 3. Credo che il PO sia alla ricerca di buone risposte in generale. Ha anche detto che quegli amministratori hanno bisogno di creare backup dal database completo. Quale non è possibile senza permessi di lettura. Tuttavia, quando i sali e gli input della password (3.) sono abbastanza lunghi, anche la conoscenza di entrambi non rivela alcuna password. Ecco perché ho consigliato di utilizzare una buona politica per le password.

@ makerofthings7, Tom Post: Grazie per il tuo aiuto! Sì, ho postato per sbaglio da un account temporaneo.