Questo schema di autenticazione è sicuro e protegge le password / gli hash dell'utente?

Guida all'autenticazione

OWASP ha un Scheda trucchi per l'archiviazione delle password con alcune indicazioni eccellenti sugli schemi di hashing e la teoria di base su come mantengono le password al sicuro. C'è anche una sezione che tratta il pezzo che ti sembra più preoccupato: proteggere l'account di un utente in caso di un eventuale compromesso.

Per ulteriori informazioni, Troy Hunt ha un articolo - Password evolute: autenticazione Guida per l'era moderna - che riassume il recente aggiornamento delle pubblicazioni governative sull'argomento, tra cui NIST Special Publication 800-63 - Digital Identity Guidelines .

Non reinventare la ruota

Sembra che tu stia cercando di inventare qualcosa di completamente nuovo. Consiglierei di attenersi a cose che sono state provate. Le risorse di cui sopra dovrebbero aiutare in questo.

Non è che io veda qualcosa di intrinsecamente sbagliato nel tuo suggerimento. Personalmente non sono un matematico o un crittografo, quindi non pretenderei di possedere l'esperienza per certificare il tuo schema come sicuro. Sembra proprio che tu stia facendo un sacco di lavoro extra, per trovare e implementare una soluzione non standard, che alla fine potrebbe renderla più vulnerabile.

Gli schemi non standard hanno anche lo svantaggio di essere più difficili da mantenere man mano che le persone si accostano a chi non è a conoscenza dei dettagli di come è stato costruito il tuo schema, quali fattori lo rendono sicuro e possono apportare modifiche che bucano la tua sicurezza modello.

Infine, come sviluppatori di software, di solito non siamo pagati per fare ricerche sulla sicurezza e inventare nuovi schemi di crittografia o autenticazione. I nostri clienti o datori di lavoro ci pagano per apportare miglioramenti misurabili nello stato dell'arte per il loro dominio specifico. Questa è solo la mia opinione, ma quando si tratta di implementare l'autenticazione, sarebbe quasi negligente non seguire le indicazioni fornite dalle organizzazioni come NIST, OWASP e i team di sicurezza dei fornitori che producono il software e le librerie che usiamo (Microsoft , IBM, Oracle, ecc.)

Perché funzioni, il server deve memorizzare la chiave pubblica generata dalla password (ad esempio "PK.public"). Senza questo, non c'è modo per il server di verificare la firma.

Quindi ora, invece di una tabella piena di hash, hai una tabella piena di chiavi pubbliche derivate dalle password. Un attaccante che ha messo le mani su quel tavolo potrebbe semplicemente fare un attacco di forza bruta su di esso, ripetendo i passaggi 2 e 3 per varie password fino a quando non ottiene una corrispondenza. Invece di memorizzare un hash, stai memorizzando qualcosa derivato da un hash. Nella migliore delle ipotesi, è equivalente alla semplice memorizzazione dell'hash.

Quindi tutto ciò che hai fatto qui è aggiungere molta complessità aggiungendo qualche fantasia crypto assimetrica, senza ottenere alcun miglioramento della sicurezza. Dal momento che la complessità è il tuo nemico, questa è una perdita netta.