Sicurezza crittografica di sali generati dinamicamente, non casuali

Naviga le tue risposte
12

Quindi, quando si parla di sicurezza, quando ho un'idea che sembra buona, ma sembra che nessun altro stia facendo, cerco di presumere che sto trascurando qualcosa di ovvio o comunque significativo. Questo è uno di questi casi ...

Il contesto di questa domanda è un sistema di autenticazione su cui sto lavorando. Ho implementato sistemi simili in passato, e generalmente ho la testa intorno alla cosa "sale e hashing", ma non sono affatto un esperto in sicurezza crittografica.

Mentre stavo definendo l'archiviazione per 16 byte casuali di sale sui miei record utente, mi è venuto in mente che potrebbe esserci un modo per ridurre la superficie di attacco nel caso in cui qualcuno mi abbia rubato o in altro modo dati utente. Sto operando al di fuori delle seguenti ipotesi:

  1. Se un hacker ruba i miei dati utente, hanno accesso a una rappresentazione salata + (ripetutamente) con hash della password dell'utente, e il valore salt stesso.
  2. Se l'hacker vuole determinare il valore in testo semplice di quella password, hanno un po 'di bruteforce di fronte a loro.
  3. Tuttavia, dato il sale, lo spazio di ricerca di quell'attacco di forza bruta è notevolmente ridotto. *

* Non sono sicuro al 100% che il punto tre sia corretto, ma ha senso che se un algoritmo di forza bruta può assumere che il valore pre-hash sia composto da <8-or-so-bytes-of-password> + <16-bytes-from-stolen-salt> (o una combinazione simile di password e sali), quindi abbiamo ridotto lo spazio di ricerca per quantità algoritmicamente significative.

< scuse obbligatorie a metà domanda per la lunghezza di questa domanda qui >

Quindi, considerando quanto sopra è la mia attuale linea di pensiero, la soluzione che sto considerando essenzialmente si riduce all'utilizzo di valori costanti e conosciuti su un utente per generare dinamicamente un sale da utilizzare durante la fase di hashing.

Dato che i valori di sale non hanno davvero bisogno di essere crittograficamente "nulla", a patto che non siano guidabili fino al punto di richiedere la scoperta di bruteforce, è sufficiente prendere essenzialmente alcune trasformazioni, ad esempio, del nome utente e della password forniti (ad esempio, applicare alcuni valori di SHA-2 e crittografi proprietari) e utilizzarli nel passaggio di hashing?

Naturalmente se qualcuno dovesse rubare il codice, la generazione di sale "segreta" è inutile. L'unica sicurezza aggiunta che sto cercando di raggiungere è costringere l'hacker a rubare i miei dati e il mio codice se vogliono la praticità dello spazio di ricerca ridotto descritto sopra al punto 3.

Spero di aver adeguatamente (e non troppo in modo verboso) descritto la mia domanda e il mio ragionamento. La domanda specifica a cui spero di avere una risposta è se questo sia o meno un metodo crittografico (o altrimenti) sicuro per archiviare e confrontare le password degli utenti.

Modifica: Sembra che i punti chiave della mia domanda potrebbero essersi persi nel rumore sopra. Lasciatemi provare ad essere più esplicito:
  1. L'accesso al sale utilizzato nella generazione di un valore hash aiuta sostanzialmente un attacco di forza bruta alla scoperta della password effettiva?
  2. In tal caso, è quindi logico che l'hacker debba rubare il mio codice oltre ai dati stessi?
  3. L'approccio generale di generare dinamicamente il sale (usando mezzi riproducibili, non casuali, ma non guidabili) è sconsigliato?
posta jmar777 15.09.2011 - 17:16
fonte

3 risposte

15

Sei in qualche modo in errore riguardo al ruolo del sale. È non pensato per essere "non percettibile dall'attaccante". Se fosse destinato a essere inconcepibile, sarebbe un dato confidenziale e lo chiameremmo una "chiave", non un "sale".

Il sale è lì per rendere il processo di derivazione della password univoco, al fine di impedire a un utente malintenzionato di effettuare economie di scala quando si attaccano diverse password. Se l'aggressore tenta di indovinare tre password, deve costargli tre volte tanto quanto attaccarne una. Un grande esempio di "economia di scala" è una grande tabella di hash precalcolati per password comuni (o la sua progenie malvagia, la tabella arcobaleno , che è solo un enorme tavolo precompilato con un trucco per mantenerlo semplicemente enorme). In presenza di un sale, non esiste una funzione hash one , ma uno per valore salt ; o, detto diversamente, una tabella precalcata sarebbe specifica per un dato sale (quello usato durante il calcolo) e inutile per attaccare qualsiasi password che non usi quel sale.

Naturalmente, se un utente malintenzionato può ottenere una copia delle password con hash ma non i sali corrispondenti, il suo compito diventa davvero molto difficile. Ma questo non è uno scenario plausibile: se hai un'area di stoccaggio in cui puoi mettere i sali fuori dalla portata dell'attaccante, allora perché non hai archiviato anche le password con hash? Quindi l'analisi della sicurezza presuppone che i sali siano noti all'attaccante. La loro utilità deriva dalla loro unicità: non ci sono due password hash distinte, sullo stesso o su sistemi diversi, nello stesso momento o in momenti diversi, hanno lo stesso valore di sale (nemmeno due password successive per lo stesso utente: quando cambi la password, cambia anche il sale).

