La soluzione che descrivi è, in realtà, hashing.
Considera la funzione di hash MD5 . Funziona iniziando con un valore fisso convenzionale ("IV") di lunghezza 128 bit. Quindi, per ogni blocco di dati di input a 512 bit, viene calcolata una funzione di compressione , che accetta come input lo stato corrente a 128 bit e il blocco di messaggi a 512 bit e emette il successivo 128 bit stato. Se osservi come funziona la funzione di compressione MD5, vedrai che è simile a un codice a blocchi (uno schema generalizzato Feistel con quattro parole secondarie) in cui il blocco di messaggi a 512 bit viene utilizzato come chiave. Quindi MD5 funziona davvero come lo descrivi: crittografa un valore fisso, con la password come chiave. Se il valore fisso è specifico per utente, allora è una sorta di "sale" (e questo è un bene per l'hashing della password).
Quindi la tua domanda è: non possiamo costruire una funzione hash da un codice a blocchi? E la risposta è: sì, ma richiede una certa attenzione. Un codice a blocchi tipico come AES è progettato per la crittografia e la sua sicurezza è stata analizzata in quel contesto. Quando si trasforma un cifrario a blocchi in una funzione di hash come descritto sopra, si sta facendo affidamento sul fatto che il codice a blocchi sia robusto in modi che non sono stati esplorati a fondo - è necessario che il codice sia resistente a relatedkeykey attacks , che non sono un problema per quanto riguarda la crittografia, ma possono essere fatali per una funzione hash. Ad esempio, l'AES è noto per essere un po 'debole per quanto riguarda le chiavi correlate, quindi usarlo "così com'è" in una funzione di hash non è necessariamente una buona idea.
Whirlpool e Skein sono due funzioni di hash che riutilizzano un codice a blocchi - in entrambi i casi, un codice a blocchi specializzato, ottimizzato per la resistenza in quella specifica situazione.
Indipendentemente dai dettagli del design della funzione hash, il any sistema di memorizzazione delle password ha una grossa, evidente debolezza, che è che memorizza la password o, almeno, un token di verifica della password (qualcosa che può essere utilizzato per decidere se una determinata password è corretta o meno). Le password provengono dal cervello degli esseri umani; loro non possono essere forti. È altamente possibile enumerare la maggior parte delle potenziali password.
È inevitabile che un server che verifica le password contenga abbastanza informazioni per, per esempio, verificare le password. Pertanto, se un utente malintenzionato può ottenere un dump del disco del server, guadagna anche quel potere e può provare le password "a casa". Questo è un attacco dizionario offline . L'unica difesa conosciuta (probabilmente, l'unica possibile difesa) consiste nel rendere ogni verifica della password intrinsecamente lenta, preferibilmente in un modo configurabile. Questo è il punto di bcrypt : l'hashing della password utilizza milioni di operazioni elementari, senza alcuna conoscenza scorciatoia, in modo che l'attaccante dovrà pagare un prezzo alto per ogni tentativo.
Una funzione di hash fatta in casa, creata da un codice a blocchi, non funzionerà, a meno che tu non la definisca per usare non la una crittografia, ma un milione di crittografie successive. Sarebbe comunque fatto in casa (cioè molto male nella crittografia, non si fida dei design fatti in casa), ma almeno non sarebbe così terribilmente debole per quanto riguarda gli attacchi di dizionario.