Security based extensions/ content blockers

1pwuser31547

Hi.
Can any you comment on benefits adding content blockers like umatrix, noscript as well as HTTPS Everywhere extension?

Do they add any significant security value when your browser is configured at enhanced security level (i.e, Chrome Enhanced Protection)

I have a general rule that I do not install any extensions in any browser in which the 1 pw extension is already installed for fear of them being compromised and so putting my data at risk.

However these extensions are designed to increase security. For example Noscript for Firefox is configured to help prevent XSS attacks.

Thanks

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Ben

I think this is really a case where you'd need to do some research and weigh the risk vs benefit. Here at 1Password we're generally not in a position to make recommendations about specific 3rd party software. We do recommend extreme caution about what browser extensions you install.

Ben

1pwuser31547

I understand.
Thanks

Ben

You're welcome. Sorry I'm not able to be more specific here.

Ben

1pwuser31547

Ben,
As a follow up to this, can you briefly explain how the extension communicates with the desktop app?
I understand there's a long term encrypted secret shared and authenticated between the two.
What is the strength (bits/entropy) of the secret?
If I remove then restore the extension later for a new session, is a new secret generated? Is there any significant security value in doing this?

Also, does 1 password support auto typing passwords (simulated key presses) in lieu of browser extension generated autofill?
I couldn't find this feature on your website.
This would useful for entering credentials in apps and also provide an alternate way to enter them into websites.
(Yes, auto-type is vulnerable to keyloggers, but I'm assuming my device is secure.)

I've read a lot about extensions and how they relate specifically to password managers.
As you know, many if not most of the past vulnerabilities of password managers relate to attacks on password manager extensions.
I would think this vulnerability is more significant for password mangers that exist solely with in the browser.
It seems likely that future attacks would focus on this browser integration.

I understand that 1 PW has done much to make autofill as secure as possible (manual/user initiated autofill, strict HTTPS/URL matching...)
Nonetheless an extension still does present an attack vector which is much more out of users' control.
If autotype were available, it would help mitigate this particular threat model.

Thanks

Ben

@1pwuser31547

The browser extensions connect to the 1Password apps using Native Messaging. As part of the connection handshake the app's code signature is checked against a list baked into the 1Password apps. If the signature does not match, the connection is dropped.

We do not offer auto-type as a solution at this point. That may be something for future consideration.

The weakest link here is that many extensions ask for fairly broad permissions, which may enable them to read the contents of web pages. This includes the data filled into forms, such as passwords. That would be the biggest risk / most obvious attack vector here: an extension installed in your browser that either maliciously or ignorantly collects form data (including passwords) from web pages once 1Password has filled.

I'm going to ask our security team to follow up and fill in some of the specific implementation details. :) It seems there may be a fair bit to this, so please give them some time to respond. :+1:

Ben

jpgoldberg

Those are some excellent and tricky questions, @1pwuser31547,

In part you are referring to a technology that we no longer need because browsers have developed more secure ways to communicating with native applications.

A history lesson

Can you briefly explain how the extension communicates with the desktop app?

Well, the details differ a bit from browser to browser and from OS to OS. I am pleased to say that we no longer user web sockets. One of the difficulties with web sockets is that any user process on the system could try to talk to it, and any user process on the system could launch a web socket. So we had to go through a lot of contorted stuff to provide a modicum of mutual authentication between bona fide 1Password browser extensions and the bona fide 1Password Helper/Agent. This was harder to achieve on Windows than on Mac, and so we developed a system in which users had to initially add a verification code when they first set up the extension. Thankfully we no longer need to do that.

I understand there's a long term encrypted secret shared and authenticated between the two. What is the strength (bits/entropy) of the secret?

There isn't any more. And the encryption was never the important part anyway. An attacker who had the power to read the traffic would almost always have the power to get the keys. So the encryption on that communication didn't really do much. The important part was the mutual authentication. For this, the shared authentication key was 256 bits. The two parties would generate random challenges for each other to each prove that they had the shared secret, but they never transmitted anything secret.

The session key (for encrypting the traffic) was created as a function of parts of the random authentication challenges and the long term secrets. It was also 256 bits. There were some complications because the crypto libraries we were using for 1Password 4 for Windows at the time didn't support GCM mode. So we had to use an Encrypt-then-MAC construction to get Authenticated Encryption.

If I remove then restore the extension later for a new session, is a new secret generated? Is there any significant security value in doing this?

When this was originally deployed, you would have need to go through the manual verification process again. But as browsers and Ones gave us better ways to knowing that each side was only talking to who it should be, we simply removed the verification and let the two sides just agree on a new secret without user intervention.

We (well, mostly me) made a decision at that time that I came to regret. By removing the manual user verification, this whole mechanism added no real security. I argued that we leave it in just in case we need to come back to it for some reason. Anyway some researchers reverse engineered the protocol (had they asked first, we would have sent them the full specification for it) and noted that without the user verification it did no real good. They correctly poked fun at us for that. I had to sit in the audience at a USENIX Security conference where people, just looking at the protocol as it stood after we removed user verification and hear who this complicated thing provided no real security.

But again, the good news is that with native messaging and our checks on the code signatures of the browsers, we don't need any of that.

Also, does 1 password support auto typing passwords (simulated key presses) in lieu of browser extension generated autofill?

We have done this in the past, but again it was back in the days when we didn't have a better way to communicate with browsers. While it certainly is useful for getting 1Password data into non-browsers, as you mention, it becomes yet another way data leaves 1Password that we need to secure. I'm not saying that we won't bring it back, but we prefer to simplify things as much as possible. We have to track security development and threats to all of the things we support, and it is just one more thing to track and secure.

As I mention much further below, there is a very good security reason for encouraging autofilling in the browser. If we could realistically eliminate the need to copy/paste we would. (We can't, and so we won't.)

The browser is a hostile environment

I've read a lot about extensions and how they relate specifically to password managers. As you know, many if not most of the past vulnerabilities of password managers relate to attacks on password manager extensions.

We have built and designed 1Password with the full understanding that the browser is a hostile environment. Many of the attacks had been around tricking the password manager to fill in (silently and invisibly) credentials without user knowledge or consent. This is why we never offered an option for automatic autofill. A couple years ago, after related attacks (which 1Password was not vulnerable to), got some press attention, the rest of the industry started to catch up and remove (or make non-default) their automatic auto-fill stuff. And I got to write a "we told you so" article for why we never allowed that feature. See 1Password Keeps You Safe by Keeping You in the Loop

Web pages are hostile environments, but browser offer better protection

I would think this vulnerability is more significant for password mangers that exist solely with in the browser.

There is a reason why 1Password X is a relatively recent creation. For a very long time, we wanted to keep user data as far away from the browser as possible. But browser security models have greatly improved, and so we felt that we could maintain the separate we needed even within the browser. 1Password X has different internal components, and the one that interacts with the web page itself has very limited and well-defined ways to talking to the components that are capable of decrypting your data. In a sense we were able to use new browser security architecture to get the kind of separation that we have between 1Password native app and extension.

It seems likely that future attacks would focus on this browser integration.

Attacks on the communication between the browser extension and the 1Password native app are attacks on interprocess communication on the user's machine instead of attacks on the extension from within the browser environment. This means that they require a compromise of the user's machine, instead of a malicious web page. While we do take those steps that we reasonably can to defend users against malware running on their own machines, there are real limits to what we can do there. So please, keep your systems and software up-to-date. That is the single best thing you can do keep malware off of your machine.

Autofill and phishing prevention

If autotype were available, it would help mitigate this particular threat model.

It would increase other threats. In addition to the convenience there is an enormous security advantage of autofill over either copy/paste or auto type: Phishing protection. When a user decides which field on which page a secret it to be entered into, the user can be fooled by a phishing site. With 1Password autofill, the phishing site has to fool both the human and 1Password. This is one of the very substantial security advantages of a password manager with browser integration that most people overlook.

This is actually one of the reasons why I chose 1Password (or what it 1Passwd back then?) as my password manager a dozen years ago. The browser integration not only made it something I would regularly use, but also served that security function. (And it was so much better than the one I was trying to roll for myself.)

XIII

I love reading these elaborate answers from @jpgoldberg.

Can we get an RSS feed for them?

Ben

@XIII

I'm not sure there is a way to turn it into an RSS feed, at least not without a 3rd party service, but it is possible to see all of Jeff's answers here:

https://discussions.agilebits.com/profile/comments/jpgoldberg

:)

