Il troncamento dell'hash crittografico rende impossibile il crack?

Sicuramente no, semmai questa pratica mina la funzione di hash rendendo più facile trovare una collisione durante una ricerca esauriente. Nel senso di una password, qualsiasi testo semplice che produce lo stesso valore di hash è una password valida .

Detto questo, ChromeOS utilizza un hash troncato della tua password Google nella loro funzione s2k per Schema di crittografia del disco di Google . Sospetto che ciò sia stato per rendere più difficile rompere la tua password di Google a favore, rendendo più facile trovare una password che decrittografa il tuo disco ... il che è un po 'inquietante.

Che cos'è "cracking"? Sta trovando un valore di password che il tuo sistema accetterà, cioè uno che corrisponderà a qualsiasi cosa il tuo sistema memorizzi come valore hash nel suo database. Se l'utente malintenzionato trova un'altra password, diversa dalla "vera" password, ma che corrisponde all'hash, allora l'attaccante vince comunque.

Per un determinato valore hash, ci sono già molte password corrispondenti (perché ci sono "solo" 2 ²⁵⁶ possibili valori hash e molte più password possibili se accetti password "lunghe", diciamo 50 caratteri). Troncando il valore hash, si aumenta solo il numero di password che, una volta triturate e troncate, corrisponderanno a quelle memorizzate; cioè rendi le cose più semplici per l'aggressore.

Ora le cose non sono necessariamente così terribili. SHA-256 offre 256 bit di output perché prova ad offrire resistenza alle collisioni di almeno 2 ¹²⁸ e hai bisogno di 256 bit di output per ottenere quella resistenza. Tuttavia, le collisioni non rappresentano un problema per l'archiviazione delle password con hash; ciò che è necessario è resistenza alle pre-immagini . Questo richiede solo n bit di output per la resistenza 2 ⁿ . In altre parole, se si mantengono solo 128 bit (ovvero 32 caratteri esadecimali), si sta ancora "bene", o almeno non sostanzialmente peggiore di quello che si otterrebbe con i 64 caratteri completi.

Attenzione: un semplice hash è non buono . Anche se non lo indebolisci ulteriormente (almeno non in un modo praticamente significativo) troncandolo, hai già due problemi:

• Non hai sale, che consente all'aggressore di applicare il parallelismo in base al tempo o allo spazio. Vale a dire, attaccando più password contemporaneamente e / o usando tabelle precalcolate (tabelle arcobaleno).
• Un singolo hash è troppo veloce, rendendo facile per l'utente malintenzionato provare milioni, forse miliardi di potenziali password al secondo.

Quindi è necessario un processo di hashing della password migliore, che può essere configurato per la lentezza e che utilizza un salt (un nuovo salt casuale per la password each ). La raccomandazione abituale è bcrypt . Quindi, e solo allora, potrebbe prevedere un troncamento (ma mantenere almeno 128 bit, e le alterazioni fatte in casa agli algoritmi crittografici non sono raccomandate su base generale).

Modifica: per chiarire le cose: un utente malintenzionato con potenza di calcolo illimitata può tentare di enumerare tutte le password possibili e mantenere quelle che corrispondono ai valori hash memorizzati - questi sono candidati per essere il "vero" parola d'ordine. Troncando l'hash, si aumenta il numero di candidati, quindi, in una certa luce, l'attaccante è più lontano dall'indovinare la "vera password". Tuttavia, l'autore dell'attacco non è dopo la "vera password", ma dopo una password che garantisce l'accesso. Qualsiasi password che corrisponda al valore memorizzato concederà l'accesso, poiché il server concede l'accesso sulla base di "la password inserita corrisponde al valore hash memorizzato". Quindi ogni candidato è abbastanza buono per l'aggressore.

Troncando l'hash, puoi solo renderlo più facile da decifrare. Diciamo che l'hash è 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae e si memorizza 2c26b46b68ffc68ff99b453c1d304134. L'aggressore ora ha un compito più semplice: può trovare qualsiasi password il cui hash inizia con 2c26b46b68ffc68ff99b453c1d304134. Se sta usando una tabella di ricerca, potrebbe dover ridisporla un po 'per adattarsi al tuo formato non standard, ma è una quantità di lavoro che è approssimativamente proporzionale alle dimensioni del tavolo.

