AES crittografa una password con se stessa più sicura di SHA1?

Risposta breve: cattiva idea, non farlo.

Risposta più lunga: il punto dell'esercitazione consiste nel memorizzare qualcosa che permetta al server di verificare una determinata password, ma non gli consente di ricostruire la password; quest'ultima proprietà è auspicabile, quindi le conseguenze di un accesso illegittimo in lettura al database del server da parte di un utente malintenzionato rimangono limitate.

Quindi vogliamo una trasformazione deterministica a una via che converta una determinata password nel valore di verifica. La trasformazione deve essere:

• configurabile lento, in modo da contrastare gli attacchi del dizionario;
• distinto per ogni istanza, per impedire attacchi di dizionari paralleli, incluse le tabelle precalcolate (ecco cosa sono i sali).

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

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

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

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

Invece, usa bcrypt. Anche PBKDF2 non è male.

Most websites used md5 or sha1 (right?), so this is what a hacker would be expecting. Thus making the AES method more secure.

Anche se la maggior parte dei siti web utilizza MD5 o SHA1, passare a AES solo per il motivo che in genere non viene utilizzato non lo renderebbe più sicuro - è solo sicurezza per oscurità , che di solito non contribuisce in modo efficace ad aumentare la sicurezza; sarà molto più sicuro usare un buon algoritmo (che è ben testato per lo scopo prefissato) e documentarlo pubblicamente, piuttosto che usare un algoritmo di cui non puoi essere sicuro se è buono, e non dire che sei usandolo.

Al momento riesco a pensare ai seguenti possibili svantaggi quando utilizzo AES o qualsiasi altro algoritmo di crittografia come questo:

1. Gli algoritmi di crittografia di solito non sono progettati per evitare collisioni: come indicato nei commenti seguenti, potrebbe non essere un problema a causa dell'atteso comportamento pseudo-casuale del cifrario a blocchi. Tuttavia, stai utilizzando un algoritmo di crittografia per qualcosa per il quale 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 in chiaro sono in realtà uno e lo stesso (se si tratta dell'algoritmo che si sta utilizzando in qualche modo una perdita, che non è improbabile dato che è per 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); significa che un potenziale hacker ha la possibilità di ottenere più informazioni da un testo crittografato piuttosto che da un valore hash.
4. In crittografia di solito è sempre meno sicuro anche cucinare qualcosa da te (che in seguito probabilmente è anche usato solo da te) piuttosto che usare qualcosa che è già ben collaudato e fuori nella comunità già da molto tempo (il che significa che ha avuto il tempo di essere accuratamente controllato da un numero di cryptanalysts).
5. Volete assicurarvi che l'algoritmo di hash della password sia lento, in modo che i potenziali attaccanti vengano ostacolati alla forza bruta nel sistema. Un modo per ottenere ciò è ad esempio eseguire iterativamente l'hashing in più round, come ad esempio fa PKBDF2. Per maggiori dettagli, vedi link

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

Per contenere la lunghezza della password, è necessaria una funzione hash, quindi torna al punto iniziale.

Si noti che esistono modi ben studiati e sicuri per trasformare un cifrario 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".

Tuttavia, considera questo:

Mi inserisco nel tuo sito e ricevo abbastanza accesso per notare che hai le chiavi AES configurate per il tuo sistema, solo le cose che sembrano "crittografate" sono le tue password ... indovina cosa ho intenzione di fare.

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

Inoltre, come proprietario del sito, NON voglio la possibilità di decrittografare le password dei miei utenti, in primo luogo, altrimenti l'opzione di "recuperare le password" diventa una possibile caratteristica che possono essere richieste dai più alti, e tecnicamente, possiamo farlo perché il sistema sottostante è costruito usando un sistema di crittografia invece di un sistema di hashing (una ragione per nulla, ma gli sviluppatori di software si occupano di richieste come queste).

Principalmente: quando si tratta di sicurezza, non provare a fare qualcosa di stravagante e fuori dalla scatola, probabilmente ti scriverò un enorme buco di sicurezza perché non sarai in grado di mettere la quantità di ricerca di un gruppo di persone che lavorano su un algoritmo per uno scopo specifico dovrebbe.

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

Given a secure block cipher, CBC-MAC is secure for fixed-length messages. However, by itself, it is not secure for variable-length messages. An attacker who knows the correct message-tag (i.e. CBC-MAC) pairs (m, t) and (m', t') can generate a third message m'' whose CBC-MAC will also be t'.

[...]

This problem cannot be solved by adding a message-size block (e.g., with Merkle-Damgård strengthening) and thus it is recommended to use a different mode of operation, for example, CMAC to protect integrity of variable-length messages.

La risposta più breve: la sicurezza di un MAC generato da un codice a blocchi dipende da come lo si costruisce. Una costruzione ingenua avrà quasi sicuramente dei difetti significativi.

La risposta corretta è: non ha alcuna importanza.

Nel caso delle password, l'unico attacco pratico è provare un elenco di password finché non trovi quello giusto con la forza bruta. Nessuno proverà ad attaccare direttamente SHA1 né AES 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 come ricercatore trova un altro modo per attaccare l'altro algoritmo, le probabilità potrebbero essere invertite l'anno prossimo.

Ciò che potrebbe importare è la velocità con cui ottieni il tuo hash / crittografare la tua password. Ma se per es. SHA1 è più veloce e vuoi che sia più lento (per respingere gli attacchi a forza bruta), puoi semplicemente eseguire l'hash più volte.

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

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

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

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

Come @Thomas Pornin ha scritto 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 hash di grandi volumi di dati o file in breve tempo. Il suo scopo non è quello di prevenire attacchi alle password con hash.

Se vuoi generare un hash per la password che è resistente a diversi tipi di attacchi, considera l'allungamento della password. A seconda del tuo stack tecnologico e delle tue librerie disponibili, considera bcrypt, scrypt, argon2 .