@larrysalibra: LastPass is a fine design solution, and the cloud is a fine storage location for passwords as long as your master encryption password is ultra-secure. Heck, I'd happily ask the
NSA to
host my 1Password database, since my password is longer and more complex than anything they can crack in hundreds of trillions of years.
But LastPass suffers from its own flaws: Other extensions in the browser can read *any* passwords it injects into the website forms, since those extensions *also* have full rights to read the same forms and intercept them. Other apps can read the LastPass extension's binary password blob from the disk and guess various master passwords against it.
It'd actually be possible to secure 1Password Mini
a little bit more against impersonation by having its own built-in private SSL certificate and using SSL locally on the machine. It would, however, be possible to search through the Mini app's code and eventually find the certificate key, so it wouldn't stop the most determined hackers. This is the problem jpgoldberg pointed out: Anything they do can be reverse-engineered, since whatever "secret method" they use will have to exist in Mini.app and would therefore be possible for a hacker to discover. So adding more local authentication schemes is a bad idea.
Adding "The extension wants to talk to 1Password mini. Allow it?" is also a bad idea and achieves almost nothing.
Remember that no matter what happens, an impersonator app would break the browser extension since the extension wouldn't be able to load any existing passwords (and the impersonation is thus easily discovered), and would only be able to save "new" passwords (which you normally don't do manually with 1Password; you use "Mini"'s password generator to fill the signup form, and since Mini would not be running, you wouldn't be able to do that and would notice that things were fishy).
As we discuss this, never forget that jpgoldberg is extremely intelligent and that they were designing this to be impersonation-resistant from day 1. That's why no existing data leaks if you impersonate 1Password Mini. They also made sure to authenticate the app connecting to 1Password Mini, so that a local rogue app can't just connect to the 6263 socket and request all the passwords. It has to come from their extension on a valid browser. It *even* validates the code signature on the browser to ensure that it's not talking to a hacked browser with memory logging or other evil stuff.
But... I think the
real, true 31337 solution to 1Password's
very minor issue is to do this:
<code>
1Password Mini.app
..on start
....if port 6263 in use
......display dialog "oh no! hackers are using the port! don't input any passwords on the web!"
</code>
Remember that Mini launches on every system startup and would detect if the TCP port was already bound. Therefore this is a flawless solution.
Another solution: In the 1Password preferences, you could have a pane for dragging in a list of "allowed browser .apps", pre-populated with Safari and Chrome. As you drag apps in there, it modifies a OS X Keychain Access entry containing a random, mutual communication token, to allow those apps to access it. The extension (in the browser) then asks Keychain Access about the token, then connects to port 6263 locally, and asks Mini what its token is. If the token returned by "1Password Mini" matches what's in the Keychain, you can assume you are talking to the real Mini. If any other apps try to read the Keychain token, OS X will say "Do you want to allow app X to access token Y from the Keychain?", and would detect it. Funnily enough, this solution uses the exact
feature of the OS X Keychain (multiple apps sharing access to a mutual secret) that's being used by the laughable "exploit" discussed by this news article. This is also why I
don't think Apple is going to change the behavior of OS X Keychain - because there are too many legitimate uses for mutual app access to secrets; such as adding access to a password for both a main app and its helper app.
