hashing della password, sale e memorizzazione dei valori hash

Question

Supponiamo che tu fossi libero di decidere come memorizzare le password hash in un DBMS. Ci sono evidenti debolezze in uno schema come questo?

Per creare il valore hash memorizzato in DBMS, prendono:

• Un valore che è unico per l'istanza del DBMS server come parte del sale,
• e il nome utente come seconda parte della sale,
• E creare la concatenazione del sale con la password attuale,
• E hash l'intera stringa utilizzando l'algoritmo SHA-256,
• e memorizzare il risultato nel DBMS.

Ciò significa che chiunque desideri ottenere una collisione dovrebbe dover eseguire il lavoro separatamente per ciascun nome utente e ogni istanza del server DBMS separatamente. Avrei intenzione di mantenere un po 'flessibile l'attuale meccanismo di hash per consentire l'utilizzo del nuovo algoritmo di hash standard NIST (SHA-3) su cui si sta ancora lavorando.

Il "valore che è univoco per l'istanza del server DBMS" non deve essere segreto, sebbene non venga divulgato in modo casuale. L'intenzione è di garantire che se qualcuno usa la stessa password in diverse istanze del server DBMS, gli hash registrati sarebbero diversi. Allo stesso modo, il nome utente non sarebbe segreto: solo la password corretta.

Potrebbe esserci qualche vantaggio prima di avere la password e il nome utente e il "valore unico" secondo, o qualsiasi altra permutazione delle tre fonti di dati? O che dire dell'incrocio tra le corde?

Devo aggiungere (e registrare) un valore salt random (per password) e le informazioni sopra? (Vantaggio: l'utente può riutilizzare una password e ancora, probabilmente, ottenere un hash diverso registrato nel database Svantaggio: il sale deve essere registrato.Subito che il vantaggio superi notevolmente lo svantaggio.)

Ci sono un bel po 'di domande relative SO - questa lista è improbabile che sia completo:

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

penso che le risposte a queste domande supportano il mio algoritmo (anche se è sufficiente utilizzare un sale casuale, quindi il 'valore unico per server' e componenti nome utente sono meno importanti).

Answer 1

Il sale deve essere solo casuale e unico. Può essere conosciuto liberamente in quanto non aiuta un aggressore. Molti sistemi memorizzeranno il testo semplice salt nel database nella colonna accanto alla password hash.

Il sale aiuta a garantire che se due persone (Utente A e Utente B) condividono la stessa password non è ovvio. Senza il sale casuale e univoco per ogni password, i valori hash sarebbero gli stessi e ovviamente se la password per l'utente A è incrinata, allora l'utente B deve avere la stessa password.

Aiuta anche a proteggere dagli attacchi in cui un dizionario di hash può essere confrontato con password conosciute. per esempio. tavoli arcobaleno.

Anche l'utilizzo di un algoritmo con un "fattore di lavoro" incorporato significa anche che con l'aumentare della potenza di calcolo è possibile aumentare anche il lavoro che un algoritmo deve eseguire per creare l'hash. Ad esempio, bcrypt. Ciò significa che l'economia degli attacchi di forza bruta diventa insostenibile. Presumibilmente diventa molto più difficile creare tabelle con noti hash perché impiegano più tempo per creare; le variazioni nel "fattore di lavoro" significheranno più tabelle da costruire.

Answer 2

Perché non aggiungere un salt casuale alla password e cancellare quella combinazione. Quindi concatenare l'hash e il sale a un singolo byte [] e memorizzarlo nel db?

Il vantaggio di un salt casuale è che l'utente è libero di cambiare il suo nome utente.Il Salt non deve essere segreto, dal momento che è usato per prevenire attacchi di dizionario.

Answer 3

Penso che tu stia complicando troppo il problema.

Inizia con il problema:

1. Stai cercando di proteggere le password deboli?
2. Stai cercando di mitigare gli attacchi arcobaleno?

Il meccanismo proposto protegge da un semplice attacco arcobaleno, poiché anche se l'utente A e l'utente B hanno la password SAME, la password con hash sarà diversa. Lo fa, sembra un metodo piuttosto elaborato per salare una password che è eccessivamente complicata.

• Cosa succede quando si esegue la migrazione del DB su un altro server?
  • È possibile modificare l'univoco, in base al valore DB, se è possibile generare una tabella arcobaleno globale, in caso contrario non è possibile ripristinare il DB.

Invece vorrei solo aggiungere la colonna supplementare e memorizzare un sale casuale corretta. Questo proteggerebbe da ogni tipo di attacco arcobaleno. Attraverso più distribuzioni.

Tuttavia, non ti proteggerà da un attacco di forza bruta. Quindi, se stai cercando di proteggere gli utenti che hanno password scadenti, dovrai cercare altrove. Ad esempio, se i tuoi utenti hanno password di 4 lettere, potrebbe probabilmente essere decifrato in pochi secondi anche con un salt e l'algoritmo hash più recente.

Answer 4

Penso che sia necessario chiedersi "Cosa speri di ottenere rendendo questo più complicato del semplice generare un valore salt casuale e memorizzarlo?" Più il tuo algoritmo è complicato, più è probabile che tu introduca una debolezza inavvertitamente. Probabilmente questo sembrerà snarky, non importa come lo dico, ma è inteso come aiuto - cosa c'è di così speciale nella tua app che ha bisogno di un nuovo algoritmo di hashing della password?