RatticDB and Encryption

RatticDB and Encryption

One of the most controversial decisions that we made in implementing RatticDB was the decision not to include any application level encryption. There are several reasons behind the decision, but ultimately it is because RatticDB is built to be 'Password Lifecycle Management' and not simply a 'Password Storage Engine'. RatticDB aims to help you keep track of what passwords need to be changed and when.

Encryption types reviewed

Static Key Encryption

We could add a configuration option in RatticDB that causes the password fields to all be stored encrypted in the database. RatticDB would decrypt the password field using the key before it sends them to the user. More fields could be included for more security, however each field you include cannot be indexed by the database. If you need to search across one of the encrypted fields you need to get every row, decrypt in in the application and check for matches. Needless to say this has the characteristics to be an expensive operation.

Other notes:

• This doesn't protect against a compromise of the machine as the key can be found in the application settings, or python can be used to import RatticDB's own libraries and force it to decrypt the password.
• Since RatticDB would be able to decrypt the password, a security flaw inside RatticDB would have access to the decrypted passwords anyway.
• The complexity of RatticDB is increased with little benefit.

Host Proof Encryption

Host proof involves encrypting the passwords before they are sent to the RatticDB server in such a way that the server does not know how to decrypt it. This would work by having each client generate a public and private key, the public key is then submitted to the RatticDB server. When a users creates or edits a password RatticDB will fetch all the public keys of the users who will have access and encrypts the passwords with them. In theory this prevents a compromise of the server from revealing any passwords. One big issue here is that via the web interface all the code that the web browsers execute comes from the RatticDB server itself. This means that a compromise of the RatticDB server would allow people to inject javascript into the client pages which sends the passwords to another location.

Other notes:

• The complexity of RatticDB would be significantly increased without a similar increase in security.
• None of the encrypted fields would be able to be searched, unless it happens on the client.
• Changes to access can only be performed by a client that has access to the password in question. This breaks LDAP access control using groups.
• The RatticDB server would not be able to verify or change passwords that have been set. These are features that we plan to implement in the future.

Filesystem Encryption

Filesystem encryption is where you do your encryption under the database layer. You could either do this at the block layer with Linux LUKS or over the filesystem layer with encfs. This encryption is entirely transparent to RatticDB and requires no additional code or tests. It does however increase the complexity of deployments. We plan to alleviate some of this by distributing a RatticDB installer in the future. We recommend that this encryption type be used when deploying production instances of RatticDB.

Other notes:

• This does allow an additional channel of access, someone could connect to the MySQL, Postgres or sqllite database manually using the connection data in the settings file.
• The encryption provided by filesystem level encryption is much better audited than any encryption that we put into RatticDB will be. As an open source project we cannot afford an extensive code audit (unless you want to do one for us).
• All fields and indexes are encrypted on disk and usable by the database when searching.