Quali pro e contro ci sono per un salt casuale di una volta tra client e server?

In effetti, questo approccio non aiuta contro il furto del database delle password. È più facile capire perché: riguarda solo lo scambio di dati e non ha alcun impatto sul formato del database. Poiché il database memorizza gli hash diretti delle password, è vulnerabile a un attacco di una tabella arcobaleno, rendendo tutte le password tranne l'entropia più elevata.

Questo valore casuale una tantum è un nonce , e tali valori sono infatti comunemente usati nei protocolli di comunicazione per evitare la riproduzione attacchi. Senza un nonce, un utente malintenzionato potrebbe origliare una conversazione legittima e ripetere successivamente la fase di accesso con il server. Potresti trovare tali implementazioni perché è utile con le seguenti ipotesi:

• la comunicazione utilizza HTTP;
• l'utente malintenzionato può ascoltare passivamente tutte le comunicazioni TCP / IP ma non può parlare direttamente con qualsiasi client, solo al server.

Esistono vecchie applicazioni Web progettate in base a queste ipotesi. Aggiungere un nonce alla fase di accesso era un peso significativo per gli aggressori nei giorni in cui erano per lo più studenti universitari annoiati nei campus universitari. Nel mondo odierno di strumenti di rete e dispositivi informatici onnipresenti, supponendo che le connessioni TCP non possano essere dirottate non è realistico. Tale protocollo è vulnerabile a un attacco man-in-the-middle in cui l'attaccante fornisce una risposta DNS falsa al client o dirotta la connessione TCP. L'utilizzo di HTTPS (con l'autenticazione corretta del server, ovvero la corretta convalida del certificato) rende l'aggiunta di un nonce al protocollo di accesso stesso ridondante (HTTPS stesso contiene un nonce in modo che le connessioni non possano essere riprodotte).

Hai ragione nel dire che questo tipo di sale non ritarda il crack delle password se si ottiene un database di password. Le tabelle Rainbow possono essere utilizzate per decifrare facilmente le password.

Dalla mia esperienza (molto limitata), non ho visto alcuna implementazione di tale funzionalità.

Non vedo davvero come impedirebbe una bruteforce attaccata dal front-end dell'applicazione, in quanto un nuovo salt viene generato, aggiunto e confrontato ogni volta, mentre l'hash della password rimane lo stesso.

L'unica cosa che posso pensare è che un attaccante passi una sessione di accesso come un'altra (ogni volta sali diversi), sebbene tali cose possano essere tracciate facilmente attraverso i log.

Note : non ho effettivamente cliccato tra le diapositive e baso la mia risposta sullo schema che hai fornito.

Sarei interessato a sentire qualsiasi opinione contraria, perché non vedo davvero come sia utile.

In tali usi è un nonce, non un SALT, e ciò che stai descrivendo è una forma di protocollo di risposta alla sfida. Vedi CRAM-MD5 per un protocollo standardizzato simile a quello che stai suggerendo (è circa un passo diverso).