Salare la tua password: le migliori pratiche?


162

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. :)



1
@Jaccco: input fantastico. Grazie!
Randolpho,

3
La migliore pratica è utilizzare una funzione crittografica che esegua la salatura per te, usando PBKDF2 (lo standard), bcrypt o persino scrypt. Grazie a Stephen per averlo sottolineato.
Maarten Bodewes,

1
Praticamente tutte le costruzioni standard di hashing delle password si occupano di combinare salt e password, quindi non dovresti preoccuparti di questo. Se non usi un hash password standard, passa a uno.
CodesInChaos

1
@Omu Bad raccomandazione. 1) Una singola iterazione di SHA-1 è troppo veloce, dovresti usare almeno 10000 e anche questo è abbastanza debole. 2) Il sale predefinito è troppo piccolo. 8 byte è minimo e si consiglia 16.
CodesInChaos

Risposte:


111

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.


4
Ho aggiunto un link a una vecchia domanda, leggi quelle risposte. Fondamentalmente, non usando un salt diverso casuale per password si corre un inutile rischio per la sicurezza, questo potrebbe essere un vero problema in futuro.
Georg Schölly,

39
Il salt casuale a livello di sito è negativo, poiché un utente malintenzionato può pre-calcolare tabelle arcobaleno e catturare l'intero database utente. Se non lo capisci, ti preghiamo di non scrivere i sistemi di login / sicurezza :) - DEVI utilizzare i sali per utente.
snemarch,

3
Sì, sale per utente. Idealmente, con iterazioni per utente memorizzate (in modo da poter aumentare il numero di iterazioni utilizzate nel tempo). Qualsiasi framework decente avrà questo incorporato. (.NET ha PasswordDeriveBytes che gestirà tutto per te.)
MichaelGG

2
Se stai progettando qualsiasi tipo di sistema di sicurezza, è necessario non utilizzare sale per utente. il tuo sito potrebbe non essere molto interessante, ma considera gli utenti che usano la stessa password su più siti ... tentare di mantenere il database sicuro tende a fallire :)
snemarch

2
Naturalmente i sali proteggono dagli attacchi dei dizionari, proprio rendendoli molto più lenti. L'uso di sali nelle password precede di gran lunga le tabelle arcobaleno. I sali sono stati aggiunti specificamente per rallentare gli attacchi del dizionario, impedendo agli aggressori di eseguire l'hashing di una password una volta confrontandola con tutti gli utenti.
Glenn Maynard,

27

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: © ¤¡


@onebyone, accidenti! Ha scoperto il mio sale di "passwordsalt"!
Samuel,

6
@Samuel: Non so voi ragazzi, ma usiamo "12345" per il nostro sale. :)
Randolpho,

@onebyone valid. Intendevo davvero "comune" come "tutti i sali di lunghezza X nel set di caratteri Y" dove X, Y sono ragionevoli; diciamo 20 caratteri e maiuscolo / minuscolo alfanumerici. Estendibile per dire tutte le stringhe esadecimali sotto la lunghezza Z (diciamo 160) poiché penso che sarebbe utile una tabella arcobaleno di hash con hash.
Tom Ritter

1
@Randolpho: Ehi, anche questo è il mio sale! Quali sono le probabilità?
Adrien,

E assicurati che il sale non sia prevedibile / Casuale: stackoverflow.com/questions/1645161/…
Jacco il

18

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.


1
Per quanto riguarda l'ultimo paragrafo: come può l'attaccante ottenere informazioni sul numero esatto di personaggi che il confronto ha fallito? Questo non ha senso ..
halloweenlv

1
Sei sia corretto che errato. Gli attacchi al tempismo sono reali e si sono dimostrati ripetutamente fattibili con una precisione spaventosa anche su connessioni di rete a latenza variabile per determinare esattamente dove il confronto è fallito. Detto questo, gli attacchi di temporizzazione non sono effettivamente applicabili agli hash delle password comuni, dal momento che non è fattibile dal punto di vista computazionale trovare input che cambiano solo piccole parti dell'output.
Stephen Touset,

9

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.


1
Le collisioni di hash dipendono dalla dimensione dell'hash. Grazie al problema del compleanno, le collisioni sono abbastanza probabili.
Georg Schölly,

2
Solo se tronchi il risultato. Ad ogni modo, continuo a sostenere che non farà alcuna differenza dove si trova il sale, perché il punto dell'hash è di rendere la relazione tra input e output non contenente schemi.
Phil H,

7

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 è .


2
Risposta errata: un utente malintenzionato potrebbe pre-calcolare MD (pass) per molte password usate di frequente e quindi calcolare MD (pass + salt) in modo molto economico perché il digest dei messaggi funziona in modo incrementale in modo da supportare lo streaming.
Erwan Legrand,

5

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.


Dovresti ricontrollare la descrizione dei round. I round sono su una base per pezzo, non l'intero messaggio. (Altrimenti, l'hashing dei dati di streaming richiederebbe il riavvolgimento più e più volte.) L'uso delle iterazioni evita il problema menzionato.
MichaelGG,

4

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.


3
Per quanto ne so, BCrypt Hash ha bisogno di salare, proprio come qualsiasi altro schema di hashing.
Jacco,

2

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.