Penso che per "funzione hash" intendi qualcosa come PBKDF2 o bcrypt , dato che menzioni "sali, iterazioni, ecc.". Funzioni come la famiglia SHA non sono un modo appropriato per memorizzare gli hash (vedi Perché è usando il sale più sicuro? ). L'unico modo per invertire una corretta funzione di hash è la forza bruta diretta: indovina la password, calcola l'hash della tua ipotesi, confronta con l'hash di riferimento. Se l'hash di riferimento è un troncamento dell'hash reale, l'attaccante guadagna una quantità trascurabile di tempo durante il confronto. Per un massiccio attacco di forza bruta, o se troncate troppo l'hash, l'attaccante può rendere più semplice il suo lavoro trovando una collisione sull'hash troncato che non sarebbe stato uno sull'hash originale. Tuttavia, questo non è un problema serio nella pratica, perché il punto debole sarà comunque la password.

Con una buona funzione di hash, ogni bit è il più indipendente possibile dagli altri bit e non rivela alcuna informazione sull'hash. Pertanto una funzione di hash troncata è ancora una funzione hash, con forza ridotta. Se la tua funzione di hash è una delle funzioni SHA (o implicitamente un hash iterato derivato da uno SHA), il I consigli NIST per l'utilizzo degli hash (NIST SP-800-107, §5.1) illustrano la forza che ci si può aspettare da un troncamento a N bit.

Penso che questa domanda abbia delle buone risposte, quindi voglio solo provare a pensare in un approccio diverso:

Dato che hash, salt, ecc, è tutto fatto nel modo più noto, si ottengono 64 caratteri (32 byte) come output. Se passi 30 byte e tieni solo 2 byte, sarà più facile trovare le password che genereranno quell'output da 2 byte? Probabilmente sì, ci saranno molte password che genereranno quei 2 byte.

E se passi via 28 byte, mantenendo 4 byte? Probabilmente meno password si adatteranno, ma ancora molte più password rispetto all'hash originale da 32 byte.

E così via ...

Supponiamo di avere l'hash 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae che è stato generato da un input valido. Consente di semplificare le cose e troncare l'hash a 1 carattere e vedere i risultati della nostra azione.

Il nostro nuovo hash è "2".

La domanda è: quanto sarebbe difficile invertire la password dall'hash troncato?

Molti algoritmi di cracking troveranno molte password diverse che corrispondono all'hash! Tuttavia, questo potrebbe non trovare mai l'input originale. Inoltre, l'input originale non ha mai potuto dimostrare di aver creato questo hash.

Supponiamo ora un diverso hash troncato di 2 caratteri.

Il nuovo hash è "2c".

Molto meno le password saranno in grado di eguagliare il nuovo hash troncato, ma ce ne saranno ancora molte.

Da questo schema puoi vedere che più un hash viene troncato, più password potrebbe essere!

Ovviamente , questo farà male anche all'autenticazione.

Dovrebbe essere ovvio, ma questo non protegge il tuo sito; protegge l'utente che ri-utilizza la propria password su altri siti. Complimenti per pensare ai tuoi utenti (e farlo in modo realistico).

Ad ogni modo, questo è esattamente equivalente all'utilizzo di una funzione hash più breve.

Il problema è che suggerisci un numero fisso di bit. Ma la lunghezza della password e la forza in generale sono piuttosto variabili.

È stato suggerito che i punti di forza delle password comuni sono equivalenti a una chiave casuale di lunghezza 18-30 bit. Quindi, potresti usare quella teoria e troncare l'hash a 15 bit - ma poi le password a 18 bit richiederebbero solo 2 ³ = 8 ipotesi, una volta che hai rotto l'hash. In secondo luogo, se sei preoccupato di essere chiamato irresponsabile, fare ciò significa "implementare la tua crittografia personalizzata è una pessima idea", e "sembrerà incredibilmente stupido se apparirà nelle notizie". ("15 bit security, anyone"?).

Questa non è una buona idea. Dovresti utilizzare invece tecniche di rafforzamento della chiave standard come PBKDF2 o scrypt.

Troncare l'hash può ridurre la sicurezza di tale hash aumentando la probabilità che un utente malintenzionato sia in grado di determinare una password che genera tale hash. Comunque la domanda è se ci sia qualche cambiamento nella difficoltà di determinare la la password usata per generare l'hash. Questo è importante se viene utilizzata la stessa password per generare più hash (utilizzando diversi sali).

Aggiorna

Pensando di più a questa scorsa notte, se l'attaccante ha accesso al sale, non c'è alcun impatto sul difficile recupero della password principale. La logica è quindi: poiché un piccolo cambiamento nell'input dell'hash avrà un grande impatto sull'output dell'hash, lo stesso sarà vero per l'hash parziale. Pertanto, se una parte dell'input è nota, l'unico modo per creare l'output è se viene determinata la password principale.

Questo non fa assolutamente alcuna differenza se non che il software di cracking originale dovrebbe essere modificato per gestirlo correttamente.