Any way to *TRULY* auto-fill entries without user intervention?

Thanks for the feedback, everyone! We can't promise anything of course, but our developers are certainly aware of your interest in these features. Thanks for letting us know! :smile:

Auto-fill is insecure. A specially crafted HTML page could capture a user's login if it is configured to autofill.

Go & Fill is usually a suitable alternative, and Ctrl+\ is never far away.

Please see this security paper: http://forum.stanford.edu/events/2014slides/security/Suman pwdmgr.pdf

Conclusion:

1. Existing autofilling password managers are less secure
2. Password managers can be strengthened by always requiring manual user interaction before
   triggering autofill

Hi, sorry for not jumping into this earlier.

You are not alone @mia! Lots of people have been asking exactly what you are asking.

There has actually been a long discussion all of this elsewhere in our forums. Ah, found it. It was a few months back in the Mac Beta Forums: "No Auto-login?" There is also a more recent (but much shorter) discussion of this in the Lounge: Schneier posts papers - one evaluates 1P

But because of security concerns we are disinclined at this time to offer, even as an option, the feature you (and so many others) are asking for. I don't want to repeat everything that has been said in that other discussion, but I do want to give you an overview of our reasoning for what might seem like an odd choice.

The short answer

Automatically filling a web form with no user intervention other than visiting the page can, if combined with something that works around the anti-phishing mechanism, lead to an attack where lots your usernames and passwords are submitted to a malicious site in a way that is silent and invisible to you.

The long answer

For this discussion, I will use the terminology adopted by David Silver and co-authors in Password Managers: Attacks and Defenses at the USENIX security conference. In the terminology of that paper, what you are requesting is "automatic auto-fill" instead of what 1Password does with "manual auto-fill". That is, 1Password requires some user intervention before it will fill a form (such as you typing Ctrl-\), while you would like it to do its filling simply when you visit a page.

We had anticipated the kinds of threats that Silver talked about. Indeed, in the actual slides for the talk, he used 1Password as an example of "how to do things right".

Anti-phishing mechanisms are not infallible

The security concern is with a malicious web page (or malicious content injected into a web page) silently collecting your passwords. 1Password along with every other password manager that provides some sort of auto-fill (automatic or manual) has a number of mechanisms to prevent filling into the wrong page. That is, if you go to a form at paypal.evil.com 1Password will not fill in a password saved for paypal.com because the domains don't match correctly. Tricking someone into giving filling out something like their PayPal password to something that only masquerades as PayPal is called "phishing".

But these sorts of defenses aren't perfect. A combination of how browsers, HTTP, and web pages are designed, we can't be sure that our defenses against that sort of thing are 100% certain. And this is particularly the case if the attacker is in a "network privileged position" such as the operator of (or someone who took control of) a public Wi-Fi hotspot.

Again, we work very hard to make 1Password do the right thing in such cases. 1Password's anti-phishing mechanisms work very well at preventing it from filling into the "wrong" web forms. But because of the nature of the HTML, iFrames, protocols, javascript, iFrames, conventions, page designs, and iFrames, the defenses that we (and everyone) has to use are messy, involving a series of rules and exceptions and exceptions to those exceptions. (Did I mention that iFrames are a trouble spot?) It is exactly the kind of thing that we know can go wrong.

Indeed, Silver et al. show a number of places where those sorts of anti-phishing mechanisms do fail (many of which have since been fixed in those products). 1Password came off quite well in that analysis, but the kinds of bugs that some other systems had are the kinds of bugs that any form filling system – including 1Password – could have. Quite simply, there are lots of different ways that some malicious page and network content could try to trick filling into the wrong site.

Invisible forms

The fields in which usernames, passwords, credit card numbers, and so on get filled won't always be visible to you. Any page could have a form on it that you don't see. If the designer of the form is attempting to trick a form filling mechanism, there is no way that 1Password could actually check to see if the fields really are visible.

So if the anti-phishing mechanism can be tricked, then when you visit a malicious web page (or one that has had malicious content added to it in transit), then you could have a password silently and invisibly stolen if automatic auto-fill is in place.

Sweep attacks

The malicious form could be designed to reload itself asking for a different password each time. So that is, a single malicious injection point could trick your automatically auto-filling password manager into giving up your passwords for many different sites. So not just PayPal, but also retail and banking sites, things like Gmail and live.com.

These are not just theoretical. Silver and his team demonstrated exactly this against a number of password managers. I should point out that he notified the vendors well in advance and only published his paper after they had a chance to fix the bugs in the anti-phishing mechanisms that were exploited.

But 1Password was completely immune to these kinds of sweep attacks, even if there had been problems with the anti-phishing mechanism. It was, and is, immune because we never silently fill a form without user intervention.

@davidhq and @reck, thank you for the suggestion. It's certainly an interesting idea! :)

Thank you @Jables, @davidhq, @reck‌,

I don't see any (substantial) security issues with having a way for 1Password to automatically (without user intervention) to signal whether a Login is available for a particular page. There is a minor concern that comes to mind, but I will put that aside. So that is definitely a feature request that falls into the "yeah, that is something we should look at" category. No promises, of course.

I'm not sure what the performance impact would be, and it can't be directly compared to what other systems do because we have a different design then many other systems which offer browser integration. Our design doesn't preclude such a feature, but it does mean that statements like "well it's easy for them to do it so it should be easy for you" don't really hold up as expected.

Fat versus thin browser extensions

With the move to 1Password 4 (for both Windows and Mac) we made the browser extension very "thin". In 1Password 3 (for Mac) and 1Password for Windows, with the 1Password JavaScript Extension (I will call that "JSE3" in what followed), the browser extension actually kept a copy of your Login data, processed your Master Password, decrypted data, etc. JSE3 talked to 1Password Agent (Windows) or 1Password Helper (Mac) only to synchronize the data within the the browser extension the main data in the 1Password program. So with JSE2, it was the browser extension that you interacted with, did a lot of cryptography, managed substantial amounts of data. Additionally it is what filled web pages or analyzed web forms for saving Logins.

That is too much going on in the browser.

The web browser is a hostile environment. It is filled with content from untrusted sources. So ideally, we'd like to have as few secrets and complexity of our code within the browser itself. Additionally, doing cryptography in JavaScript is a pain. For one thing, we had to keep the number of PBKDF2 iterations for data stored in the browser extension to relatively low numbers. There are other reasons as well why we would like to do as little cryptography in JavaScript as possible. For example, it is very hard to "free" strings in JavaScript.

From extension to Mini/Agent in 1Password 4

In 1Password 4 we moved almost everything out of the browser extension and into 1Password Mini (Mac) or 1Password Agent (PC). What is left within JSE4 is stuff that belongs in the browser (filling and analyzing web pages) along with communicating with 1Password Agent. The data and the cryptography and most of the user interface are no longer in the browser extension. (1Password for Mac 5 continues to use JSE 4).

Again, this design doesn't preclude what you are suggesting. Of of the top of my head, I can see how we might approach this with our current design. But I did want to take the opportunity to talk about this often hidden fact about our design. We are proud of how we've moved so much stuff out of the browser, but rarely get to display that pride.