Using char[] in addition to String for password passing

[abeluck]

Hey guys!

It would be pretty spiffy if the Java API provided additional functions to handle the password as a char[] throughout the duration of the string's lifecycle. Currently, the API uses String exclusively for handling the users password.

The Java Secure Coding Guide and JCE Guide both suggest the use of char [] for storing sensitive information, such as passwords. This is because the String object is immutable and cannot be overwritten once the operations are complete.

The goal here is to limit the extent to which sensitive information is sprayed about in memory.

I thought this might be a simple patch to contribute, but following the rabbit hole all the way down reveals even the SQL statement that keys the database uses a String in the native call.

    execSQL("PRAGMA key = '" + password + "'");

So, supporting a char[] would require adding additional methods for every one that takes a password. We could possibly re-implement the String versions in terms of the char[] versions by calling String.toCharArray().

Finally, I propose an additional native method along the lines of native_execSQL(char[] sql). Then this method could be used for the key and rekey statements.

I'm happy to implement this, but since it is rather invasive I figured I should propose it for discussion first.

Thoughts?

[developernotes]

Hi Abel,

That sounds interesting, definitely something worth investigating further. Keep in mind that SQLCipher itself will continue to keep the key in memory to encrypt/decrypt pages. It is difficult to mitigate security leaks when one has access to a full memory dump of an application. As an aside, if you want to look into this further, we have a test suite that can be run across Android emulators/devices; you may consider adding additional tests around your new behavior. Let me know if you have any questions. Thanks!

[abeluck]

Indeed. Given an attacker with access to the memory and who is sufficiently patient and skilled, all secrets are belong to them, as it were.

However, my interest here is in protecting the user's passphrase not the encryption key. This is important because users often reuse passwords across multiple services. The compromise of a password in one context (e.g., memory dumped from X app) could lead to compromise in another context (e.g., their email).

So. the passphrase need only exist in memory long enough to derive the encryption key.

Would you be amenable to the modification of the API in the way I described? I'd like to get at least a cursory thumbs up before I spend the time implementing it ;-)

[developernotes]

Hello Alfred,

While the public API does currently accept a String parameter as a password, the client API does not store the password and the keying of the database occurs as a char[]. We plan to migrate the public API towards a char[] at some point in the future as well.

[developernotes]

Hello Alfred,

No, we do not have a timeline for this, it will likely be soon, as there isn't much involved with this change.

[developernotes]

Hello Alfred,

Certainly, if you are interested in issuing a pull request we'd be glad to take a look at it when you are ready. If not, I plan to address it soon.

[developernotes]

Hello Alfred,

I have just recently pushed a new version of SQLCipher for Android (3.0.2) that now included accepting a char[] as a parameter to opening a database connection.

[developernotes]

Hi @alfredperkins,

Yes, we will look at adding that in another release.