Sale "reale" e "finto"

La distinzione è arbitraria. Un algoritmo basato sul sale funziona prendendo i dati di input e rimescolandoli in vari modi, e non c'è alcun metodo per inserire il sale che è più o meno "falso" di qualsiasi altro.

Cercando di escogitare un algoritmo di elaborazione della password che sia efficiente su una CPU generica ma che non si adatta bene a una GPU (o a un FPGA o ASIC personalizzato) è un vero argomento di ricerca. Questo è ciò che scrypt riguarda, e probabilmente bcrypt fa già un buon lavoro. L'idea qui è di usare gli accessi in tabelle che sono costantemente modificate; l'accesso alla tabella nella RAM è qualcosa a cui le CPU generiche sono buone, ma che rende le cose difficili per GPU (possono farlo, ma non con un parallelismo completo come quello che si ottiene di solito con una GPU).

Sì, c'è una distinzione valida da tracciare; avresti bisogno di un crittologo per dirti quanto sia significativa la differenza.

Un "vero sale" come hai descritto è usato per "perturbare l'algoritmo di crittografia". Lo capisco vagamente, ma non abbastanza per descriverlo correttamente. Basti dire che con un vero salt, il testo della password originale è codificato ma con output diversi a seconda di come l'algoritmo incorpora l'input salt (l'algoritmo ha (almeno due) input, il sale e (separatamente) il testo della password originale).

Un "finto sale" comporta la modifica del testo della password originale con il sale prima di cifrarlo con l'algoritmo di crittografia. Ad esempio, se la mia password è "nezperce" e il mio sale è "qp", l'algoritmo verrà consegnato al testo della password modificato "qpnezperce" per la codifica. Se Alice cerca anche di usare la password "nezperce", ma ha salt "w4", allora l'algoritmo codificherà il testo della password modificato "w4nezperce" per lei. Di conseguenza, il suo hash crittografato sarà diverso dal mio, anche se utilizzeremo entrambi la stessa password.

Entrambi i metodi forniscono il vantaggio principale del sale; per garantire che la stessa password non sia sempre codificata allo stesso modo. L'uso dei sali aumenta la difficoltà di montare un attacco di hash precalcolato (in precedenza ho detto dizionario o attacco a forza bruta, vedere i commenti).

Credo che ci siano altri vantaggi nell'usare un "sale reale", come un maggiore overhead computazionale (che rallenta gli attacchi). Ma, di nuovo, avresti bisogno di qualcuno con più abilità cripto di me per sapere se è vero o no.

Penso che il vantaggio di un "finto sale" sia che è più facile da implementare e richiede meno criptazione. So che il posto in cui ho più comunemente visto i sali falsi sono le applicazioni web che gestiscono il proprio database di autenticazione.

Non ho familiarità con i dettagli dell'implementazione della crittata Unix originale. Ma non sembra che abbia davvero senso per me. Soprattutto considerando quale sia lo scopo della salatura delle password in primo luogo. Penso che se si utilizza un salt cambia il tuo algoritmo per renderlo 'più strong', quindi stai usando l'algoritmo sbagliato in primo luogo.

Ero anche al discorso e fui quello che si sedette con entrambi i crittografi durante il discorso. Il vero sale rispetto a un finto sale mi ha davvero incuriosito. Ora perdonami perché non ho i miei appunti di fronte a me, ma c'è una grande differenza nella sicurezza del vero sale rispetto a un sale finto. Un vero sale altera la chiave mentre entra nel codice a blocchi, quindi non solo la chiave in chiaro (password) è la chiave per determinare in che modo le iterazioni avranno luogo. Ora un sale falso altera semplicemente il testo in chiaro (password) e la chiave rimane la stessa. Regolando l'algoritmo il vero sale diventa esponenzialmente più difficile da rompere di un sale finto.

Quindi usiamo un esempio per descriverlo. In questo esempio userò un hash MD5 (non ricordo se è possibile utilizzare un vero sale su MD5, anche se così non mi fiamma per questo) con un vero sale e un sale falso. Ora diciamo che sto usando CUDA-Multiforcer come mio cracker per password GPU. Avrei impostato di correre contro lo standard MD5 per provare a decifrare la password ma da quando ho salato la password poteva girare per sempre in base al sale (vero o falso). Ora parte della descrizione che mi è stata data è stata la capacità di rompere il sale finto e di come ci sia voluto un po 'più a lungo per calcolare / spezzare spezzando l'hashish. Non ho seguito quello che stavano dicendo in modo che potessi essere lontano da quello. Ora assumiamo che siamo stati in grado di acquisire la password salt (true of fake). Usando un sale finto, lo inseriamo nel nostro password cracker e continuiamo a usare la forza bruta fino a quando non possiamo abbinare gli hash. Non molto difficile da eseguire e verrà eseguito abbastanza rapidamente.

Ora, se usassimo un vero sale, sarebbe esponenzialmente più difficile, e più lungo per rompere gli hash. Usando un vero sale dovrei riscrivere una parte del CUDA-Multiforcer per usare un vero sale con l'algoritmo specifico che era in uso. Ricorda che cambia la chiave nel codice, il che significa che non si tratta solo di un semplice cambio di testo, è un cambiamento dell'algoritmo, quindi ora devo modificare il codice per farlo. Ok, ora abbiamo cambiato il modo in cui viene eseguito il cracker delle password, ora ci imbattiamo in un problema di velocità. Con il cambio della chiave ora ci vuole un bel po 'di tempo per testare ogni password, dato che ora sta cambiando l'iterazione che usa per ogni password forzata bruta. Entrambi mi hanno dato alcuni esempi della differenza nella velocità, e penso che con un sale finto era circa 1 milione al secondo, e un vero sale era intorno

La distinzione tra sale falso e sale reale è diversa se gli algoritmi di hashing sono nascosti all'attaccante. un "sale reale" che determina una variazione dell'algo di hashing in un algo standard aperto sarebbe facilmente implementato da un attacco GPU / distribuito, poiché tutti gli input sono noti all'attaccante e quindi il sub-algo può essere facilmente determinato prima di tempo.

I primi hashing di Unix per le password (come ricordo da Bell System V7) NON fornivano l'algoritmo per l'hashing della password: era l'unica parte del sistema per cui si poteva ottenere solo il file .o, dove le università sono state in grado di ottenere il codice sorgente per tutto il resto.