Esiste una difesa contro Brute-Force eseguita su un file crittografato locale?

L'unica difesa che puoi avere su un file crittografato localmente è la forza della password usata per crittografarlo. Inoltre, l'utilizzo di un algoritmo di crittografia sicura è importante (AES è piuttosto standard in questo momento).

Hai assolutamente ragione che il cracking a forza bruta ha successo al 100%. Il problema risiede nella quantità di tempo necessario per decifrare una password. Una password sicura sarà molto lunga e userà una combinazione di lettere maiuscole e minuscole, numeri e simboli. In tal modo, si assegna all'autore dell'attacco uno spazio chiave di 96 caratteri. Supponiamo che tu usi una password di 32 caratteri. Ciò equivale a 2.208.192.040.014.184.559.945,134,363,758,220,403,329,915,059,847,434,832,829,218,816 combinazioni possibili di 32 password di caratteri.

Un altro fattore è la velocità con cui un computer è in grado di generare ogni password durante la bruteforcing. Sul mio computer, posso generare circa 50.000.000 di hash MD5 al secondo. Allo stesso modo, per le chiavi WPA (wifi), posso generare solo circa 2.000.

La tua idea di avere un programma con una funzione di "autodistruzione" quando vengono provate troppe password è una forma di sicurezza piuttosto debole - molto più debole di una password. Prendiamo ad esempio il software di crittografia del disco, TrueCrypt. Con TrueCrypt puoi creare contenitori di file crittografati. Tuttavia, c'è del software là fuori che è fatto apposta per crackare i volumi crittografati da TrueCrypt - senza mai usare il software TrueCrypt. Lo stesso può accadere anche per il tuo programma teorico.

Quindi, alla fine, la migliore sicurezza per un file crittografato localmente è di avere una password lunga con un mix di caratteri e di utilizzare una crittografia standard ritenuta sicura dalla comunità.

Se il file viene recuperato dal filesystem al sistema dell'attaccante, non c'è più alcun gateway. La forza bruta può continuare senza alcun impedimento.

Le chiavi o le password più complesse aumentano il tempo / il costo della forzatura bruta, ma "alla fine" (si spera prima della morte termica dell'universo), potrebbe essere rotto.

Il problema è che non c'è motivo per cui un utente malintenzionato debba utilizzare il TUO programma per eseguire la decrittografia. In effetti, per aumentare la velocità, gli hacker scrivono quasi sempre programmi personalizzati su forza bruta, non sul programma originale usato per crittografare. Possono farlo perché praticamente tutti i programmi di crittografia affidabili, anche quelli proprietari, utilizzano algoritmi noti e ampiamente conosciuti per eseguire la crittografia. Ciò semplifica la scrittura di un programma personalizzato da decrittografare piuttosto che utilizzare il programma originale. Pertanto, qualsiasi protezione da forza bruta nel programma originale sarebbe inutile.

Potresti pensare, perché non creare un algoritmo di crittografia personalizzato o apportare qualche modifica a quelli esistenti e mantenere il programma closed-source per impedire alle persone di scrivere i propri programmi di decrittografia? Il motivo principale per cui questa è una cattiva idea è che gli algoritmi sicuri sono difficili da trovare, e il tweaking di algoritmi ben collaudati e testati è pericoloso - è MOLTO facile introdurre accidentalmente una backdoor. Inoltre, è la sicurezza attraverso l'oscurità, che è generalmente disapprovato. Alla fine, qualcuno decodificherà il tuo programma alla fine e capirà quali modifiche hai aggiunto, rendendo queste misure inutili.

Quindi in realtà nessuna misura del software può proteggere completamente dagli attacchi di forza bruta (teoricamente parlando). In pratica, però, una lunga passphrase e algoritmi computazionalmente intensi possono renderlo completamente irrealizzabile anche per i supercomputer più potenti.

È possibile che i dati vengano cancellati dopo x tentativi, ma è necessario implementarli a livello hardware, ovvero, progettare l'hardware per rendere impossibile ottenere una copia dei dati crittografati senza prima sbloccarli. Quindi aggiungere misure anti-manomissione all'hardware. Credo che alcune unità flash ad alta sicurezza, come Ironkey, siano in grado di farlo.

Inizierò col dire che hai ragione, alla fine la forza bruta potrebbe rompere qualsiasi schema di crittografia. Il futuro potrebbe comunque essere milioni di anni nel futuro, a seconda della complessità della chiave di crittografia, della forza della crittografia, ecc. Esistono in realtà alcune difese contro i tentativi offline di decifrare un file di password che sono generalmente considerati best practice.

Dal momento che dici di non essere chiari su come funzionano le password e l'hashing, darò una breve descrizione di ciò che si applica anche alla crittografia dei dati in generale. Sono sicuro che hai sentito dire che le password in chiaro sono un problema. La soluzione a questo sta usando un algoritmo di hashing.

Ci sono tre parti chiave per qualsiasi algoritmo di hashing della password. Dovrebbe sempre risultare nello stesso hash con lo stesso testo che viene prodotto. Dovrebbe essere computazionalmente costoso da calcolare. Dovrebbe essere a 1 via o avresti lo stesso problema dell'elenco di password in chiaro. Una volta che l'hashing ha cominciato a diventare popolare, gli aggressori si sono adattati rapidamente. Avrebbero generato hash di password comunemente utilizzate, note come tabelle arcobaleno e quindi basta abbinare questi hash agli hash nel database. Questo è molto meno dispendioso dal punto di vista computazionale del calcolo di ogni hash al volo, poiché questi algoritmi di hashing sono deliberatamente lenti.

Il presupposto che devi fare è che il tuo database delle password possa essere rubato da un malintenzionato. E più a lungo ci vuole per farglielo scoppiare, più è probabile che tu possa rilevare il loro attacco e resettare le tue credenziali. Questo è anche un motivo per cui è consigliabile 90 giorni per la rotazione della password, poiché riduce una finestra durante la quale tali credenziali sono utilizzabili. Ad ogni modo, descriverò le basi di queste difese in modo da poter continuare a studiare su questo argomento e su parole specifiche in grassetto che sono di interesse specifico.

Prima di tutto, qualsiasi schema di crittografia del database delle password dovrebbe includere un salt . Un esempio di uno schema di crittografia delle password che include un salt è bcrypt , che è una buona base di ciò che deve essere cercato con qualsiasi funzione di questa funzione. Viene generato un salt per ogni password e aiuta a prevenire un attacco utilizzando tabelle arcobaleno . Le tabelle Rainbow usano un elenco di hash precalcolati, e un sale rende questo poco pratico da archiviare su disco a causa dei requisiti di dimensione pura.

Ci sono anche dei modi in cui puoi rendere difficile il calcolo di ogni hash. Questo fa sì che ogni ricerca sia più lenta, ma è comunque abbastanza veloce da non disturbare gli utenti. Rende molto più lento un attacco di forza bruta. bcrypt di nuovo è un buon esempio di questo.

Il terzo è la difesa più comunemente nota, best practice per le password . Sembra abbastanza banale, ma può aiutare a garantire che qualsiasi attacco basato sull'uso di dizionari di password comuni fallisca e che siano necessarie molte tecniche di bruce force molto più lente.