it-swarm.it

AES crittografare una password con se stesso è più sicuro di SHA1?

Questa non è davvero una domanda pratica, ma più una questione di curiosità. Ho sentito un professore CS raccomandare di passare da password md5ing non a SHA1, ma ad AES che crittografa la password usando se stessa come chiave. Qualcuno ha qualche idea sul fatto che questo sia effettivamente più o meno sicuro?

Alcuni pensieri in merito:

  • SHA1 è unidirezionale, che dovrebbe renderlo più sicuro di una funzione che preserva i dati.
  • D'altra parte, l'hacker non può trarre vantaggio dalla natura decifrabile di AES perché non conosce ancora la password.
  • A meno che non lo indovini. Ma poi sarebbe indifferente da come l'ho crittografato.
  • Poiché sai che la password AES viene decrittografata quando la chiave di decrittazione corrisponde all'output, potrebbe essere forzata sul computer dell'hacker.
  • Ma l'hacker non sa come sia crittografato, quindi non ci proverà.
  • Ma l'hacker avrebbe potuto ottenere anche il codice di crittografia, nel qual caso è semplicemente una questione di quali dati impiegano più tempo per la forza bruta.
  • La maggior parte dei siti Web utilizza md5 o sha1 (giusto?), Quindi le tabelle di ricerca per questi hash sarebbero molto più diffuse rispetto al metodo AES. Rendendo così il metodo AES più sicuro.
  • Ma se saliamo entrambi i metodi, diventerebbero ugualmente immuni alle tabelle di ricerca.

Alcuni punti comuni nelle risposte e contrappunti:

La crittografia AES non è progettata per resistere alle collisioni e quindi probabilmente avrà più collisioni per la stessa lunghezza della stringa hash.

Se stiamo usando un sale più lungo, la password crittografata sarà più lunga di un hash SHA1. Questo potrebbe essere sufficiente per portare le collisioni a un livello comparabile - o forse no.

La crittografia AES indica quanto tempo è stata la password, entro 16 byte.

Possiamo aggiungere al metodo AES: dopo averlo crittografato, eseguiamo il pad o il trim a una lunghezza ragionevole (che è più lunga di quella di SHA1 per evitare collisioni).

30
skier88

Risposta breve: cattiva idea, non farlo.


Risposta più lunga: il punto dell'esercizio è memorizzare qualcosa che consenta al server di verifica una determinata password, ma non consente di ricostruire la password; quest'ultima proprietà è auspicabile, in modo che le conseguenze di un accesso in lettura illegittimo al database del server da parte di un utente malintenzionato rimangano limitate.

Quindi vogliamo una trasformazione deterministica unidirezionale che converte una determinata password nel valore di verifica. La trasformazione deve essere:

  • configurabile lentamente, in modo da contrastare gli attacchi del dizionario;
  • distinto per ogni istanza, per prevenire attacchi di dizionario paralleli, comprese le tabelle precalcolate (ecco di cosa parlano i sali).

Una singola chiamata di MD5 o SHA-1 non riesce su entrambi gli account, poiché queste funzioni sono molto veloci e non salate. La lentezza può essere fatta annidando molte invocazioni (migliaia, forse milioni) e il sale può essere iniettato "da qualche parte", anche se ci sono modi buoni e cattivi per farlo. PBKDF2 è una trasformazione standard che fa proprio questo, e non è male (anche se bcrypt dovrebbe essere in qualche modo preferibile ).

Tuttavia, MD5 e SHA-1 fanno almeno una cosa giusta: erano progettati per essere a senso unico. È difficile da fare; non è nemmeno teoricamente provato che funzioni a senso unico possano davvero esistere affatto. I crittografi di tutto il mondo sono attualmente coinvolti in una competizione per progettare una nuova, migliore funzione hash unidirezionale.

Quindi, ciò che il tuo professore sembra raccomandare è di sostituire una funzione progettata per il senso unico, con una funzione che era non progettata per il senso unico. Non corregge nulla di lentezza e salatura, ma rimuove l'unica cosa positiva di MD5 e SHA-1. Inoltre, AES è noto per essere relativamente debole per quanto riguarda gli attacchi con chiave correlata - non è un problema fintanto che AES viene utilizzato per quello che doveva essere, cioè la crittografia, ma diventa un elemento importante problema quando viene sovvertito in un blocco predefinito per una funzione hash unidirezionale. Sembra possibile creare una funzione hash sicura riutilizzando parti del progetto AES, ma richiede una sostanziale rielaborazione (vedere ad esempio Whirlpool e ECHO ).

