Zero-out sensitive data after use

[emerose]

The current Grendel code uses ordinary char[] and byte[] arrays to store secrets, including passphrases and documents. (I haven't investigated private key data yet…) These are cleared from memory only at the whim of the GC algorithm, which can mean that sensitive data remains in cleartext on the server well after it is needed.

This isn't a huge deal, but given Grendel's threat model — it's designed to protect secrets while not in use, even against attackers with access to local storage — it does represent a threat. To protect against it, the array objects' lifespan should be kept as short as possible, and they should be explicitly overwritten when no longer needed. Some Java sources explicitly recommend this practice — a quick search turns up the following:

http://java.sun.com/javase/6/docs/api/java/io/Console.html
http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#PBEEx

However, I wouldn't be surprised if the Java world is less than consistent on this point. (And indeed: more searching turns up http://java.sun.com/security/seccodeguide.html#0-6b which provides some less-than-helpful advice on the topic. "Reduced effectiveness" is still more effectiveness than no effectiveness, though.)

-sq

[codahale]

The user's password is transmitted via basic auth, and only accessible via HttpServletRequest#getHeader(String), which returns a String, which as you know is immutable and tends to hang around the heap longer than other objects. The private keys for users' keyset are stored as BigInteger instances, which are also immutable.

I should probably just take the #sanitize() methods out and convert the char[] usages back to Strings for honesty's sake. If an attacker can traverse the process's heap, the jig is up regardless of what I do. (Short of reimplementing this in a language with manual memory allocation or implementing my own mutable bignum classes and implementing the cryptographic algorithms on top of that.)