Puoi generare e immagazzinare sali in qualsiasi modo tu ritenga opportuno, anche con un "generatore dinamico", a patto che la probabilità di riutilizzare un valore salino sia trascurabile. Questo è così precisamente perché dovrebbero essere pubblici e non devono essere "inaccessibili" dall'attaccante - le cose non guidabili richiedono artiglieria pesante .

C'è un concetto un po 'correlato che è stato talvolta chiamato "pepe": una chiave segreta che è anche inserita nel processo di hashing (vedi questa domanda precedente ). Quella chiave è condivisa a livello di sistema. L'idea sarebbe che una chiave univoca sia più facile da mantenere riservata rispetto a un intero database di password con hash, almeno in alcune configurazioni (ad esempio, la si mantiene in un file di configurazione privato, non nel database SQL). Il concetto di "pepe" implica una gestione più complessa (una cosa in più per eseguire il backup e non perdere o condividere tra server front-end) e vale la pena solo nello scenario marginale in cui un utente malintenzionato può scaricare il database degli utenti ma non il sistema host completo. In ogni caso, il "pepe" non realizza la proprietà di unicità che il sale fornisce, quindi il pepe non deve sostituire il sale - solo possibilmente completarlo .

    
risposta data 16.09.2011 - 01:23
fonte
3

Questo era un po 'lungo per i commenti.

Il sale in effetti dà loro un punto di partenza.

Tuttavia, in genere si tratta di un problema controverso in quanto il valore di conoscere una determinata password è quasi sempre correlato solo al numero totale di password che possono essere invertite dalla tabella utente. In altre parole, se devono passare letteralmente anni di tempo al computer per estrarre 10 password, i dati in effetti non hanno valore.

Sollevare nomi utente e password da un sito ha valore solo perché gli utenti tendono a riutilizzare la stessa password su più servizi. Ovviamente non è importante che un hacker effettui l'accesso come utente sullo stesso sito da cui ha estratto la password perché se fosse in grado di ottenere le password da te, allora le probabilità sono ottime che potrebbero anche estrarre qualsiasi altro dato desiderato.

Quando vendi questi nomi utente e password hanno valore perché quelle chiavi potrebbero aprire altri blocchi come account Facebook e siti bancari. L'unica altra situazione di cui hanno valore è pubblicamente vergognarsi pubblicando i nomi utente / password in un forum pubblico, ala Sony.

Quindi, se si utilizza un salt salt per password, si sta già aumentando il tempo necessario per ottenere qualcosa di valore al punto di stupidità. Inoltre le persone con le risorse necessarie per violare tutte queste password in un ragionevole lasso di tempo sono molto probabilmente agenzie governative ... il che è un problema completamente diverso.

Il che mi porta al mio voto: trova un problema diverso da risolvere.

    
risposta data 15.09.2011 - 19:07
fonte
-1

Un'importante legge sulla sicurezza è "smetti di provare a fare la tua cripta". Smetti di creare i tuoi sistemi di autenticazione e usa solo i sistemi standard. Non c'è niente di particolarmente sbagliato in ciò che proponi, ma mentre lo chiedi, dimostri che non capisci del tutto il problema. È come guardare un martello da carpentiere in un chiodo usando una chiave inglese. Non è tanto che non funzionerebbe come il fatto che diffideresti la sua competenza.

Se vuoi rendere la vita più difficile agli hacker, modifica il più possibile.

Semplifichiamo la tua domanda: cosa posso fare per rendere più dure le password? Li costringe a rubare la guida del codice sorgente?

Ad esempio, l'uso di SHA-2 rende più difficile per gli hacker. I loro strumenti sono ottimizzati per SHA-1 e MD5 e molti strumenti non funzionano con SHA-2.

Oppure, se vuoi davvero un segreto nel codice sorgente, le cose complesse che suggerisci non migliorerebbero la situazione più della semplice aggiunta di "x" alla parte anteriore del valore di sale. In questo modo, l'hacker potrebbe rubare i sali e gli hash, ma non sarebbe in grado di fare molto con loro senza conoscere anche il codice sorgente.

Ricorda che alcuni programmatori verranno dopo di te e dovranno mantenere il tuo codice. Se è un sistema bizzarro, stanno per strapparsi i capelli per la frustrazione. Se si tratta del normale sistema di autenticazione o di un normale sistema con una piccola modifica, non malediranno il tuo nome.

    
risposta data 21.09.2011 - 18:45
fonte

Leggi altre domande sui tag

La protezione WiFi WPA2 è protetta contro l'avvelenamento e lo sniffing ARP? Quando si esegue un PenTest su un sito protetto da WAF, cosa dovrebbe sapere un Pentestore per migliorare la qualità del test?