Verifica l'hash della password con nonce quando la password è già stata sottoposta a hashing sul server?

Am I right to say that this won't work if the password is not stored in plain text on the server? I fail to see how the server could verify the hash if the password is already hashed (with salt and pepper) on the server.

Questo schema richiede che la password sia archiviata in chiaro. Molto male.

Can this scheme be extended to work with hashed passwords somehow?

Sono sicuro che può, ma non ce n'è bisogno. Lo schema a cui hai fatto riferimento è il protocollo di autenticazione del digest HTTP . È stato scritto in un giorno in cui SSL era considerato costoso da implementare in molti sistemi. Authn di digest ha fornito un modo per accedere tramite canali di testo libero senza esporre la password. Non c'è assolutamente alcuna ragione per farlo più. SSL ora è effettivamente gratuito.

In generale, il rischio di memorizzare le password sul server è considerato superiore al vantaggio di avere il server che non ha la password in memoria per un breve periodo di tempo (il tempo dalla ricezione del messaggio della password fino all'inizio dell'ashing e il cleart- la memoria della password del testo può essere cancellata).

Ci sono alcune situazioni in cui l'hashing lato client può avere senso. Ad esempio, LastPass implementa un meccanismo di autenticazione univoco che implica l'hashing client e server. Lo fanno perché utilizzano la password come base per la creazione della chiave di crittografia e non vogliono che il server conosca la chiave di crittografia. Quindi quello che fanno è:

1. Molti cicli di PBKDF2 sul client per creare una chiave di crittografia strong.
2. Un round di SHA-256 per trasformare la chiave di crittografia in quella che è effettivamente la tua password.
3. Invia password al server. Si noti che le proprietà di SHA-256 rendono computazionalmente impossibile reinserire la password nella chiave di crittografia.
4. Il server esegue l'hashing standard lato server usando PBKDF2 e salt.

Fondamentalmente, il server LastPass esegue l'archiviazione standard delle password ma quello che ottiene come "password" è il risultato dell'hashing sul lato client.

Se stai utilizzando un canale sicuro, ovvero TLS, non è necessario eseguire questo tipo di trucchi.

• Sulla tua prima domanda, sì hai ragione, questo schema richiede che il server abbia accesso alla password in chiaro per poter riprodurre H (nonce + cnonce + password).
• Riguardo alla tua seconda domanda, non riesco a pensare a un modo che non ti aprirà per attacchi di replay. (ma non sono il migliore in questo campo)
• No, l'aggiunta di sali non complica ulteriormente le cose rispetto a quando ha solo l'hash sul lato server. (Se hai la semplice password -che non lo fai, in questo scenario- calcolare l'hash con o senza il sale non è molto diverso)

Can this scheme be extended to work with hashed passwords somehow?

Non questo schema. A causa di come funziona, deve avere la password o qualche equivalente specifico (vedi link per i dettagli) per eseguire alcuni calcoli necessari.

Ovviamente con un approccio ingenuo è possibile modificare lo schema in modo che l'hashing della password venga eseguito sul client in modo che una password hash sul server possa essere utilizzata per il confronto. Ma in questo caso la password originale con hash diventa essenzialmente la nuova password che devi proteggere e la password originale non ha alcuna importanza.

L'idea principale di una password con hash è che si ha un'operazione irreversibile per proteggere la password nel database e che si utilizzerà questa operazione irreversibile sulla password reale prima quando si aggiunge l'hash al database e successivamente quando si confronta il valore inserito password contro la voce del database. Ciò significa che è necessario proteggere il trasporto (cioè utilizzare TLS) o il database (ad esempio, inserire la password e cancellare nel database). Se hai bisogno di uno schema non puoi né proteggere il database, né il trasporto prova la crittografia a chiave pubblica.