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

2»

Comments

  • kathampykathampy
    edited October 2014

    I want this as well. Just show a bubble count on the extension (or the system tray icon for IE) to indicate if a saved password is available. You'd only need to check every time a URL is loaded in the main window. It shouldn't be anymore demanding than detecting every form submission to auto-save passwords.

  • Drew_AGDrew_AG AG Alumni

    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:

  • After some more experience with 1Password I also think that this and something else (https://discussions.agilebits.com/discussion/comment/153539) are the only things missing for this product to be really incredible, get out of my way and just work. It's very close and that's also why I'm taking the time for reporting my wishes.

    And here, as well as in the topic about entering master password again for revealing passwords, this should be optional... and if developers feel this is not a good default, then they would just ship with defaults they feel are appropriate... but yes, there really should be completelly automatic logins... this is the real magic, not pressing a key combination to make it work.

  • Davidhq I agree with you but the Devs seem like they don't.
    This is the biggest functionality I miss from last pass is truly no handed password fill and submitting. One can hope

  • I'm optimistic :) Do devs also oppose adding this with default = disabled?

  • edited October 2014

    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
  • svondutch,
    Are you saying that Lastpass's style of password management is inherently insecure?

  • How is auto-submit secure then?

  • edited October 2014

    @mia Not at all. I was simply quoting this security paper: http://forum.stanford.edu/events/2014slides/security/Suman pwdmgr.pdf

  • jpgoldbergjpgoldberg Agile Customer Care

    AgileBits Team Member

    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.

  • Great explanation. I stopped wishing for that feature.

  • Yes, agreed. If it is a potent security concern, I would say leave it until something more secure can be figured out.

  • DBrownDBrown AG Alumni

    Thanks for the feedback!

  • But now my suggestion for some indicator when 1Password is able to act on the page is even more relevant... the best would be if extension icon would change (get) color as someone suggested...

  • Yes an indication change when a login is available would be great. As you say changing the the 1P browser icon would be ideal. When I used Roboform their browser toolbar used to update depending on if logins were available or not and it seemed to work fine, so it can be done.

  • Drew_AGDrew_AG AG Alumni

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

  • DBrownDBrown AG Alumni

    In the meantime, you can press Ctrl+\ at any site's login page. If you have a Login item saved for that URL, 1Password will use it to fill the form with your saved credentials.

  • @jpgoldberg‌ I love it when you show up in threads and explain away the feature I came looking for. Two-factor authorization last night, and automatic auto-fill this morning. Thanks for taking the time to be so thorough, and understanding that many power users want more information than the cursory deflections about security concerns or performance issues (or the "if you look again, we never said it could do that" response).

    I also agree with where this left other end-users in this thread. I would like some kind of indicator that 1Password has data for the site I'm on, without having to interact with the browser plugin/add-on. This is a seemingly ubiquitous (obviously not quite) feature in the password manager ecosystem, so I struggle to see the performance argument. And, I don't think the security concerns apply in this capacity.

  • DBrownDBrown AG Alumni

    Thanks for the feedback, @Jables!

  • jpgoldbergjpgoldberg Agile Customer Care

    AgileBits Team Member
    edited November 2014

    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.

2»
This discussion has been closed.