La memorizzazione nella cache le password in chiaro in memoria di servizio WCF

Question

Questo suona probabilmente come una pessima idea, a prima vista, ma qui è il mio scenario: Ho un servizio di Windows che espone diversi endpoint WCF che utilizzano l'autenticazione utente. L'autenticatore personalizzato sia cercare le credenziali dell'utente in un database locale (password viene memorizzata come salata SHA-1), o farà una richiesta WCF per un altro servizio per convalidare la password. (C'è un enum sull'oggetto utente che può essere interno o esterno, che indica quale fonte di autenticazione per l'uso).

Ho constatato che l'esecuzione sia l'assegno di ricerca + hash o che effettua la chiamata WCF è costoso da fare su ogni singola richiesta al mio servizio, quindi vorrei alle informazioni di cache username / password. Ogni elemento nella cache avrebbe una vita, così per esempio se la voce nella cache è di 60 secondi di vita, alla successiva richiesta di autenticazione verificherà le credenziali contro la fonte originale anziché la cache e quindi aggiornarlo.

Per il database locale, si potrebbe semplicemente archiviare la coppia username / SHA1 in un dizionario, e su ogni richiesta da un utente "interno" Vorrei solo ri-hash la password fornita e confrontarlo. Per un utente "esterno", avrei solo la password in chiaro presentata al autenticatore, quindi sarebbe a me hash e conservarla come parte della cache. Anche se questo certamente mi fa risparmiare il sovraccarico di una richiesta di database o di una chiamata di servizio a distanza, ho ancora di eseguire l'operazione di hash ogni volta.

Il servizio in questione verrà eseguito su un server interno con un buon fisico, così come la sicurezza di rete. E 'una pratica accettabile per memorizzare la password in chiaro nella cache invece di memorizzare una versione hash? In quel caso il mio rischio sembra essere un attaccante il dumping della memoria del processo e ottenere le password. Se ritengo che rischio accettabile, c'è qualche altra ragione dovrei evitare di avere le password in chiaro nella memoria?

Se scelgo di usare password in chiaro, penso che SecureString potrebbe limitare il mio rischio in misura. Vale la pena la pena di utilizzare SecureString (attuazione sembra molto rotonda)? Sono ben consapevole del rischio di password memorizzazione persistente non-hash, però io non sono sicuro di quello che il consenso sembra essere su memoria volatile di password in chiaro.

Answer 1

SecureString utilizza la memoria criptata, quindi questo sarebbe probabilmente migliorare le prestazioni rispetto al fare l'hashing te stesso ogni volta. Ma si dovrebbe al profilo nel proprio ambiente.

Per quanto riguarda il rischio di immagazzinare le password semplici nella memoria, che non è una questione che può essere risolta in questo contesto. Potrei solo dire, sì, il suo OK. Perché è per la mia situazione, per vari motivi. Ma questo non sarebbe uguali ai suoi.

Ecco cosa suggerisco: Considerate le ramificazioni delle password che perde - in pratica quanto sarebbe il caso di ($ o $$$?) Ad un hacker di possedere una password? La maggior parte dei problemi di sicurezza in questi giorni vengono da un incentivo finanziario. Relativamente parlando, atti di vandalismo puro viene surclassato da questi ragazzi.

Ora si confronti con la possibilità che la sicurezza potrebbe essere compromessa in modo totalmente diverso, vale a dire SQL Injection o telefonando a un utente di "verificare le loro conto". Se il valore $ di una coppia di password è alta e non c'è altro modo per ottenere loro, allora forse si dovrebbe tenere cifrandoli (e ora si è giustificato il costo di un server più potente!). E assicurarsi che si quindi fissare la chiavi crittografiche -. Una volta un hacker ha il server, quelle chiavi sono probabile che, come di facile accesso come memoria di programma

D'altra parte, se il valore è basso e ci sono altri exploit possibili prontamente disponibili (e ci sono spesso), si potrebbe fare un argomento ragionevole che non vale la pena il tempo degli hacker per compromettere il server e il dump del la memoria.

In bocca al lupo.

Answer 2

  

Il servizio in questione verrà eseguito su un server interno con un buon fisico, così come la sicurezza di rete.

Fino a quando questo è vero da ora fino all'eternità (o la prossima patch, che mai viene prima) la memorizzazione di una password memorizzata nella cache in RAM come testo normale va bene. Se si dove memorizzare l'intero DB password nel ram (dire il vostro storage persistente è troppo lento) Penso che la loro memorizzazione come stringhe sicuri sarebbe meglio, ma dal momento che si memorizzano solo poche parole d'accesso per un massimo di 1 minuto, non vedo alcun problema.