Domanda

Sto scrivendo una piccola app desktop che dovrebbe essere in grado di crittografare un file di dati e proteggerlo con una password (ad es.è necessario inserire la password corretta per decrittografare).Voglio che il file di dati crittografato sia autonomo e portatile, quindi l'autenticazione deve essere incorporata nel file (o almeno così presumo).

Ho una strategia che sembra praticabile e logica in base a ciò che so (il che probabilmente è appena sufficiente per essere pericoloso), ma non ho idea se sia effettivamente un buon progetto o meno.Allora dimmi:è pazzesco?Esiste un modo migliore/migliore per farlo?

  • Passo 1:L'utente inserisce la password in testo semplice, ad es."La mia password difficile"
  • Passo 2:L'app esegue l'hashing della password dell'utente e utilizza tale valore come chiave simmetrica per crittografare/decrittografare il file di dati.per esempio."MyDifficultPassword" --> "HashedUserPwdAndKey".
  • Passaggio 3:L'app esegue l'hashing del valore con hash del passaggio 2 e salva il nuovo valore nell'intestazione del file di dati (ad es.la parte non crittografata del file di dati) e utilizza tale valore per convalidare la password dell'utente.per esempio."HashedUserPwdAndKey" --> "HashedValueForAuthentication"

Fondamentalmente sto estrapolando dal modo comune di implementare le password dei siti web (quando non si utilizza OpenID, cioè), che consiste nel memorizzare l'hash (salato) della password dell'utente nel proprio DB e non salvare mai la password effettiva .Tuttavia, poiché utilizzo la password utente con hash per la chiave di crittografia simmetrica, non posso utilizzare lo stesso valore per l'autenticazione.Quindi la eseguo di nuovo, trattandola sostanzialmente come un'altra password, e salvo il valore con doppio hash nel file di dati.In questo modo posso trasferire il file su un altro PC e decrittografarlo semplicemente inserendo la mia password.

Quindi questo progetto è ragionevolmente sicuro, o irrimediabilmente ingenuo, o una via di mezzo?Grazie!

MODIFICARE:chiarimenti e domande di follow-up in merito a:Sale.
Pensavo che il sale dovesse essere tenuto segreto per essere utile, ma le tue risposte e i tuoi collegamenti implicano che non è così.Per esempio, questa specifica collegato da erickson (sotto) dice:

Pertanto, la derivazione della chiave basata su password come qui definita è una funzione di una password, un salt e un conteggio di iterazioni, dove le ultime due quantità non devono essere mantenute segrete.

Ciò significa che potrei memorizzare il valore salt nello stesso posto/file della chiave con hash ed essere comunque più sicuro che se non usassi affatto salt durante l'hashing?Come funziona?

Un po' più di contesto:il file crittografato non è pensato per essere condiviso o decrittografato da altri, si tratta in realtà di dati di un singolo utente.Ma mi piacerebbe distribuirlo in un ambiente condiviso su computer che non controllo completamente (ad es.al lavoro) ed essere in grado di migrare/spostare i dati semplicemente copiando il file (così posso usarlo a casa, su diverse postazioni di lavoro, ecc.).

È stato utile?

Soluzione

Generazione di chiavi

Consiglierei di utilizzare un algoritmo riconosciuto come PBKDF2 definito in PKCS#5 versione 2.0 per generare una chiave dalla tua password.È simile all'algoritmo che descrivi, ma è in grado di generare chiavi simmetriche più lunghe da utilizzare con AES.Dovresti essere in grado di trovare una libreria open source che implementa generatori di chiavi PBE per diversi algoritmi.

Formato del file

Potresti anche considerare di utilizzare il file Sintassi del messaggio crittografico come formato per il tuo file.Ciò richiederà un po' di studio da parte tua, ma anche in questo caso ci sono librerie esistenti da utilizzare e apre la possibilità di interagire in modo più fluido con altri software, come i client di posta abilitati S/MIME.

Convalida della password

Per quanto riguarda il tuo desiderio di memorizzare un hash della password, se usi PBKDF2 per generare la chiave, potresti utilizzare un algoritmo di hashing della password standard (sale grosso, un migliaio di cicli di hashing) per questo e ottenere valori diversi.

In alternativa, potresti calcolare un MAC sul contenuto.È più probabile che una collisione di hash su una password sia utile a un utente malintenzionato;è probabile che una collisione di hash sul contenuto sia inutile.Ma servirebbe a far sapere a un destinatario legittimo che per la decrittazione è stata utilizzata la password sbagliata.

Sale crittografico

Sale aiuta a contrastare gli attacchi con dizionari precalcolati.

Supponiamo che un utente malintenzionato abbia un elenco di probabili password.Può eseguire l'hashing di ciascuno e confrontarlo con l'hash della password della sua vittima e vedere se corrisponde.Se l'elenco è lungo, l'operazione potrebbe richiedere molto tempo.Non vuole dedicare così tanto tempo al suo prossimo obiettivo, quindi registra il risultato in un "dizionario" in cui un hash punta all'input corrispondente.Se l'elenco delle password è molto, molto lungo, è possibile utilizzare tecniche come a Tavolo Arcobaleno per risparmiare spazio.

Tuttavia, supponiamo che il suo prossimo obiettivo abbia rubato la password. Anche se l'attaccante sa cos'è il sale, la sua tabella precalcolata non ha alcun valore—il salt modifica l'hash risultante da ciascuna password.Deve rieseguire l'hashing di tutte le password nella sua lista, apponendo il sale del bersaglio all'input.Ogni sale diverso richiede un dizionario diverso e, se vengono utilizzati abbastanza sali, l'aggressore non avrà spazio per archiviare i dizionari per tutti.Fare trading sullo spazio per risparmiare tempo non è più un’opzione;l'aggressore deve ricorrere all'hashing di ciascuna password nella sua lista per ciascun bersaglio che desidera attaccare.

Quindi non è necessario mantenere segreto il sale.È sufficiente garantire che l'aggressore non disponga di un dizionario precalcolato corrispondente a quel particolare sale.

Altri suggerimenti

Come ha affermato Niyaz, l'approccio sembra ragionevole se si utilizza un'implementazione di qualità di algoritmi potenti, come SHA-265 E AES per hashing e crittografia.Inoltre consiglierei di utilizzare a Sale per ridurre la possibilità di creare un dizionario di tutti gli hash delle password.

Naturalmente, leggendo Bruce Schneier'S Crittografia applicata neanche sbaglia mai.

Se stai utilizzando un algoritmo hash forte (SHA-2) e un algoritmo di crittografia forte (AES), andrà bene con questo approccio.

Perché non utilizzare una libreria di compressione che supporti i file protetti da password?In passato ho utilizzato un file zip protetto da password contenente contenuti XML :}

È davvero necessario salvare la password con hash nel file.Non puoi semplicemente usare la password (o la password con hash) con un po' di sale e poi crittografare il file con essa.Durante la decrittografia, prova a decrittografare il file con la password + salt.Se l'utente fornisce una password errata, il file decrittografato non è corretto.

L'unico inconveniente che posso pensare è che se l'utente inserisce accidentalmente una password errata e la decrittazione è lenta, deve aspettare per riprovare.E ovviamente se si dimentica la password non c'è modo di decrittografare il file.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top