Consider an application that runs locally on a Windows PC. The application uses a local folder for reading/storing encrypted data (i.e. images). A user logs in (authenticated from a local encrypted DB). The application needs to perform secure read/write operations to local storage based on user-UI interaction. These operations are using symmetric cryptography (AES).

  • Is it safe to store information such as password or a cryptographic key in memory (i.e. a private class member) for the whole session?
  • If not, what is the alternative way (I assume not to interrupt the user asking for password every time a crypto operation needs to take place).
  • the answer here may inspire you security.stackexchange.com/questions/12332/… May 28, 2019 at 14:36
  • @SoufianeTahiri I have already save the hashed version of user password in a local encrypted DB (I am using bcrypt for the hash and CryptProtectData for the DB). I check if the hashes match to proceed. Should I keep users' pass in a class member variable to generate the keys for AES operations later? May 28, 2019 at 14:52

1 Answer 1


It depends on your threat model. Will a potential attacker have access to the machine? Might they be able to escalate their authority enough to either dump the process space of the application, or to attach to it as a debugger? Or if you’re concerned about the attacker downloading the entire database and being able to decrypt all the images, consider moving the decryption process or image storage to a separate machine with better security. Or you could encrypt each image with a unique key, and keep each key in a remote database, and use the user’s database to store their master decryption key.

If your concern is that a rogue or compromised client will download each decrypted image in an attempt to acquire the entire database, consider a monitoring process that alerts you to excess activity. Also, consider slowing down each key or image request (this process is known as “trust anchor dragging”) making it harder for anyone to download the entire database in a reasonable amount of time.

Rather than use a private member to store the key, use your platform’s provided cryptographic service library. On Windows, use the CryptoAPI. In Java, use the Cryptographic Service Provider. These tools are designed for secure storage of keys.

If you can’t use the cryptographic library, the key might be persisted in swap space, and end up on your hard disk. If you have the option in your language (C/C++, go, ASM) consider allocating memory using your operating system’s secure memory function, such as mlock() or VirtualAlloc().

  • The potential attacker is unlikely to access the machine (but not impossible). The storing of password in a class private variable for using it for the entire session is discouraged? Are there any alternatives? I think I get your point but I want to know the potential implementations in order to examine what exactly should I implement (in terms of security and ease-of-use). May 28, 2019 at 15:11
  • OK, I added info to the answer regarding using the CSP or OS secure functions. May 28, 2019 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .