Re: Encrypting passwords stored in memory

From: Alan (a__l__a__n_at_hotmail.com)
Date: 09/20/05 

Date: Tue, 20 Sep 2005 10:46:01 -0400

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

Relevant Pages

  • Re: Extreamly large Hashtable
    ... >>>I'm assuming that if it is in memory it will be faster then looking ... >>performance (unless it means that the keys' equals() and ... >>references to the objects, ... Even if the Map.Entry overhead is more ...
    (comp.lang.java.programmer)
  • Re: Security Flaw in Popular Disk Encryption Technologies
    ... does that mean that geli properly wipes keys from RAM when a laptop is turned off? ... This attack has to be defended against in hardware; it exploits a 'feature' of modern day RAM chips, which can not be controlled by software. ... As encrypted volumes simply require keys to be in memory to be able to use the volumes, the encryption software is vulnerable to this attack. ...
    (freebsd-hackers)
  • Re: Efficient processing of large nuumeric data file
    ... the test for whether a key is in the dict. ... Keep an eye on your program's memory consumption as it runs. ... I'd probably use the unix "sort" utility to sort the input (that ... each group of keys (see itertools.groupby for a convenient way to do ...
    (comp.lang.python)
  • Re: Security Flaw in Popular Disk Encryption Technologies
    ... "detach - Detach the given providers, which means remove the devfs entry and clear the keys from memory." ... does that mean that geli properly wipes keys from RAM when a laptop is turned off? ... This attack has to be defended against in hardware; it exploits a 'feature' of modern day RAM chips, which can not be controlled by software. ... As encrypted volumes simply require keys to be in memory to be able to use the volumes, the encryption software is vulnerable to this attack. ...
    (freebsd-hackers)
  • Re: ssh gives "Permission denied, please try again"
    ... as secure as those Debian generated keys... ... If you always pick passwords whose first four letters are 'A' you're ... The point being that keys are not some panacia and those that think they ... lots of people attack passwords, nobody attacks keys. ...
    (uk.comp.os.linux)