0

I've created a user application running on Windows 7 desktops. This application allows users to enter their username and password for another system. My application does this with a simple textbox.

Currently, I'm storing this data in memory for the application. The application later encrypts and transmits the credentials via TLS https. My question is, can I store the username and password in my applications memory unencrypted? What rules do I need to follow with accepting and holding (in memory) user credentials?

schroeder
  • 125,553
  • 55
  • 289
  • 326
Steve Short
  • 1
  • 1
  • Although this quesiton isn't about standard practices or rules, you may find it helpful: https://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe – Cody P Sep 06 '17 at 21:42

3 Answers3

1

It is best practice to encrypt these details in memory, but you need to undertake some sort of threat modelling process and see if it justifies the overhead.

It would seem your primary risk is users reading memory using appropriate tools - this requires malicious intent and a fairly sophisticated user. Is this a likely threat scenario? What they can access if they do compromise the credentials? Is it just data on the local machine?

Memory dumps are another potential issue, if an error occurs, or a malicious user forces a fault and memory is dumped to logs, the data may be retrievable from these logs.

Swap files and hibernation files may also contain this data as memory is swapped out or if the device hibernates while the credentials are in memory.

There are multiple tools available to you to protect against these cases, types such as SecureString in .Net framework, there are also data protection APIs provided by the MS operating systems. Secure String as one user has already replied are immutable and encrypted and they are also stored in multiple locations in memory. I would use constructs such as this provided by the frameworks and the OS and avoid rolling any of your own code to secure the data in RAM.

iainpb
  • 4,162
  • 2
  • 17
  • 35
0

You should not hold them un-encrypted, since it's easy to take copies of memory and look for known tokens in there.

Depending on your language being used, I would recommend a secure string implementation such as .NET SecureString class. This ensures a immutable, encrypted and have a security garbage collection when no longer needed.

Other than that, make sure it doesn't end up in log files or exception handling dumps, etc.

ndrix
  • 3,226
  • 13
  • 17
  • 1
    Given "However, those strings may still be exposed to any process or operation that has access to raw memory, such as a malicious process running on the host computer, a process dump, or a user-viewable swap file" SecureString doesn't offer a lot of advantage over a malloced region which is not freed before an explicit overwrite? – symcbean Sep 04 '17 at 21:23
-2

It all comes down to a risk assessment - what is the risk of doing what you propose? What is the impact of having those credentials stolen?

Any process with access to that memory could copy the credentials.

Are you ok with that risk? Will your users be ok?

Secondly, if you told your users about it, how comfortable would they be? Do you risk losing customers or reputation?

schroeder
  • 125,553
  • 55
  • 289
  • 326
  • This seems more like a comment to me. Asking what the risk is and how comfortable he is with the customers knowing it may help the user think, but it doesn't provide any new information or expertise. Who has access to the memory? What OS protections are in place? What standard practices and OWASP recommendations are there? – Cody P Sep 06 '17 at 21:53
  • @CodyP unless the risks dictate that it is unnecessary to encrypt in memory. Then the decision is based on the risk assessment and not 'best practice' or what others would do. – schroeder Sep 07 '17 at 19:09
  • Asking someone to perform a risk assessment without explaining the risks isn't very helpful. I could copy and paste your answer with little change to almost any question. What are the typical risks? Why is a risk assessment so important? How difficult are the risks to mitigate? For example, if I asked "How do I store my passwords?' or "Is HTTPS worth it" and you answer "Are you ok with the risks?", then your answer obscures and distracts from the fact that for almost everyone, the answer is (summed up) "hash them using a salt and bcrypt" and "yes, you should be using HTTPS" – Cody P Sep 07 '17 at 19:20
  • @CodyP and when the question is "Can I store credentials unencrypted?" then the answer is about risks, and yes, that's an answer that is broadly applicable. But, when someone is asking the question about "can I?" and "what rules do I follow?" any answer ***has*** to include a risk assessment. Walking the OP thru a risk assessment does not seem appropriate. But it seems that the OP has not considered approaching the problem from a risk angle. – schroeder Sep 07 '17 at 19:30