Quanto è sicuro questo approccio di autenticazione rispetto all'hash?

Is there any drawback by this approach compared to the usual password salting and hashing?

Di solito non vi è alcun motivo per inventare il proprio metodo di hashing della password, a patto che quelli esistenti siano adatti al proprio scopo. È difficile ottenerlo meglio rispetto alla scelta di un metodo noto e consolidato. Ma è facile sbagliare.

La forza degli attuali metodi di hashing della password deriva da molteplici aspetti:

• La funzione irreversibile per rendere l'input di calcolo dall'output è impossibile
  Questo viene fatto usando le potenti funzioni hash crittografiche.
• convalida lenta di una singola password rallenta gli attacchi a forza bruta
  Questo avviene creando delle funzioni di hash lente e persino cercando di mantenere queste funzioni di hash lente anche se l'attaccante ha costruito hardware specificamente per risolvere il problema di velocità.
• output multipli (storage) per lo stesso input (password) per rendere il pre-computing non fattibile
  Ciò viene fatto usando un salt random per ogni hashing. I sali vengono prelevati casualmente da un set abbastanza grande in modo che il pre-calcolo e la memorizzazione dei risultati di tutti gli input possibili diventano impossibili nel tempo e nella memoria.

Vediamo come la tua idea si confronta con questo approccio consolidato:

• irreversibilità
  Questo è probabilmente dato finchè la funzione di derivazione della chiave (per ottenere la chiave di crittografia dalla password) fornisce questa proprietà. Solo, non c'è nulla di noto su questa funzione, quindi presumo che tu non abbia considerato che questa funzione potrebbe aver bisogno di avere proprietà speciali.
• convalida lenta per rallentare la forza bruta
  Nessun aspetto del tuo algoritmo si preoccupa di rallentare la forza bruta e nessun aspetto è intrinsecamente lento. Questo potrebbe essere fatto di nuovo all'interno della funzione di derivazione della chiave, ma ancora una volta non hai bisogno di una funzione appositamente costruita per questo.
• output multipli (storage) per lo stesso input (password)
  Ciò è probabilmente garantito dall'avere una IV casuale per ogni crittografia.

In sintesi, direi che la sicurezza del tuo approccio dipende dalla scelta della funzione di derivazione della chiave, ovvero che il KDF è un hash lento e unidirezionale. Dal momento che non hai richiesto che il tuo KDF si comportasse in quel modo, considererei la tua idea una cattiva idea. Anche se richiedi che il KDF sia strong e abbastanza lento potrebbero esserci altri problemi dell'algoritmo che non ho riconosciuto nel breve tempo.

Ancora una volta, non inventare il tuo se esiste un metodo di lavoro che risolve il tuo problema. Di solito peggiora, non meglio.

Sì, c'è un inconveniente, anche se è "solo" pratico (eppure percepisco il tasso di collisione (la password errata ha derivato una chiave che decrittografa in qualcosa che segue la sintassi che ci si aspetta) per essere più alta nello schema, ma Non l'ho fatto per la matematica, perché l'altro inconveniente è prevalente).

Ci sono molte più parti in movimento nel tuo schema rispetto al solito hashing della password. Ciò significa che più cose possono andare storte, specialmente se la implementi tu stesso. L'utilizzo di una funzione di hash è facile rispetto all'utilizzo di un codice a blocchi.

Le implementazioni e gli esempi di hashing sicuro per le password sono facilmente disponibili mentre un'implementazione del tuo schema sarebbe un po 'speciale, offrendo molti più insidie nell'implementazione.

Inoltre, ciò consentirebbe agli aggressori che hanno il database di violare le password degli utenti, forse altrettanto facilmente. A seconda della funzione di hash e di salting che usi, AES, che è per lo più implementato nell'hardware, è veloce in confronto - e solo un blocco sarebbe un buon indicatore della decrittazione corretta.