C'è un valore nella memorizzazione delle password nella propria tabella con chiavi crittografate o con hash?

Question

C'è un valore nella memorizzazione delle password nella propria tabella con chiavi crittografate o con hash?

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (0 voti)

2

Il metodo usuale per siti semplici è quello di memorizzare un hash della password di un utente nel proprio record utente.

Cosa succede se il campo della password viene rimosso dalla tabella utente e viene creata una tabella delle password? La tabella delle password avrebbe lo stesso hash della password, ma al posto dell'id utente, la chiave della tabella è un altro hash, un hash dell'ID utente e una chiave segreta.

L'idea è che se ottieni una copia della tabella utente, non ottieni gli hash delle password. Se si ottiene l'utente e la tabella delle password, non è possibile connettere una password a un particolare account utente.

Suppongo che se potessi rompere l'hash della password, avresti una manciata di password che sai essere in uso sul sistema. Potresti provare ogni password su ciascun account finché non funziona. Quindi forse ho risposto alla mia stessa domanda. Tuttavia c'è qualcosa che mi manca? Mi sembra una buona idea, ma non ho trovato nulla al riguardo.

Suppongo che potrebbe essere facile rilevare un attacco che utilizza un elenco di password esistenti per gli utenti nel sistema e bloccare o altrimenti arrestare l'attacco.

sql-injection passwords hash

posta Thomas Pornin 14.12.2012 - 16:15

fonte

5 risposte

Leggi altre domande sui tag sql-injection passwords hash

Encrypt + Dati di firma: PKCS # 7 / CMS o fai-da-te? SSL forgiato senza installazione di root CA, possibile?

score 2 · Answer 1

Se si utilizza una funzione di hashing della password crittografica appropriata (ad esempio, bcrypt, scrypt o PBKDF2), il valore aggiunto da questo approccio è trascurabile. Quindi, in realtà, la soluzione consiste semplicemente nel respingere responsabilmente le tue password in primo luogo.

score 2 · Answer 2

Dai un'occhiata a la mia risposta qui che parla di segregazione delle informazioni sulla password. Combinato con un set di autorizzazioni diverso che non consente la lettura ma consente il confronto tramite una stored procedure, la separazione delle informazioni sulla password sarebbe davvero utile.

Non è possibile andare efficacemente sulla crittografia o sui valori delle chiavi di hashing perché l'output sarebbe casuale. Avresti bisogno di uno spazio abbastanza grande per evitare collisioni e poi ti imbatterai in quantità dolorose di frammentazione del database in cui gli inserimenti si verificano ovunque e le pagine vengono suddivise. I valori chiave dovrebbero rimanere numeri interi incrementali per la sanità mentale di tutti.

I suppose that it might be easy to detect an attack that is using a list of passwords that do exist for users in the system and block or otherwise shutdown the attack.

No. Ciò comporterebbe il confronto con l'elenco completo di possibili hash che sarebbe costoso se si fossero utilizzati metodi di salatura e hashing appropriati.

score 1 · Answer 3

Se stai salendo e tagliando le tue password correttamente, il sistema che hai proposto non ha alcun valore aggiunto o nullo. Se un utente malintenzionato può ottenere un database, probabilmente può ottenere entrambi. Un hash aggiunto sulla chiave esterna non fornisce alcun aumento significativo della sicurezza oltre l'hashing delle tue password.

Inoltre, a seconda di come si implementa un tale sistema, si potrebbero causare notevoli perdite di prestazioni.

score 0 · Answer 4

Questa è sicurezza per oscurità, IMO. Il passaggio extra di hashing dell'ID utente per produrre una password è banale da ricreare una volta noto. Poiché i nomi utente non sono archiviati in formato hash nella tabella utente e poiché qualcosa, da qualche parte, deve avere accesso in lettura a entrambi i DB, se un utente malintenzionato può ottenere un dump della tabella utente e ottenere nomi utente, può ottenere un dump della tabella delle password e collegare i punti. L'unico sconosciuto è l'algoritmo di hash utilizzato, e poiché ci sono un piccolo numero di funzioni di hash sicure adatte allo scopo, è banale provarle tutte (e non pensare per un minuto che sto sostenendo la creazione del proprio hash o usare un oscuro, questo è solo più sicurezza per oscurità).

Se il metodo di hashing è sicuro e la password ha entropia non banale ( la top 10 delle password più comuni e semplici derivazioni di lo stesso ha effettivamente zero entropia dato che sono la prima cosa che qualsiasi cracker proverà), potresti spruzzare il tuo hash della password sulla tua auto e guidarla nel DEF CON e staresti perfettamente bene. Questo è il punto; l'attacco più efficiente dell'hash ideale dovrebbe essere l'attacco di compleanno, che dovrebbe comunque essere impossibile con la giusta combinazione di entropia di input, dimensioni del digest e costo computazionale.

score 0 · Answer 5

Abbiamo le password hash per un motivo specifico: nel caso in cui un utente malintenzionato possa prendere una copia delle tabelle del server. Abbiamo cancellato le password per impedire che l'attaccante esegua l'escalation di un accesso parziale e di sola lettura in un accesso in lettura / scrittura (vedere questo post del blog per una discussione più dettagliata). L'hashing della password è già un secondo livello di difesa.

La tua proposta riguarda l'aggiunta di un terzo livello: ha valore solo se lo scenario di attacco è che l'autore dell'attacco possa ottenere un accesso di sola lettura su una ma non su entrambi. Questo scenario non è tuttavia molto realistico, in quanto tale accesso di sola lettura spesso proviene da attacchi di SQL injection e gli elementi del server che hanno il permesso di leggere la tabella degli utenti spesso hanno anche il permesso di leggere la password hash (in particolare sistema di login, che deve, per definizione, usare entrambi).

Quindi devi bilanciare la sicurezza extra contro la complessità extra, perché la complessità è nota per essere il nemico della sicurezza. In tal caso, non ritengo che la complessità extra valga la pena, dal momento che lo scenario per il quale la suddivisione della tabella aggiungerebbe un po 'di sicurezza non è plausibile.