Killing yourself with passwords - part one

Passwords have always been a pet hate of mine, I'm one of the few people I know that has a password safe with almost 1000 entries. In this series of posts I'm going to detail my transition from a combination of DropBox and KeePassX to RatticDB.

In this series:

  • Part one - Overview, Requirements, Options and basic Design [this post]
  • Part two - Implementation Plan, Installation and setup
  • Part three - Security, Monitoring and back ups
  • Part four - Getting started with RatticDB
As I finish writing each post, I'll update the above list with corresponding links.

Requirements

My previous setup had the rather concerning requirement of installing DropBox on all computers in which access to passwords was required. I also had issues with urgent access to systems from mobile devices.

Before looking for solutions, I came up with the below list of requirements:

  • Not a spreadsheet
  • No special client software
  • Not reliant on public cloud services
  • Free (as in open)
  • Highly available
  • Something special, beyond a standard password safe
  • Ability to use LDAP Authentication
  • Two-Factor Authentication

Options

My methodology for finding options for this was limited to experiences that friends have had and were willing to give me temporary access to for testing purposes. This left two options: After a brief stint using TeamPass I decided the user interface was a bit too unfriendly for me, which coupled with the insecure suggestion of using 777 permissions put TeamPass out of the running for me.

Looking further into RatticDB I found an LCA2014 talk by Elizabeta Sørensen which detailed the RatticDB project and what it's trying to achieve. After a few hours browsing through Github, the RatticDB website and various discussion boards I was sold.

Basic Design

The architecture of this implementation requires a certain level of trust in the underlying systems - in this case the ESXi servers, network equipment and internet connectivity, that we must accept these as at least "good enough" for our needs. One of the key things I like about RatticDB is that they leave encryption choices up to the administrator rather than trying a more classic one-size-fits-all approach that may lead to problems in the future or difficulties for more paranoid administrator

I plan to utilise two Ubuntu Server 14.04 (LTS) VMs for the base of my installation with each VM residing on a different physical server. The LVM volume on each VM will be encrypted (more on that later) and each VM will run LXC with two containers - one for the MySQL Database and the other for the application. The MySQL Databases will be active / active so that I can load balance between the web servers and keep the databases separate from my main database servers. Replication traffic will traverse between the VMs via an OpenVPN tunnel to ensure security.

The active / active design is important to ensure hardware or software failure doesn't cause loss of access to the passwords.

LVM Encryption and other passwords for the solution will be kept in a KeePass Database stored both in RatticDB for ease of access in the event of a single server failure and on encrypted flash drives which will be stored in a secure location.

In addition to requiring Two Factor Authentication (built into RatticDB), access to the web application will be restricted via Client Certificates.