Ben

williakz

@XIII : Hear! Hear!

1pwuser31547

Ben and Jeff,
Thanks so much for those explanations. It's very helpful to learn the historical context around how and why things are the way they are.

To follow up: Since user intervention is critical to the security of autofill, is there any benefit to creating a separate entry for username and password for those really sensitive sites, thus requiring the user to click autofill separately for username and password?
This would of course be more inconvenient but would add another layer/step of user intervention.
This is already built in for sites with 2 page log in like google/gmail.

If there is a security benefit in this, then would you consider (in future updates) setting up autofill that requires another click to autofill password after username is filled, (rather than needing to create a separate entry for both as is the case now)?

I think it's great that currently the user must click enter to submit the credentials after they're autofilled rather than the password manager automatically submitting them.

@jpgoldberg "It (auto type) would increase other threats. In addition to the convenience there is an enormous security advantage of autofill over either copy/paste or auto type: Phishing protection."
Definitely phishing protection is one of the most important reasons for using autofill. However auto type can be configured to type the URL then username/password.

jpgoldberg

Since user intervention is critical to the security of autofill, is there any benefit to creating a separate entry for username and password for those really sensitive sites, thus requiring the user to click autofill separately for username and password?

Interesting question. There may be some marginal gain in having people go through that twice instead of once, but we have to ask whether it is worth it. The difference between no user approval and some user approval is a lot greater than the different between user approves once versus twice. Yet the increase of burden on the user would be substantial. (Ideally, it would be nice to conduct actual user studies than relying on intuition of this, but my intuition is guided by having read lots of user studies on other things.)

