Passwords in memory, practical ways to improve security

Question

Storing a password in an application's memory is risky. The OS may write a portion of memory to disk as a swap file. Processes may access each others' memory, even though they shouldn't. (More)

I'm developing a deterministic password generator with Java and I'm wondering what's the best way to handle the master key in memory. There's going to be periods of time where the application needs to "remember" the master key, before it can overwrite it in memory. I thought about encrypting the master key in memory and writing the randomly generated decryption key to disk. When the master key is no longer needed, the app would attempt to overwrite both the file on disk and the encrypted master key. This approach would at least provide some security against someone later uncovering an old swap file. Does it make sense? Should I do something else?

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

Answer 1

In Java, it is recommended that a char[] is used for sensitive data instead of a String object. This makes it possible to overwrite the data when done with it, something that is not possible with the immutable String object.

Answer 2

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

Encrypt your swap file/partition. Then you wouldn't need to worry about leaking passwords from swap.

If you write the program, then you should also use system features that prevents certain parts of the memory from being paged out, using mlock() or mmap() with MAP_LOCKED in Linux or VirtualLock() in Windows.

Many Linux systems nowadays are configured so that unless you're root or have ptrace permission, you cannot directly read/write to other process of the same user unless the other process is a child process of the tracing process (ptrace_scope = 1). If you need better security, you can also configure so that ptrace child is only possible by root or processes with CAP_SYS_PTRACE capability (ptrace_scope = 2) or to disable ptrace entirely (ptrace_scope = 3). On Windows, this permission is called SE_DEBUG_PRIVILEGE.

Best practice if you're working on a higher level cross platform language like Java is to leave the key management to a separate process like gpg-agent or ssh-agent. Or to a hardware security module, which does the key management, authentication, or encryption/decryption on a separate hardware. Another option is that many modern systems may also support TPM, which gives you essentially in-built HSM.

Answer 3

You could use a GuardedString for the purpose of keeping password Strings a little safer. It's a special String Object crafted to deal with issues of having passwords kept in memory represented by String:

Package org.identityconnectors.common.security.GuardedString version 0.2.3. Quoting the GuardedString class file documentation:

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).