Quindi non utilizzare uno schema di hashing delle password basato su AES fatto in casa; del resto, non usare nulla di "fatto in casa": è una ricetta per il disastro. La sicurezza non può essere testata; l'unico modo noto per creare un algoritmo sicuro è che centinaia di crittografi esperti lo guardino da vicino per alcuni anni. Non puoi farlo da solo. Persino un crittografo solitario non lo rischierà.

Invece, usa bcrypt. Anche PBKDF2 non è male.

32
Thomas Pornin

La maggior parte dei siti Web utilizzava md5 o sha1 (giusto?), Quindi questo è ciò che un hacker si aspetterebbe. Rendendo così il metodo AES più sicuro.

Anche se la maggior parte dei siti Web utilizza MD5 o SHA1, il passaggio ad AES solo per il motivo che di solito non viene utilizzato lì non lo renderebbe più sicuro - questo è solo sicurezza per oscurità , che di solito non contribuisce efficacemente ad aumentare la sicurezza; sarà molto più sicuro usare un buon algoritmo (che è ben testato per lo scopo dato) e documentarlo pubblicamente, piuttosto che usare un algoritmo di cui non si può essere sicuri se è buono, e non dire che si è usandolo.

Al momento posso pensare ai seguenti possibili svantaggi quando si utilizza AES o qualsiasi altro algoritmo di crittografia come questo:

  1. Gli algoritmi di crittografia di solito non sono progettati per evitare collisioni: come sottolineato nei commenti seguenti, potrebbe non essere un problema a causa del comportamento pseudo-casuale previsto della crittografia a blocchi. Tuttavia, stai usando un algoritmo di crittografia per qualcosa per cui non è stato progettato.
  2. È immaginabile che ci siano attacchi agli algoritmi di crittografia che sono molto più facili da fare se si sa che il testo e la password chiari sono effettivamente la stessa cosa (se il fatto sull'algoritmo che stai usando in qualche modo perde, il che non è così improbabile dato che è ad esempio discusso qui).
  3. Gli algoritmi di crittografia producono dati che in molti casi variano con la lunghezza del testo in chiaro. Ciò significa che il testo cifrato contiene informazioni sulla durata della password. Nel caso di AES questo è un multiplo di 16 byte per quanto posso dire ; i valori di hash, d'altra parte, hanno una dimensione fissa (ad esempio 160 bit/20 byte per SHA1); il che significa che un potenziale hacker ha la possibilità di ottenere più informazioni da un testo crittografato che da un valore di hash.
  4. In crittografia di solito è sempre meno sicuro anche cucinare qualcosa da soli (che successivamente viene probabilmente anche usato solo da te) rispetto all'utilizzo di qualcosa che è ben testato e fuori nella comunità già da molto tempo (nel senso che aveva il tempo di essere ispezionato a fondo da un certo numero di crittografi).
  5. Vuoi assicurarti che l'algoritmo di hashing della password sia lento, in modo che i potenziali aggressori siano ostacolati a forzare la loro forza nel tuo sistema. Un modo per ottenere ciò è ad esempio eseguire in modo iterativo l'hash in più round, come ad esempio PKBDF2. Per maggiori dettagli, vedi http://security.blogoverflow.com/2013/09/about-secure-password-hashing/
17
codeling

Un problema immediato che vedo con questo approccio è la lunghezza fissa della chiave di AES. Usando AES-128, uno sarebbe limitato a 16 byte della password. Che dire delle password più lunghe o delle passphrase lunghe?

Per adattarsi a qualsiasi lunghezza di password è necessario disporre di una funzione hash, quindi tornare al punto iniziale.

Si noti che esistono modi ben studiati e sicuri di trasformare un codice a blocchi in una funzione hash, le cosiddette modalità PGV come Davies-Meyer, Matyas-Meyer-Oseas o Miyaguchi-Preneel.

(*) Per una definizione appropriata di "sicuro".

7
Krystian

Tuttavia, considera questo:

Entro nel tuo sito e ottengo abbastanza accesso per notare che hai le chiavi AES configurate per il tuo sistema, l'unica cosa che sembra "crittografata" sono le tue password ... indovina cosa farò.

Li terrei hash, lascia molto meno spazio per raschiare facilmente l'intero database delle password.

Inoltre, come proprietario del sito, NON VOGLIO in primo luogo la possibilità di decrittografare le password dei miei utenti, altrimenti l'opzione per "recuperare le password" diventa una possibile caratteristica che i superiori possono chiedere, e tecnicamente, noi può farlo perché il sistema sottostante viene creato utilizzando un sistema di crittografia anziché un sistema di hashing (un motivo zoppo ma gli sviluppatori di software gestiscono richieste come queste).

Principalmente: quando si tratta di sicurezza, non cercare di fare qualcosa di stravagante e fuori dagli schemi, probabilmente ti scriverai un enorme buco di sicurezza perché non sarai in grado di mettere la quantità di ricerca di un team di persone che lavora su un algoritmo per uno scopo specifico dovrebbe.

5
StrangeWill

La risposta corretta è: non importa affatto.

Nel caso delle password, l'unico attacco pratico è provare un elenco di password fino a quando non trovi quella giusta con la forza bruta. Nessuno proverà ad attaccare SHA1 né AES direttamente per farlo. Anche nell'attuale punto di ricerca, attaccare SHA1 sarebbe diecimila volte più facile di AES, entrambi sono ancora completamente impossibili (per invertire gli hash delle password perché le collisioni non contano qui). E poiché un ricercatore trova un altro modo per attaccare l'altro algoritmo, le probabilità potrebbero essere invertite l'anno prossimo.

Ciò che può importare è la velocità con cui si ottiene l'hash/si crittografa la password. Ma se ad es. SHA1 è più veloce e vuoi che sia più lento (per respingere gli attacchi di forza bruta), puoi semplicemente eseguire l'hash più volte.

Ciò che un hacker "si aspetta" non è così rilevante, rendere qualcosa di "inaspettato" è solo l'oscurità. È come dire "Inverso tutte le lettere della password, ora è più sicuro". Non lo sarà. Se l'hacker può accedere al database delle password, come puoi essere sicuro di non avere accesso alla tua funzione di derivazione dell'hash della password?

Un difetto quando si "cripta una password con se stesso": la lunghezza del testo cifrato potrebbe dare all'aggressore un indizio sulla lunghezza della password. È terribile.

In ogni caso, dovresti salare la password, preferibilmente con qualcosa di unico per l'utente.

4
Kosta

Esistono MAC (Message Authentication Codes) costruiti con cifrature a blocchi; il più noto è probabilmente CBC-MAC . Ha problemi rispetto a un hash-mac, in particolare:

Dato un codice di blocco sicuro, CBC-MAC è sicuro per i messaggi di lunghezza fissa. Tuttavia, di per sé, non è sicuro per i messaggi di lunghezza variabile. Un utente malintenzionato che conosce le coppie di tag messaggio (ovvero CBC-MAC) corrette (m, t) e (m ', t') può generare un terzo messaggio m '' il cui CBC-MAC sarà anche t '.

[...]

Questo problema non può essere risolto aggiungendo un blocco di dimensioni del messaggio (ad esempio, con il rafforzamento di Merkle-Damgård) e quindi si consiglia di utilizzare una modalità di funzionamento diversa, ad esempio CMAC per proteggere l'integrità dei messaggi di lunghezza variabile.

La risposta più breve: la sicurezza di un MAC costruito da un codice a blocchi dipende da come lo costruisci. Una costruzione ingenua avrà quasi certamente difetti significativi.

4
Nick Johnson

Il fatto che tu abbia progettato un algoritmo insolito non lo rende sicuro. Gli algoritmi "autocostruiti" sono pericolosi, perché nessuno ha effettuato analisi crittografiche di essi.

Come ha scritto @Thomas Pornin sopra, AES non è stato progettato per resistere alle collisioni. Inoltre, AES è relativamente veloce, il che semplifica gli attacchi.

SHA1 è progettato per resistere alle collisioni, ma SHA1 è anche progettato per essere molto veloce, perché il suo scopo è quello di generare in breve tempo hash di grandi volumi di dati o file. Il suo scopo non è prevenire attacchi alle password con hash.

Se si desidera generare un hash della password resistente a diversi tipi di attacchi, considerare l'estensione della password. A seconda del tuo stack tecnologico e delle librerie disponibili considera bcrypt, scrypt, argon2.

1
mentallurg