Security

If you are concerned about the security of the program, this page should tell you everything you need and maybe some things you never wanted to know.

The truth is, the program is as secure as you make it (that is not secure). There are several attack vectors that could possibly be leveraged in order to do mischief and compromise data. However there is this big question:

What is the data actually worth?

The only data the program works with is basically the songbook and so that is what can be stolen from you. Is it really such a problem? If yes, I will also mention some steps you can take to level up the security. But for me personally, I do not care if somebody makes an unauthorised copy of my songbook. If you tweaked the resources and templates or something, you may want to keep it private, whatever makes you happy.

Client security

The songbook, the songs, the collections, the resources, everything is placed in the program folder (unless specified otherwise) and so anyone who can read files on your machine can access them. This stuff is not supposed to be secret anyway.

Server security

The server is a set of PHP scripts, which is one mess of a language. That being said, there are probably some bad design decisions an attacker could potentially exploit, but you can use the backup feature to protect the songbook data. Remote code execution should not be possible (as much as it should not have been possible in log4j). The server API requires an authentication token for any kind of data manipulation and the authentication tokens are stored as a JSON file (where is no SQL, there is no SQL injection).

Connection security

This is where the game begins. The VCS system works over HTTP which is not encrypted nor authenticated and so it is possible to extract the token here or change the request entirely, given that somebody intercepts that very HTTP request. This can be mitigated by implementing HTTPS, which would require some extra configuration on the server and possibly even on the client end.

Local credentials security

The desktop client (the Java application) lets you to store your authentication token locally so you do not need to type it every time. However, storing credentials secretely in this case is impossible. The .auth file is encrypted so that the token is not stored in plain-text, but if somebody wants to go out of his way, this will not stop him. The problem is that the encryption key is derived from a password and this password has to be stored somewhere (we have exactly the same problem now, only we are using more RAM). This password is hardcoded in the source code of the desktop client, so all you have to do is to look at the source code to find it. If you build the client yourself, you can change the password, but decompiling a Java application is orders of magnitude easier than doing the taxes.

So if you really want to keep your token safe, you can change the settings to make the program use your own password that you will have to enter every time. You now basically have the same problem in a different place, but you can keep the password simpler than your token is. Keep in mind that upon changing the password, the program will no longer be able to decrypt the .auth file, so you will need to delete it and enter your token again.

Heading without content

This may not sound all that good, but the thing is that this is not a critical piece of software and not many people really care about your songbook so they will not waste their energy to try to disrupt it or steal it or something. Just create backups and stay healthy.