A couple of people have asked me how and why the data for 10C Locker is stored if it's not written to the database. While I would love to have a grandiose story about how there's multiple layers of super-complex, Mission Impossible-style layers for the data to go through to keep it secure, the fact of the matter is really much less interesting: the data is stored in an encrypted folder on an encrypted drive.
The web server hosting the 10Cv5 API — which powers 10C Locker — runs Ubuntu 18.04 LTS1 on a pair of SSDs that have full disk encryption enabled to keep information safe in the event the entire machine is stolen. In addition to the full disk encryption, there is a dedicated 50GB VeraCrypt folder that needs to be manually mounted and password entered after each reboot. While I could have the password stored and automatically entered to have the VeraCrypt folder available within moments of a system reboot, I like the idea of having a person physically "unlock the vault". This might change in the future should the server need to reboot more than 6 times a year.
VeraCrypt is a solid tool that gives people a safe place to store information, and it's incredibly easy to set up on just about any Ubuntu-based operating system. People who are interested in doing so can find a simple step-by-step on AskUbuntu. The encryption algorithm being used is AES-Twofish-Serpent with a 768-bit primary and secondary key size. When the data is deleted from the VeraCrypt folder, the bits are overwritten with zeros to ensure that no fragment of the encrypted message can ever be recovered.
All in all, I'm fairly confident that the data people record via 10C Locker is as secure as I can make it.
Why Not Use the Database?
The second question that people generally ask is why the encrypted message is not stored in the database. Fortunately the answer is incredibly simple: backups. There are backups made of the 10Cv5 database at regular intervals, and some backups are held for as long as 90 days. This would mean that any encrypted message deleted from the database would likely continue to exist in a backup file on my NAS or burned to a DVD for longer than the message owner expects, which is unacceptable in my mind. One of the reasons I made 10C Locker was because I couldn't be certain that similar tools online didn't keep the data. If I were to be lazy and take shortcuts about data security, then why the heck did I invest the time in building an entire API endpoint and front-end for the feature?
All in all, I'm generally happy with how the system is set up to keep information secure. Could it be made stronger? Of course it can. Does it need further layers, though? Probably not at this point.
- This probably surprises exactly zero people. ↩