PKCS # 5 Privacy del sale? [duplicare]

7

Nella documentazione ufficiale dello standard PKCS5 V2.0, possiamo leggere "Il sale può essere visto come un indice in un ampio set di chiavi derivate dalla password e non deve essere tenuto segreto."

La parte "non deve essere tenuta segreta" è interessante.

Poiché il sale viene utilizzato per aggiungere una vasta gamma di possibilità di password (o per creare due chiavi diverse se due utenti hanno la stessa password), qual è lo scopo di lasciare il sale insicuro?

Capisco che in genere un utente malintenzionato non abbia accesso al sale, quindi complicherà il suo lavoro per trovare la password corretta. Ma se un attaccante conosce il sale, dov'è la "magia"? Conoscere il sale è come eseguire un attacco di dizionario tradizionale (se escludiamo il conteggio delle iterazioni)!

C'è qualcosa che non capisco? So che conoscere il sale non infrange la sicurezza, ma dire che "non deve essere tenuto segreto" mi sembra strano.

    
posta Normand Bedard 30.05.2011 - 16:20
fonte

2 risposte

4

Mantenere qualcosa di privato è difficile (ad es. costoso). Per un elemento di dati confidenziali, solitamente chiamato "chiave" (a volte una "password" quando la suddetta chiave può essere memorizzata in un sistema basato sull'uomo), dobbiamo pensare all'intero ciclo di vita chiave: come, quando e dove è creato, memorizzato, copiato e cancellato. In alcuni (molti!) Contesti, una corretta gestione delle chiavi richiede sistemi di storage fisici resistenti alle manomissioni (smartcard, HSM ...); questi non crescono sugli alberi. Non c'è bisogno di alcun motivo per non voler mantenere qualcosa di privato; piuttosto, abbiamo bisogno di ragioni esplicite per fare qualcosa che valga la pena essere privati.

Un salt non è una chiave (altrimenti la chiameremmo una chiave, non una salt). Il suo punto deve essere distinto per ogni istanza, anche se viene utilizzata la stessa chiave. Il sale impedisce molti tipi di condivisione dei costi, in cui un utente malintenzionato può attaccare elementi protetti N (ad esempio password hash) per meno di N volte il costo dell'attacco. Una forma di condivisione dei costi è una tabella precalcata, ad es. "tavoli arcobaleno". Un sale sconfigge questo essendo unico per ogni istanza.

Consentendo che il sale sia pubblico, rendiamo molto più facile avere un sale unico per istanza. Gestire così tante chiavi segrete sarebbe molto difficile, ma per gli elementi pubblici, invochiamo solo un PRNG e memorizziamo il valore così com'è, senza ulteriori indugi.

    
risposta data 31.05.2011 - 04:07
fonte
0

"need not be kept secret"

Probabilmente significano qualcosa come "non deve essere crittografato con crittografia strong"; ma non "dovrebbe essere pubblicizzato attivamente a tutti".

Lo scopo principale di sale è evitare la condivisione dei costi . La condivisione dei costi sarebbe a pre-calcolare una tabella hash una volta, quindi utilizzare la tabella hash per attaccare tutti gli account utente contemporaneamente. (O peggio ancora, efficacemente attaccare gli account utente su molti sistemi.)

Un sale grande e casuale protegge efficacemente dalla condivisione dei costi. E lo fa anche se è memorizzato in testo in chiaro accanto alla rappresentazione con hash della password.

Pensa in questo modo: eseguire una ricerca attraverso un gigantesco set di dati richiede tempo; Le dimensioni della RAM e le velocità della RAM I / O sono limitate. Ad un certo punto la dimensione della tabella hash precalcolata diviene proibitiva. Il sale ha poi raggiunto il suo scopo, che sia tenuto segreto o meno.

(Quando l'approccio alla tabella hash non è fattibile, l'autore dell'attacco passerebbe presumibilmente alla semplice esecuzione della funzione hash. Fx attacco brute-force eseguendo l'hash delle potenziali password in parallelo su cluster di macchine economiche .)

    
risposta data 30.05.2011 - 18:52
fonte

Leggi altre domande sui tag