I am looking for a password application for storing passwords, and RatticDB have a web interface and SSH access is planned, which are exactly the features I am looking for. However, they write that they don't encrypt the database.

When designing RatticDB we made some very specific design decisions.
We didn't include encryption in the application at all. Encryption is
not easy to do right, increses complexity and the application needs to
be able to decrypt the passwords somehow anyway. We do recomend that
you install it in such a way that the database is on an encrypted
filesystem.

An encrypted file system doesn't really protect the database when the Linux host is running, so the passwords will be in clear text as long at the host is up.

4 Answers
4

RatticDB is a password manager; it must, by definition, be able to return the raw passwords themselves. From the outside, the role of the password manager is to store the passwords and show them only to duly authenticated entities, so that the stored passwords may be used with third-party systems which are completely unaware of how the passwords are remembered by users.

Encryption is a mechanism which can be used to ensure data confidentiality within certain conditions. In the case of a password management database, the use or non-use of encryption makes a difference only with regards to partial breaches by attacker. Since RatticDB must be able to produce the stored passwords on demand by the right user, a complete hijack of the machine necessarily allows the attacker to obtain all passwords, regardless of encryption. However, if a backup file for the database component is stolen, then encryption matters: if the data was encrypted with a key that was not stolen, then the breach does not reveal the passwords.

From an engineering point of view, RatticDB's stance is understandable: as an application-level piece of code, it may consider that database encryption is best dealt with at the database level, out of the scope of RatticDB itself. Indeed, whether encryption brings benefits or not depends on contextual characteristics such as the local backup policies. A comprehensive database encryption system would be TDE (as implemented by Oracle and Microsoft SQL Server), which is done on the database, regardless of the application.

Another model where encryption could be applied, and would become relevant, would be a password manager which stores only encrypted passwords that the manager cannot decrypt. In a way, this is how most "password wallet" applications work, when included in your browser (e.g. KeePass): data is ultimately encrypted with regards to some user secret (e.g. a "master password") and decrypted right on the user's machine, even if the encrypted passwords are physically stored in another machine. This sort of thing can work only if the client system (the one closest to the human user) is able to do decryption, something which is not a given in a Web context (basically, it needs a browser extension). RatticDB appears to follow another model, which supports dumb clients (Web browsers with no extension).

At some point if the host is compromised it might anyway be possible to extract the information even if the app encrypts things. Setup the system on an encrypted LVM and use long and complex passwords for management.

Needless to say that they should be changed frequently.

From my POV I don't think it is more unsafe just because they do not use encryption internally.

They seems to think that the passwords need to be stored in plaintext in order to be useable. This is no better than keeping a plaintext list of passwords on your desktop because your password host WILL become compromised.

This is yet another case of someone not understanding an existing solution before creating their own.

The passwords should be encrypted on the client and the cyphertext should be stored by the password managing host.

Another point to keep in mind, this completely breaks any laws you have to abide by. For example, if you are in healthcare, using RatticDB will cause you to be 100% non-compliant with HIPAA.

Just because a password has to be retrieved or viewed by users is not a reason to ignore encryption. This is the same thinking process that banks and websites have been using for ages for their member login information... OH, because we use SSL when a user authenticates, it means the password is never sent over the web in plaintext... Until someone gets in via XSS and can run SQL queries against the entire database, letting them see the entire table that has all the passwords in plaintext.

This isn't 1990 people.

I cannot recommend this application to anyone. Check out webpasswordsafe (free) or LastPass (free & paid)