Location, Location, Location

cropped-hackersstill

I wouldn’t think that cryptography and real-estate tend to overlap often, but they have at least three things in common: location, location, and location. Go into any office and check for notes on the undersides of keyboards, in top desk drawers, or stuck to the sides of monitors, and you’ll find every password you need to access their systems. This is probably not a great thing, but ultimately if you’ve got physical access, you’ll most likely get to the data eventually. Some even encourage writing passwords down, because the alternative of forced memorization usually means people will choose simple passwords and reuse them.

So what’s more secure? A complex password in a desk drawer, or a simple one memorized and reused across multiple sites? For most people, probably the former. Chances are, you don’t have anything the NSA or the CIA would care about, so you’re more likely to be at risk from a teenager somewhere in Asia harvesting data for identity thieves than you are to have a spy breaking in to your office. Of course, this isn’t to say that writing down a password is a good idea, so what’s the better way?

I have a KeePass file that I’ve used to store personal passwords in for about a decade now. It’s got a good secure password that’s easy for me to remember, but it’s a pain to keep backups and make sure it’s in sync. You can use something like DropBox to make it available, but since DropBox isn’t really designed to be particularly secure, you’ve given an attacker an additional access vector. It’s also difficult to share any single item with someone else, without giving them the whole thing.

You could use a site like Lastpass or 1Password, but not only are these more tempting than a shiny red button to anyone hoping to harvest passwords for nefarious purposes (Lastpass has already been compromised at least once), but they could turn off their servers at any point and your saved data would all be gone forever.

The best solution, in my opinion, is to distribute the data and ensure no single point of access gives an attacker everything they need to break into the data. In PassBrain, I’m accomplishing this by providing the software to anyone who wants to install it on their own servers (so an attacker can’t just break into a site like Lastpass and access all the data, they’d have to know to target your password site specifically), and then additionally splitting the keys between client and server.

First, we have the user’s login password. This is of course stored nowhere except as a hash, which is great since we only ever need to check that it matches, but we can’t do this with our secret data, as it must be read back. So the next level is our public/private key pair, that’s unique to a single device for a user (if a user accesses the site with multiple devices, they’ll have a unique key pair for each). The public key is stored on the server in plain text, as other users of the site will need to access this in order to encrypt data to send to them. The private key is then stored locally on the user’s device.

If an attacker were to gain access to the server, they would have no way of extracting the data from the database, since they would need the private key from the user’s device. Likewise, if they have access to the device but not the user’s password to log into the site, they can’t access anything useful to decrypt with it. While an attacker could install a keylogger to get this information, at that point they could just log the passwords directly no matter how secure they are.

I also considered a model where a centralized hosted site like Lastpass is used to control user access, but it connects to a secure remote location to store the actual password ciphers that the client controls, but I don’t think this gains anything over simply hosting the site yourself. This could add an additional layer of security that’s worth looking into, but the more movie pieces you add to a system like this, the more potential doors you open up for someone to get in through.