Salare la tua password: le migliori pratiche?

Sono sempre stato curioso ... Qual è la cosa migliore quando si salta una password per l'hashing: prefisso o postfisso? Perché? O importa, finché sali?

Per spiegare: ormai tutti (si spera) sappiamo che dovremmo salare una password prima di cancellarla per l'archiviazione nel database [ Modifica: in modo da poter evitare cose come quello che è successo a Jeff Atwood di recente ]. In genere questo viene fatto concatenando il salt con la password prima di passarlo attraverso l'algoritmo di hashing. Ma gli esempi variano ... Alcuni esempi antepongono il sale prima della password. Alcuni esempi aggiungono il sale dopo la password. Ne ho anche visti alcuni che cercano di mettere il sale nel mezzo.

Quindi qual è il metodo migliore e perché? Esiste un metodo che riduce la possibilità di una collisione dell'hash? My Googling non ha prodotto un'analisi decente sull'argomento.

Modifica: grandi risposte gente! Mi dispiace di poter scegliere solo una risposta. :)

Il prefisso o il suffisso è irrilevante, riguarda solo l'aggiunta di entropia e lunghezza alla password.

Dovresti considerare queste tre cose:

1. Il sale deve essere diverso per ogni password memorizzata. (Questo è un malinteso abbastanza comune.)
2. Utilizzare un generatore di numeri casuali crittograficamente sicuro.
3. Scegli un sale abbastanza lungo. Pensa al problema del compleanno.

C'è una risposta eccellente di Dave Sherohman a un'altra domanda sul perché dovresti usare sali generati casualmente invece del nome di un utente (o altri dati personali). Se segui questi suggerimenti, non importa dove metti il ​​sale.

Penso che sia tutta una semantica. Metterlo prima o dopo non ha importanza se non contro un modello di minaccia molto specifico.

Il fatto che sia lì dovrebbe sconfiggere i tavoli arcobaleno.

Il modello di minaccia a cui ho accennato sarebbe lo scenario in cui l'avversario può avere tabelle arcobaleno di sali comuni aggiunti / anteposti alla password. (Di 'la NSA) Stai indovinando che lo abbiano aggiunto o aggiunto, ma non entrambi. È sciocco, ed è una supposizione povera.

Sarebbe meglio presumere che abbiano la capacità di memorizzare questi tavoli arcobaleno, ma non, diciamo, tavoli con strani sali intervallati nel mezzo della password. In quel caso ristretto, suppongo che la cosa intervallata sarebbe la cosa migliore.

Come ho detto. È semantica. Scegli un salt diverso per password, un long salt e includi caratteri dispari come simboli e codici ASCII: © ¤¡

La vera risposta, che nessuno sembra aver toccato, è che entrambi hanno torto . Se si implementa il proprio crypto, non importa quanto banale parte di un credi che stai facendo, si sta andando a fare errori.

HMAC è un approccio migliore, ma anche se stai usando qualcosa come SHA-1, hai già scelto un algoritmo che non è adatto per l'hash della password a causa del suo design per la velocità. Usa qualcosa come bcrypt o eventualmente scrypt e togli completamente il problema dalle mani.

Oh, e non pensare nemmeno di confrontare gli hash risultanti per l'uguaglianza con il tuo linguaggio di programmazione o le utility di confronto delle stringhe di database. Questi confrontano carattere per carattere e cortocircuito come falsese un personaggio differisse. Quindi ora gli attaccanti possono usare metodi statistici per provare a capire cos'è l'hash, un personaggio alla volta.

Non dovrebbe fare alcuna differenza. L'hash non sarà più facilmente indovinabile ovunque tu abbia messo il sale. Le collisioni tra hash sono rare e imprevedibili, in quanto intenzionalmente non lineari. Se facesse la differenza per la sicurezza, ciò suggerirebbe un problema con l'hash, non con la salatura.

Se usi un hash crittograficamente sicuro, non dovrebbe importare se pre o postfix; un punto di hashing è che un singolo bit di modifica nei dati di origine (non importa dove) dovrebbe produrre un hash diverso.

Ciò che è importante, tuttavia, è usare sali lunghi, generarli con un corretto PRNG crittografico e avere sali per utente. Memorizzazione dei sali per utente nel database è non è un problema di sicurezza, usando un hash a livello di sito è .

Prima di tutto, il termine "tavolo arcobaleno" viene costantemente utilizzato in modo improprio. Una tabella "arcobaleno" è solo un particolare tipo di tabella di ricerca, che consente un particolare tipo di compressione dei dati sulle chiavi. Scambiando il calcolo per lo spazio, una tabella di ricerca che richiederebbe 1000 TB può essere compressa mille volte in modo da poter essere memorizzata su un'unità disco più piccola.

Dovresti essere preoccupato per l'hash per la password delle tabelle di ricerca, arcobaleno o altro.

@ Onebyone.livejournal.com:

L'attaccante ha "tabelle arcobaleno" che consistono non negli hash delle parole del dizionario, ma nello stato del calcolo dell'hash appena prima di finalizzare il calcolo dell'hash.

Potrebbe quindi essere più economico forzare una voce di file con password bruta con postfix salt rispetto al prefisso salt: per ogni parola del dizionario a sua volta caricheresti lo stato, aggiungi i byte salt nell'hash e poi lo finalizzi. Con il prefisso salt non ci sarebbe nulla in comune tra i calcoli per ogni parola del dizionario.

Per una semplice funzione hash che scansiona linearmente attraverso la stringa di input, come un semplice generatore congruenziale lineare, questo è un attacco pratico. Ma una funzione hash crittograficamente sicura è deliberatamente progettata per avere più round, ognuno dei quali utilizza tutti i bit della stringa di input, in modo che il calcolo dello stato interno appena prima dell'aggiunta del salt non abbia senso dopo il primo round. Ad esempio, SHA-1 ha 80 colpi.

Inoltre, algoritmi di hashing delle password come PBKDF compongono la loro funzione hash più volte (si consiglia di ripetere PBKDF-2 almeno 1000 volte, ciascuna iterazione che applica SHA-1 due volte) rendendo questo attacco doppiamente impraticabile.

BCrypt hash se la piattaforma ha un provider. Adoro come non ti preoccupi di creare i sali e puoi renderli ancora più forti se vuoi.

Inserire il salt un numero arbitrario di caratteri nella password è il caso meno atteso, e quindi il più "sicuro" socialmente, ma in realtà non è molto significativo nel caso in cui si utilizzi una password lunga e unica per password stringhe per sali.