Re: Encrypting passwords stored in memory
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: Encrypting passwords stored in memory

From: Alan <a__l__a__n@hotmail.com>
Date: Tue Sep 20 2005 - 16:46:01 CEST

Shankar wrote:
> A recent security audit has raised the issue that these passwords
> can be seen if a memory dump of the process is taken or it is
> swapped out. Are there any standards for storing passwords in
> memory?

I'm not aware of any standards, but this is a common problem that has been
addressed by some folks who know what they are doing. My first exposure to
addressing this issue came while studying PGP 2.6.2 source code. (It's been
ten years since I did that, so some of what I'm about to describe may have
come from other sources...) Anyway, I've built systems with encryption keys
K(n) which must be stored in memory. Those keys are stored encrypted with a
constant key, which is compiled into the program. The constant key "must
not" be stored as a string (too easy to find with a "strings" command).
Instead use byte arrays, preferably multiple of them located in different
parts of the software, each storing a piece of the key. When you must
obtain your keys K(n), you construct your constant key from its precusor
parts into a byte array, then decrypt K(n) into another byte array. You
then decrypt whatever you need. Then you zero out the two byte arrays
containing K(n) and the constant key.

All of the above should be locked into memory (non-swappable) using your
platform's tool. You should definitely test the effectiveness of the mlock
(using a test value for the keys and some sort of memory eating tool to
force maximum swapping, then scan the swap drive for the test keys). If you
find them, you lose :-(

You must also use strong login passwords (especially for root) and patch
your operating system and other software components rigorously and
continuously. Remove all services that are not necessary. Close all
unnecessary ports on firewalls (did I mention keeping your firewalls
patched?) etc.... Anyone who can gain physical access to the machine, or
who can gain root login through any means including buffer overflows etc,
can overcome everything I've described (as well as, probably, every possible
measure I have not described...)

Good luck
Alan
Received on Thu Sep 29 21:56:18 2005