È sicuro o addirittura comune memorizzare nella cache i controlli di bcrypt in memoria

L'hashing della password viene utilizzato per l'archiviazione delle password a lungo termine per gestire il caso di accesso indesiderato al database di sola lettura da parte dell'utente malintenzionato. Questa è una minaccia realistica; tale accesso in lettura è un risultato comune degli attacchi SQL injection riusciti.

D'altro canto, un modello comune suppone che l'attaccante non possa leggere il contenuto della RAM di un server live. In quel modello, non vi è alcun problema nella memorizzazione nella cache della password stessa nella RAM, il che evita di dover toccare il database: la verifica della password è solo un confronto in memoria. Scenari in cui un utente malintenzionato può leggere la RAM senza essere in grado di assumere il pieno controllo della macchina sono abbastanza complicati e difficilmente applicabili.

Il caching dell'emissione di bcrypt non ha molto senso da solo, perché, affinché questa informazione sia utile, deve essere in qualche modo indicizzata dalla password e dal sale (internamente, ci sarebbe una mappa "password + salt" su "bcrypt output"), quindi l'autore dell'attacco che può leggere l'output bcrypt dalla RAM dovrebbe essere in grado di leggere la password in chiaro. Tuttavia, in una determinata implementazione del server esistente, potrebbe essere più semplice riadattare una cache RAM come tale mappa (nel codice, è possibile collegarlo in modo trasparente al "motore bcrypt"); come spiegato sopra, l'output di caching bcrypt non è peggiore dell'archiviazione di password in chiaro nella RAM, che di solito va bene.

Dalla tua domanda, sembra che tu stia inviando la password al server ad ogni richiesta. Se è così, devo chiedere: perché mai lo faresti?

Il solito schema è quello di inviare la password una volta su una richiesta di "accesso". Se la password è corretta, il server invia al client un token di autenticazione temporaneo generato casualmente. Questo gettone dovrebbe essere abbastanza lungo da resistere a un attacco di forza bruta anche senza tecniche di allungamento chiave, e avere un periodo di validità abbastanza breve che compromettendolo presenta solo un rischio limitato. (Per operazioni particolarmente critiche per la sicurezza, come la modifica della password a lungo termine, è ragionevole chiedere al cliente di inviare nuovamente la password originale.)

In genere tali token sono archiviati sul lato server in modo semplice in alcune sessioni di archiviazione a breve termine. Suppongo che potresti farlo con una funzione hash non allungata, così che un compromesso dell'archiviazione dei token non comprometta automaticamente tutte le sessioni attive.

Sul lato client, è comune per le app Web archiviare il token in un cookie HTTP, in modo che venga automaticamente inviato al server ad ogni richiesta. Tieni presente che, se lo fai, dovresti fare attenzione a proteggere la tua app contro gli attacchi di falsificazione delle richieste tra siti.

• No, non è comune per gli hash delle password
• È raro perché ciò che si vuole veramente fare è assegnare un ID di sessione temporaneo dopo un accesso piuttosto che autenticare continuamente la password. Questo aiuta anche a prevenire gli attacchi CSRF se implementati in un certo modo.
• Se la correzione dell'architettura richiede molto lavoro, puoi come cache di stop-gap la password < - > bcrypt risultato per un periodo di tempo. Accertarsi che sia archiviato solo in memoria e scada dopo un breve periodo di tempo. Probabilmente 10 minuti sono appropriati.