È consigliabile crittografare questi dettagli in memoria, ma è necessario intraprendere una sorta di processo di modellazione delle minacce e vedere se giustifica il sovraccarico.
Sembrerebbe che il tuo rischio principale sia che gli utenti leggano la memoria usando strumenti appropriati, questo richiede intenzioni malevole e un utente abbastanza sofisticato. È uno scenario di probabile rischio? A cosa possono accedere se compromettono le credenziali? Sono solo dati sul computer locale?
I dump della memoria sono un altro potenziale problema, se si verifica un errore o un utente malintenzionato costringe un errore e la memoria viene scaricata nei registri, i dati potrebbero essere recuperabili da questi registri.
I file di swap e di ibernazione possono contenere anche questi dati quando la memoria viene scambiata o se il dispositivo va in ibernazione mentre le credenziali sono in memoria.
Ci sono più strumenti disponibili per proteggere contro questi casi, tipi come SecureString in .Net framework, ci sono anche API di protezione dei dati fornite dai sistemi operativi MS. Secure String, come già confermato da un utente, è immutabile e crittografato e viene anche memorizzato in più posizioni in memoria. Userei costrutti come questo fornito dai framework e dal sistema operativo ed eviterò di far ruotare il tuo codice per proteggere i dati nella RAM.