LastPass: Security done wrong

So I use KeepassX for Linux (and Keepass2Android on my mobile), which I frankly don't understand why it's not recommended way more often. It's open source, doesn't have those problems, nor does it have a company--ego--attached to it that has incentives to downplay security-issues to save face/profit. Ego is a potential attack surface.

Every time the password-manager discussion comes up, I scan the thread and check what possibly problems any of them have. And all of the other ones have at least some of those issues that I care about, even if only that the encrypted blob is stored somewhere out of your control. Except for KeepassX, for which the only "serious" downside I've read is that some big security names on Twitter seem to really dislike the GUI for some reason. Which is a fine opinion, but not one where I'd consider their expertise to hold much value over anyone else's (and personally, I disagree with).

> Here's another question to ask: "Is everyone really going to open a separate application, unlock the vault every time they want to use it (due to timeout), Ctrl+F for the URL, and then Ctrl+C out the username and password every time they want to visit a site? Also, is everyone going to create a correlated entry every time they make a new account?"

Okay, so here's how I use KeepassX for Linux:

The application is small and lightweight and therefore already open (but locked) as an icon in my systray. I have to unlock the vault due to timeout[0]. To find the entry, type a few characters in the search box, or select it from the appropriate category/folder, I put the few ones I use most in the default/top folder for even quicker access. Then I right-click the entry and select "perform autotype". Done.

"Perform autotype" seems to basically send a bunch of keyboard events: , [username], , [password], . This sequence works every login form I use. There's probably exceptions, but iirc you can configure the autotype sequence. Otherwise for that one login form that is weird and annoying you can always right-click and use "copy username/password to clipboard" (which is auto cleared after X seconds). Finally if the login form won't let you autotype AND doesn't let you paste, it becomes even easier: right-click, "delete entry" and never use that service again because COME ON, really.

edit to add: the Android app, Keepass2Android is slightly more cumbersome to use, but that's mainly because I find touch screen typing my master password a bit of a pain. After that it's actually easier, when you selected the entry, you select Keepass2Android as keyboard app, which only has these buttons: [User], [Pass], [Next field], [Submit]. At entering the master password there's also a checkbox "allow quick unlock", which allows you to unlock using only the last 3 chars of your master password (for duration of a second, longer+configurable, timeout).

[0] Do other password managers get around this? I really don't see how, without getting the same exposure as I would get by disabling the timeout in KeepassX?

The https thing is unfortunate and should be fixed, but I've always got my KeepassX from a signed repo.

The cobbling together is also an important part of its strengths. In particular I want the sync of the encrypted DB to be decoupled from the app that decrypts and manages the password entry into forms (the latter being yet another entity, btw).

I'm really curious to see that FAQ entry! Because I can't imagine a scenario where timing sidechannel attacks would be relevant to a password manager app (provided the sync is decoupled, which is one reason why that's so important). If you're gonna bruteforce the master key, you'll use an external program any way, so constant time comparisons in Keepass's routines shouldn't matter? Also it's not like you could remotely trigger Keepass to decrypt 1000s of times in order to glean info from timing data, because it's not a browser plugin. Which is one of the reasons why we don't want our password manager to be a browser plugin. Again, decoupling is a strength.

wait. the communication goes what way?? You make it sound like the 1Password extension (that doesn't handle encryption, therefore is not authenticated) can request password and credential data from the 1Password app, like it's pulling data from it?

How does the 1Password app know that whatever process is making that request is in fact made by that particular browser extension, prompted by user-action on the extension that is the same user as the one that unlocked the encrypted password vault in the app? And if it doesn't why are you storing your passwords in it :)

Are we all clear on what a password manager is? Maybe we should start with a good definition, such as:

A password manager is an application that manages an encrypted database, that when unlocked by the user, can be prompted by the user, to decrypt an entry from the database, and send one or more fields of that entry to a specified receiving application's input/login field(s). Communication only flows from the user prompting, to the password manager, to the receiving application. Not the other way around.

Ok that's not a full definition yet, it also needs a bit about how to store the encrypted database, how not to sync it, not keeping any keys or plaintext in memory any longer than strictly necessary, etc etc.

But it's good if we'd have a definition like that, something that is waterproof by definition.