Puoi utilizzare RSA2048 per le password hash?

Il tuo schema di hashing proposto non ha alcun reale vantaggio sugli schemi esistenti e alcuni potenziali aspetti negativi.

Uno schema di hashing delle password deve avere tre proprietà chiave :

• deve essere a senso unico: non c'è modo di recuperare la password dall'hash, l'unico modo per trovare la password è indovinarlo;
• deve essere salato: ogni hash incorpora un valore univoco in modo che un utente malintenzionato non possa riutilizzare gli stessi calcoli per attaccare molti hash;
• deve essere costoso (per lo meno lento): il calcolo di un hash deve richiedere risorse significative, quindi gli attacchi di massa richiedono un enorme investimento in hardware.

Il tuo schema proposto è a senso unico - ma il primo passo di hashing con MD5 è sufficiente per questo. (Per inciso, sebbene MD5 non abbia punti deboli noti per questo caso d'uso, è sufficientemente rotto che è vivamente raccomandato di non utilizzarlo affatto, ma potresti semplicemente sostituire SHA-256 e la tua domanda rimarrà valida, così come la mia risposta.) L'esecuzione di un'operazione RSA in alto non migliora questo aspetto.

Lo schema proposto è salato, utilizzando una chiave diversa per ciascun hash. Va bene. Ma c'è un modo più semplice per eseguire la salatura: essenzialmente si prende l'hash (password + sale) invece dell'hash (password). (Il diavolo è nei dettagli ma rimarrò fedele al riepilogo di alto livello qui.) Quindi sappiamo già come farlo.

Il tuo schema proposto non è costoso. La convenienza deve essere sintonizzabile, per raggiungere il massimo utilizzo di risorse che è barable sul server legittimo che verifica la password e tenere il passo con l'evoluzione tecnologica (ad esempio aumentare il numero di iterazioni da 10 ⁵ a 10 ⁶ ogni 5 anni dato che i computer sono ~ 10 volte più veloci). Un modo semplice per farlo è quello di prendere un hash veloce e iterarlo, il che richiede un lungo calcolo sequenziale; questo è ciò che fa PBKDF2 . Schemi più complessi cercano di essere ottimali sull'hardware del PC e meno buoni su es. GPU o FPGA; vedi Gli esperti di sicurezza consigliano bcrypt per l'archiviazione della password? . Non è chiaro in che modo la tua proposta potrebbe essere ottimizzata per quanto riguarda la convenienza: usa chiavi RSA più grandi?

Un grosso difetto potenziale nella tua proposta è che l'operazione core RSA (exponentiation modulare) non ha buone proprietà di sicurezza se usata direttamente, perché è soggetta a relazioni algebriche come x ^e · y ^e = ( x · y ) ^e . Ecco perché la "crittografia RSA" non è un semplice esponenziazione , ma aggiunge un po 'di padding ai dati; OAEP è lo standard moderno. Non è possibile utilizzare OAEP perché è non deterministico: eseguirlo due volte sullo stesso input produce diversi ciphertexts. È probabile che una versione deratizzata di OAEP possa funzionare, o anche uno schema più semplice dato che sei in un caso molto speciale in cui nessun testo cifrato verrà mai decifrato, il che significa che molti attacchi a schemi di crittografia non sono applicabili.

Nota che non puoi andare fino a non aggiungere nessun padding, non senza ulteriori vincoli: y = x e mod n assolutamente necessario avvolgere modulo n , altrimenti x può essere calcolato da y semplicemente prendendo e la radice nei reali. Come specificato nella domanda, e non è vincolato, consentendo la scelta comune di e = 3. Poiché x è un numero a 128 bit ( 256-bit se si usa SHA-256 invece di MD5) e n è un numero di 2048 bit, x e non si chiuderà, quindi x può essere recuperato banalmente da y . C'è ancora la one-wayness dell'hash, ma si perde la salatura che è stata fornita solo dal gradino RSA. Esistono facili soluzioni a questo problema, ovviamente: richiede un e sufficientemente ampio e include un valore salt nei dati con hash. Ma se devi fare affidamento sul resto del design, perché dovresti inserire RSA nel mix? Questo illustra il rischio di aggiungere altro materiale a un algoritmo crittografico: puoi renderlo più debole anche se pensavi di aggiungere una funzione di sicurezza.

Per riassumere:

• La tua proposta non ha una proprietà chiave delle funzioni di hashing della password: expensiveness.
• Potrebbe essere possibile modificare questa proposta per avere questa proprietà, ma non è chiaro come.
• Si aggiunge un potenziale vettore di attacco (relazioni algebriche); esistono difese ma non è chiaro cosa stai ottenendo.

Assuming I'm working on an environment that currently uses MD5 to hash passwords, and I want to switch to something more secure.

Se questa è una domanda pratica, merita una risposta pratica:

Non inventare schemi di archiviazione password personali. Esegui in base alle migliori pratiche .

Non c'è alcun vantaggio per il tuo schema rispetto all'utilizzo delle opzioni standard (pbkdf / bcrypt / scrypt / argon2). Ci sono molti potenziali svantaggi nella sicurezza, oltre a bug generali nell'implementazione (dal momento che stai costruendo tu stesso invece di usare una libreria di uso comune). L'implementazione di questo in un ambiente di produzione confina con la negligenza professionale.

Riguardo alla sua sicurezza: per lo meno si soffre che sia facile parallelizzarlo, quindi un attaccante che ha ottenuto un dump del database può fare il vecchio "spin up un gruppo di istanze ec2" per attaccare i tuoi hash. Questo è il punto alla base di bcypt, ma non sembra che l'abbia affrontato affatto.