Definitely phishing protection is one of the most important reasons for using autofill. However auto type can be configured to type the URL then username/password.

It is true that someone could use copy/paste or auto type in a way that helps thwart phishing, but one principle of usable security is to build systems in which the easy thing to do is the safer thing to do.

If you don't mind my asking, I get the feeling that your interest in auto type goes beyond what you've said here. If you have a way of working for which auto type from 1Password would really be a very good thing, please help us understand that. There is a case for bringing back auto type, in particular, we'd rather have people use that than copy/paste in the situations where autofill can't be used. But the complexity of and confusion of maintaining and presenting three different ways to get information about of 1Password doesn't appear to be worth it at this time.

Autofill is the easiest and most secure thing for people to use in most circumstances. Copy/paste is an unfortunate necessity in some cases. Adding a third, unnecessary option, will make it less likely that people will use the best option in the cases where the best option is available.

1pwuser31547

First, in my opinion, 1 PW should be able to fill credentials into an app without needing to copy/paste.
Since (some not all) other password managers can do this without copy/paste, it should be reasonable to expect that 1 PW should be able to do this as well.

Secondly and most importantly, I want to know what's the most secure and convenient way to supply credentials to a website from a password manager- autofill using an extension or autotype.

@jpgoldberg
"Attacks on the communication between the browser extension and the 1Password native app are attacks on interprocess communication on the user's machine instead of attacks on the extension from within the browser environment. This means that they require a compromise of the user's machine, instead of a malicious web page."

This was my most pressing concern that simply visiting a website infected with malicious scripts or malvertising, into which I had to supply credentials for account access (via autofill) could potentially be enough to compromise my entire database. So what you say here is very reassuring since compromising a user's device is a much bigger hurdle than simply visiting a compromised website.

However, it still seems to me that since web pages are a hostile environment, any program that resides in a browser, like an extension that can read and write all of your credentials, inherently or at least theoretically is more vulnerable than one that does not reside in a browser.
Is this a false statement or an oversimplification?

If not, then my question is that since autotype doesn't require an extension and is simply acting as a keyboard (as I understand it) and if it can be securely implemented then doesn't this method have the potential to be an even more secure way of supplying credentials than using a program residing in a browser?

jpgoldberg

Thank you @1pwuser31547.

As in many cases, there is a security v security trade-off. The anti-phishing advantages of having something in the browser does come with the risks associate with having something in the browser, as well as having to worry about inter-process communication. The convenience of browser integration also has a security advantage in that it will make it more likely that people will actually use their password manager.

We have opted for the security advantages of a browser extension over the security advantages of staying entirely out of the browser. I believe that this is the best design for the overwhelming majority of our users. I do acknowledge that it may not be the best design for a user who will always use their password manager even without the browser integration and will take additional steps to avoid filling credentials in to phishing sites, but I also think that you may underestimate the burden of the latter.

Before I started using 1Password a dozen or so years ago, I had rolled my own password manager. It did not have browser integration. The consequence is simply that I didn't use it nearly as much as I should have, and so I had much more password reuse than I wanted. And keep in mind that I was a user who understood the importance of using a password manager and of avoiding phishing. I'm not saying that you wouldn't do better than I did, but I do think that it is the rare user who will do well without the browser integration.

1pwuser31547

Thank you so much you for that explanation @jpgoldberg.

