Imposta un hash, accedi con una password?

Sono d'accordo con @Xiong Chiamiov, non c'è nulla di intrinsecamente sbagliato in questo approccio.

D'altra parte, non offre molti vantaggi all'approccio standard (tutto l'hashing viene eseguito lato server), e c'è sicuramente qualche rischio nel rivelare l'hash a entità non fidate.

Se il client originale non è affidabile, questo ovviamente non fa nulla, in quanto il client può semplicemente registrare la password inserita.

Se la connessione originale tra client e server non è affidabile, questo aiuta solo un po '. Un uomo passivo nel mezzo ha ancora guadagnato l'hash e può provare a decifrarlo. Un uomo attivo nel mezzo potrebbe cambiare l'hash per ottenere l'accesso, o potrebbe cambiare la risposta al criterio di hashing per forzare un hash debole a ottenere la password (o forzare l'hashing del tutto o semplicemente iniettare Javascript o simili per leggere il password inserita).

Quindi l'unico caso d'uso ragionevole è la mitigazione limitata contro un uomo passivo nel mezzo alla registrazione iniziale. Se dovessi incontrarlo, verificherei che l'iscrizione iniziale è davvero non sicura, e se non c'è un approccio più ragionevole rispetto a rivelare l'hash.

Il problema che emerge di solito quando si parla di hashing sul lato client è che un utente malintenzionato che ha violato il il database può semplicemente passare gli hash al server per autenticarsi. Tuttavia, questo schema non consente l'uso dell'hash per l'autenticazione, solo la creazione iniziale dell'account, quindi non cade in quella trappola.

Ho visto questo genere di cose usate nel contesto dei file di Apache htpasswd; gli utenti generano un digest e lo inviano su un canale relativamente insicuro (ad es. email) all'amministratore di sistema, che lo aggiunge alla configurazione del server. Mentre un sistema che coinvolge l'autenticazione di base o digest non è l'apice della sicurezza del computer, questo dimostra che non è un approccio completamente nuovo e ha avuto almeno un po 'di attenzione.

Vista la descrizione come la metti, non vedo alcun problema ovvio. Ovviamente ci possono essere problemi di implementazione, come un bug che consente di alimentare l'hash invece della password per l'autenticazione. E dal momento che la connessione iniziale non è attendibile, è probabilmente un po 'più facile per un utente malintenzionato ottenere un hash della password (che può quindi provare a crack o generare una collisione per). Ma quelli non sono problemi con lo schema stesso, o problemi principali.

Due lendini

possibly after requesting the hashing policy - salt, which hash function, etc - from the server

Non sono chiaro se questo meccanismo utilizza un sale per utente o un sale globale. Se utilizza un sale globale, è vulnerabile a un attacco arcobaleno.

Server stores "99476bb..." in the database as the password hash for that user.

Poiché l'hash è stato generato al di fuori del server, non è possibile per il server applicare regole di complessità o lunghezza della password. Dovrebbero essere applicati dall'app. Inoltre, non c'è modo di verificare il riutilizzo della password.

Non penso che lo schema proposto aggiunga ulteriori rischi, ma non sono sicuro che ne riduca effettivamente nessuno. Sembra che manchi un po 'di informazioni cruciali. In base a questo schema, come si fa inizialmente a controllare il cliente per sapere che è chi pensa di essere prima di consentire loro di impostare l'hash? Questa è la vera sfida: esistono diversi modi in cui è possibile comunicare una password impostata / modificata sul filo per prevenire gli attacchi MitM, ma quando si desidera consentire l'impostazione remota di qualsiasi forma di processo di autenticazione, il problema è nel controllare il utente remoto.

Inoltre, non sono convinto che la politica che ti sta costringendo a considerare questa alternativa sia di alcun beneficio reale se non quella di far sentire meglio gli auditor. Ammettiamolo, se il tuo rischio è la raccolta di informazioni sulla password dalla memoria del sistema operativo, il vero problema sono i controlli adeguati sull'accesso al sistema operativo e quella memoria, non ciò che è nella memoria. Se qualcuno ha quel livello di accesso, è probabile che possa compromettere comunque il processo di autenticazione di base. Tutta la politica sta davvero aggiungendo complessità, che probabilmente creerà altri problemi.