6

I have found a similar question here Saving passwords inside an application but it didn't really answer my concerns.

I am dealing with an application that will receive a password (securely) from the user. Once I receive the password I would need store it in some variable and send it through transactions to other systems (this logic is safe and secure and already implemented).

My worry is that I don't want to be able to see the password in a core dump so I would like to encrypt any password before saving it to any variable.

Questions:

  • Is encrypting it before saving it to a variable enough? Or am I missing some security loopholes?

  • Is there a simple header only libraries that can do encryption? Can you guide me to where I can start looking?

Note to answer commenters:

  • The password will not be stored long term; Only for the lifespan of the transactions.

  • Unfortunately, the participants of the transactions cannot decrypt the password, therefore I would need to decrypt it before I send it to them.

  • My main concern right now is to find a way to encrypt and decrypt the password locally - in an easy manner...

  • I found OpenSSL library and crypto++ but it seams that I would need to link with them, I can't just include and call them (i.e. not header only libraries)...

Thanks,

Community
  • 1
  • 1
Kam
  • 5,878
  • 10
  • 53
  • 97
  • Well, if the encryption routine fails, you *will* see the password :) There are platforms specific ways to really 0-out memory however, so you could use those to clear the password from memory as soon as you do not need it any longer... though of course you will likely have access to the necessary resources to decrypt it should you want to. – Matthieu M. Jun 12 '13 at 15:09
  • Are you planning to store the password "long term" or "short term" (by long term, storing it in a file somewhere on disk, short term, you receive it and then send it to the other server then and there, only holding the password for as long as you need to send it)? Any "long term" storage is breakable. That's why "proper" password storage is done in "oneway encryption", so you can never "reverse encrypt it" [it's of course still possible to "run the encryption on a lot of possible guesses" until it matches]. – Mats Petersson Jun 12 '13 at 15:13
  • 2
    If someone has access to your encrypted password in the dump and the encryption/decryption, then it is fairly trivial for them to decrypt your encrypted password. The best way to keep a password safe and protected is by not keeping it at all. So you have to decide how difficult you can reasonably make it for snoopers to find and reverse process your protections around the password. – StarPilot Jun 12 '13 at 15:14
  • I have updated question. @StarPilot I understand your concern but I guess it is a risk I would have to take since I need to encrypt and decrypt within my application. – Kam Jun 12 '13 at 15:20
  • you could link statically to openssl or crypto++ – Uroc327 Jun 12 '13 at 15:22
  • @Uroc327 ahh I didn't know that.. mm I don't know if they offer the static library for download or need to build it myself.. But will look into it. – Kam Jun 12 '13 at 15:24
  • @Kam It seems, like there are static libraries for OpenSSL available (didn't look for crypto++). In my /usr/lib directory as well as after googling i got a static library (didn't test... ;)) – Uroc327 Jun 12 '13 at 15:33
  • "receive a password (securely) from the user" - in what way? Does the user type in their password, or is it received over a network and in plain text? – TheDarkKnight Jun 12 '13 at 15:36

1 Answers1

2

(Note: I'm sure there are rigorous checklists and official guidelines about how to treat passwords in secure software out there, from people and authorities that actually know something about security. This is not one of those!)

I don't think there is a cryptographically-secure way to have passwords in your process memory, be able to use them, but not give access to it to a user that can run your application under a debugger or inspect your core dumps.

What you can do is obscure the password. Here are some techniques you can use:

  • Not keep the password as a simple string anywhere in your memory (scatter the characters around, etc.)
  • Scrub all the variables that the password is stored in after they are used (e.g. if you pass the password to a function, you should set all the characters of that variable to NUL inside the function after you are done with it.
  • Encrypt the password.
  • Vary the encryption key at each run of the application (or periodically if it's a long-running app.)
  • Generate the encryption key procedurally based on some aspect of the system/hardware and not store the encryption key for the password anywhere in your process memory.
  • Use hardware like the Trusted Platform Module (TPM) if available.

Implementing the above consistently and effectively is quite hard and impacts all of your code that deals with the password. And sometimes you even have to intentionally make your code more obscure and go against all your instincts as a programmer (e.g. not passing the password into functions as a parameter, but using hard-coded addresses inside the function.)

I, once again, have to emphasize that it's probably provably impossible to secure your passwords in software only, when the adversary has complete access to the physical machine.

As for the second part of your question, I don't know of any header-only encryption libraries, but encrypting a password will probably only need a cipher and probably a hash. And all of the best algorithms have public-domain or otherwise free implementations in the wild. You can get one of those and copy/paste into your own application. Don't forget to seriously test it though!

yzt
  • 8,873
  • 1
  • 35
  • 44