I agree with and understand what you're saying especially " The convenience of browser integration also has a security advantage in that it will make it more likely that people will actually use their password manager."
I've been trying to get my family members to use a password manager - it's fair to say it's been a steep, uphill struggle.

I agree that phishing is by far the most serious threat. Reading about some of these spoofing techniques (like homograph attacks for example) is really eye opening. Threats like these and more will certainly evolve.

I'm digressing here but as a security product, maybe you can consider making an educational page, regularly updated about best security practices and cyber threats both present and evolving. Maybe it can be pushed to client apps? There's a lot of great information scattered throughout in these forums.

However I would still like to ask why you are seriously considering implementing autotype for Windows and not for MAC.
"Auto-type feature in new Windows app [coming in a future update]"
Is there an OS limitation?

If not, then I would request that you consider implementing autotype for MAC in future updates, at least for the sole purpose of filling credentials outside of browsers such as client apps and virtual/remote desktops, which I feel is a core functionality of a password manager.

Thanks. I really appreciate the dialogue.

1pwuser31547

@jpgoldberg
Sorry to add one more question about autofill before your answer. I though it may save you some work in replying.

This may be a silly question but I will ask it anyway.

Does the way autofill is initiated by the user make any difference- clicking on the "autofill" in the extension versus by directly placing the cursor in the username and password fields individually (separate UN/PW entries created) and then while cursor is place, right clicking and choosing 1 PW option?

One of the concerns about autofill that I've read about is that credentials could be filled in invisible log in forms on the website and if there are malicious scripts involved, then there is the possibility of credentials being stolen.

So I was wondering if placing the cursor exactly where the autofill will occur would decrease the possibility of filling in invisible fields, like in an iframe and make it more likely filling will occur where the cursor is placed.

I know with user generated autofill as you implement, sweep attacks don't affect 1 PW. But preventing filling in invisible fields seems to be more difficult to prevent, at least as I understand it.

Thanks again

1pwuser31547

Autotype fills security question fields; autofill appears not to.
So rather than copy/paste these very sensitive credentials, I imported them into another password manager that supports autotype.
Using autotype, the credentials were filled flawlessly.

Does autofill work for filling passwords for security questions?
I tried to do this by creating the credentials as both a password entry and as a log in entry (with username blank), both with exact matching of URLs.
The autofill tab was available but did not respond after clicking. This was the case whether the website required only 1 security question (thus one field to be filled), or multiple.
Is this a bug or is autofill only available for log in password fields, or am I doing something incorrectly?

I understand there's a bug currently where autofill overwrites the old log in password when trying to change a log in password.
I've only experienced this autofill bug with log in password changes, not when changing security questions (in which autofill is simply unresponsive). In both situations, autotype corrected this problem, without needing to resort to copy/paste.

Finally, is it possible to code autotype only when URL matches? This, I would think, would allow for phishing protection, as in autofill.

Thanks

AGAlumB

macOS and Windows are very different in this regard due to Secure Input in the former, enabled in all password fields. Drag and drop is a better option on macOS, whereas auto-type is more viable on Windows. But yes, having an auto-type feature at all is more problematic not only due to of the keystroke-logging aspect, but also because by its very nature it needs to be able to fill anywhere on demand, which circumvents phishing protections, and usability concerns on top of that.

Autofill, on the other hand, depends on the browser's APIs and how the website is designed, which is a good thing as far as avoiding the pitfalls of auto-type, but can be problematic in some contexts as a result, so it's constantly evolving. It's not officially supported, as there is no standard for this, but filing security questions can work in some cases. Autofill just isn't intended for pages without login forms, since its whole purpose is to fill login credentials saved in a Login item in 1Password.

Yes, auto-type could potentially be designed to fill only at a matching URL, but that defeats the purpose of auto-type in many cases, since the reason the user wanted it was to fill in a context where it wasn't a "simple" form on a web page in a browser, or they want to fill something completely arbitrarily; they'd just have used Autofill otherwise.

While it isn't feasible for us to be one-stop shopping for general security information, and others are already filling that need all over the web, we include information relevant to 1Password users specifically on our support site, and then have occasional blog posts on more general (but 1Password-adjacent) security topics on our blog -- https://blog.1password.com -- and of course you can find Goldberg and others here discussing specific topics that aren't universally relevant. Cheers! :)

1pwuser31547

Thanks for your reply.
Drag and drop however doesn't always work- I've encountered situations where the dropped credential (password) isn't accepted when the exact pasted one is.