Password in memoria, modi pratici per migliorare la sicurezza

Question

Password in memoria, modi pratici per migliorare la sicurezza

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

2

La memorizzazione di una password nella memoria di un'applicazione è rischiosa. Il sistema operativo può scrivere una parte della memoria su disco come file di scambio. I processi possono accedere alla memoria l'uno dell'altro, anche se non dovrebbero. (Altro)

Sto sviluppando un generatore di password deterministico con Java e mi chiedo quale sia il modo migliore per gestire la chiave master in memoria. Ci saranno periodi di tempo in cui l'applicazione deve "ricordare" la chiave principale, prima che possa sovrascriverla in memoria. Ho pensato di crittografare la chiave principale in memoria e scrivere la chiave di decodifica generata a caso sul disco. Quando la chiave master non è più necessaria, l'app tenterà di sovrascrivere sia il file su disco sia la chiave master crittografata. Questo approccio fornirebbe almeno un po 'di sicurezza nei confronti di qualcuno che successivamente scopre un vecchio file di scambio. Ha senso? Dovrei fare qualcos'altro?

Quali sono le buone pratiche per ridurre la durata dei dati di password e chiavi crittografiche in memoria?

java memory password-management data-leakage

posta Atte Juvonen 13.01.2017 - 14:13

fonte

3 risposte

Leggi altre domande sui tag java memory password-management data-leakage

È sicuro utilizzare la crittografia di Java Bouncycastle nell'ambiente di produzione rispetto alla cripta standard di Java? È sicuro usare la sessione per verificare se l'utente ha effettuato l'accesso?

score 2 · Answer 1

2

In Java, si consiglia che una char[] è usato per dati sensibili invece di un oggetto String . Ciò rende possibile sovrascrivere i dati quando vengono eseguiti con esso, cosa che non è possibile con l'oggetto String immutabile.

risposta data 13.01.2017 - 14:36

fonte

score 1 · Answer 2

What are good practices to reduce data lifetime of passwords and cryptographic keys in memory?

Encrypt your swap file / partition. Quindi non dovresti preoccuparti di perdere le password dallo swap.

Se scrivi il programma, dovresti anche usare le funzioni di sistema che impediscono che alcune parti della memoria vengano cancellate, usando mlock () o mmap () con MAP_LOCKED in Linux o VirtualLock () in Windows.

Molti sistemi Linux oggi sono configurati in modo tale che, a meno che tu non sia root o abbia il permesso di ptrace, non puoi direttamente leggere / scrivere su altri processi dello stesso utente a meno che l'altro processo non sia un processo figlio del processo di tracciamento (ptrace_scope = 1 ). Se hai bisogno di una sicurezza migliore, puoi anche configurare in modo che ptrace child sia possibile solo da root o processi con capacità CAP_SYS_PTRACE (ptrace_scope = 2) o disabilitare completamente ptrace (ptrace_scope = 3). Su Windows, questa autorizzazione si chiama SE_DEBUG_PRIVILEGE.

La migliore pratica se stai lavorando su un linguaggio multipiattaforma di livello superiore come Java è quello di lasciare la gestione delle chiavi a un processo separato come gpg-agent o ssh-agent. Oppure a un modulo di sicurezza hardware, che gestisce la chiave, l'autenticazione o la crittografia / decrittografia su un hardware separato. Un'altra opzione è che molti sistemi moderni possono anche supportare TPM, che fornisce HSM essenzialmente incorporato.

score 1 · Answer 3

Potresti usare GuardedString allo scopo di mantenere le stringhe delle password un po 'più sicure. Si tratta di uno speciale oggetto String creato per risolvere problemi di password mantenute in memoria rappresentate da String:

Pacchetto org.identityconnectors.common.security.GuardedString versione 0.2.3. Citando la documentazione del file di classe GuardedString:

Secure string implementation that solves the problems associated with keeping passwords as java.lang.String. That is, anything represented as a String is kept in memory as a clear text password and stays in memory at least until it is garbage collected. The GuardedString class alleviates this problem by storing the characters in memory in an encrypted form. The encryption key will be a randomly-generated key. In their serialized form, GuardedString will be encrypted using a known default key. This is to provide a minimum level of protection regardless of the transport. For communications with the Remote Connector Framework it is recommended that deployments enable SSL for true encryption. Applications may also wish to persist GuardedStrings. In the case of Identity Manager, it should convert GuardedStrings to EncryptedData so that they can be stored and managed using the Manage Encryption features of Identity Manager. Other applications may wish to serialize APIConfiguration as a whole. These applications are responsible for encrypting the APIConfiguration blob for an additional layer of security (beyond the basic default key encryption provided by GuardedString).