1Password's use of Secure Input

System

This discussion was created from comments split from: Beta #10 of 2022 is now available 🏄🏻 🙌.

hvarun87

another strange issue when opening up logitech Logi Options app for my mouse, getting this error w.r.t 1 password.. please look into it.
Error Redirects here: https://support.logi.com/hc/en-gb/articles/4411277511063

volts

I just permanently lost actual note data because of this.

I was editing an item in the main 1Password window, so I had text selected.
I clicked to open Calculator.app from the Dock. It appeared on screen.
The keyboard focus unexpectedly stayed in 1Password.
I began typing my arithmetic sums.
This overwrote the text selection in 1Password.
I had to switch to Calculator.app a second time to make it active.

---

Focus theft occurs on the Master Password screen too.

Quit 1Password completely
Open 1Password to the Master Password entry screen
Click to open another app from the Dock
Wait for the app to open
Hit Command-Q to quit the other app.
1Password quits instead.

volts

I'm guessing this is a side effect of SecureInput.
This behavior happens when any text field in 1Password is active.
And when any text field is active, Secure Event Input is enabled.

1Password 8 uses SecureInput very broadly. Even the Keyboard Shortcuts fields activate SecureInput!

 

while sleep 1; do ioreg -l -d 1 -w 0 | grep SecureInput; date; done

 

Do ALL fields need to enable SecureInput?
Or maybe just the Master Password and other Password fields when they're masked??

• Safari only enables SecureInput when entering text in masked Password fields, not when they've been revealed
• BitWarden also only enables SecureInput for Password fields while they're masked
• The macOS/Safari password manager doesn't mask Passwords, and doesn't enable SecureInput

 

Does the Search field need to enable SecureInput? I don't think it should, and it's the most annoying.

• Quick Access doesn't enable SecureInput for the search field
• Neither does 1Password 7
• Neither do the browser extensions
• Neither does the macOS/Safari password manager
• Neither does Keychain Access
• Nor BitWarden or LastPass
• https://developer.apple.com/library/archive/technotes/tn2150/_index.html

 

Notes fields are also annoying. No other apps enable SecureInput for Notes fields.

 

I'm curious what threat is being addressed.

---

 

Interestingly, the macOS and Safari password managers use SecureInput for initial unlock, but they don't prevent a newly-launched app from getting focus, which comes full circle to my original post. :-)

Ben

Hi @hvarun87

another strange issue when opening up logitech Logi Options app for my mouse, getting this error w.r.t 1 password.. please look into it.

1Password utilizes Secure Input in order to protect your data. It seems some aspects of Logitech's software and hardware are incompatible with Secure Input. For example, with my MX Master 3 I'm unable to scroll while Secure Input is enabled, if the mouse is connected via Bluetooth. The issue does not present itself if the mouse is instead connected using the included RF dongle. Very strange — and not behavior I've personally seen from any other mice. This happens with all applications that use Secure Input. It is not limited to 1Password. Other than not using Secure Input (which is a non-starter) I'm not sure there is anything we can do on our end to improve the experience here.

the unsecured sites are not getting detected in watch tower.. i have a unsecured password account in my list. but when I go to watchtower and filter unsecured sites, it doesn't show up there.
This is working well on the 1Password 7 app from app store on mac.

Interesting. I'm seeing a discrepancy as well. 1Password 8 for Mac:

1Password 7 for Mac:

I'll check with our engineering team and see what the reason for the difference might be.

Ben

volts

Other than not using Secure Input (which is a non-starter) I'm not sure there is anything we can do on our end to improve the experience here.

That dismisses an obvious option: Use Secure Input for masked password fields only.

Or provide an option: Use Secure Input for: All fields vs. Masked password fields

I don't understand the current reasoning. Secure Input breaks accessibility tools and input devices. Secure Input also changes basic macOS window-stacking and focus behavior. But it doesn't provide a meaningful increase in security against malicious actors. It isn't intended to be a protective bunker.

Or am I missing something?

Secure Input does protect against well-behaved user processes that have been granted specific Accessibility permissions. If that's considered a serious threat, 1Password could alert the user when a new event tap is detected.

But the clipboard is always available to other user processes, without any additional privileges.

And screenshots don't require privileges. (Malware often takes screenshots when Secure Input is toggled!)

Secure Input doesn't protect against processes that have been granted Screen Recording. Or processes that use Accessibility to control the system.

And Secure Input can't protect against more insidious or privilege-escalating malware, anyway.

So I guess I don't get it.

Ben

I see your point, @volts. I think there is some argument that we could use Secure Input less than we currently do (though to be clear I don't know which way that argument would go). But ultimately we'd still be using Secure Input some, which will trigger this situation with Logitech mice.

Ben

volts

Agreed! It certainly should be used for the appropriate fields - and Apple and everybody else uses it for password entry, so Logitech should (hah!) work appropriately, too.

Enabling Secure Input for the Search field, and even for keyboard shortcut settings, feels over-broad.

Ben

I'm not sure I agree. I don't think I need TextExpander, for example, to know what I'm searching 1Password for. I say that with zero disrespect or distrust of TextExpander — I've been a user for a long time — but it simply doesn't need to know that information.

Ben

Ben

Hi folks,

I've split & merged a couple of threads here which all center around the same subject: how, when, and why 1Password uses Secure Input. I will bring this subject up with our security & product teams for further review, to see if perhaps we can lessen our usage.

Thank you.

Ben

ref: dev/core/core#13958

volts

Thanks! It makes sense as a standalone/consolidated thread.

This active discussion is directly related too: https://1password.community/discussion/comment/634645

Your perception of the importance of TextExpander (and other accessibility tools) working in 1Password is irrefutable. So that's a great point - if you don't need or use a13y features yourself they will have zero value to you.

They have significant value to others. I hope you'll advocate for accessibility even if you don't require it personally.

Jack.P_1P

Hey @volts:

Thanks for your additional feedback. As Ben mentioned, this is something we'll share with the product teams as we work to make 1Password the best it can be.

Jack

FogCityNative

I'm in favor of less security and more compatibility with Text Expander or Typinator.

Let's say someone has installed a screen grabber or keystroke recorder on my machine. Well, they're going to need to send that captured data somewhere where they can use it for malicious purposes. This is why I have Little Snitch and subscribe to rules that block known malicious sites. I have very minimal fear of security issues that would be worth giving up functionality and compatibility with Text Expander or Typinator or other such text macro programs.

Charles Butcher

Edit 20 minutes later: a second restart has fixed this on the M1 mini, to the extent that I can now use TextExpander while editing a 1Password entry. This all seems a bit random.

---

Another frustrated TextExpander user here. I’m struggling to understand how this behaviour with Secure Input is changing:

• as compared to 1Password 7,
• between the different versions of 1Password 8, and
• on different Macs.

In 1Password 7, for instance, I was accustomed to being unable to use TextExpander only while editing a 1Password entry. That seemed perfectly reasonable. So why is it necessary to change the way 1Password 8 behaves?

In 1Password 8, meanwhile, I’ve had occasional problems with Secure Input in the past, but for a while everything has been OK. Now with 8.8.0 80800126, Secure Input is not happy, and it’s behaving differently on two different Macs.

On my M1 mini (Monterey), Secure Input has locked up completely, even after quitting 1Password.

On my Intel MacBook (Monterey), Secure Input seems to be behaving as expected. However, 1Password is giving an annoying “That didn’t work…” message when I’ve made no attempt to enter a password. Not elegant.

Would it help if, in the 1Password login window, it were possible to move focus away from the master password field? When I’ve had problems in the past I’ve sometimes felt that that password field is holding the whole system to ransom.

Another strangeness: I’ve also previously found that TextExpander works when I am editing entries in 1Password 8. This is welcome, as long as it doesn’t compromise security, but doesn’t sound to me like expected behaviour :-)

Ben

@FogCityNative

I'm in favor of less security and more compatibility with Text Expander or Typinator.

I don't think it would be fair for us to assume that our customer base as a whole would agree here. I wouldn't suspect the majority use macro utilities and outbound firewalls. Security and convenience tend to be opposing factors. We try to strike the best balance for the most common use case. When there is no balance to be found, we do have a tendency to favor security.

@Charles Butcher

Would it help if, in the 1Password login window, it were possible to move focus away from the master password field? When I’ve had problems in the past I’ve sometimes felt that that password field is holding the whole system to ransom.

What would we move the focus to instead? I'd suggest in cases like this it may make the most sense to close the 1Password window. It is possible to keep the app running in the background without the window being open.

Another strangeness: I’ve also previously found that TextExpander works when I am editing entries in 1Password 8. This is welcome, as long as it doesn’t compromise security, but doesn’t sound to me like expected behaviour :-)

The only recent changes we've made that I'm aware of with regard to our usage of Secure Input are related to the search field. 🤔 I'll do some checking with my colleagues to see if anyone is able to reproduce this. Thanks for bringing it to our attention.

Ben

Ben

Just confirmed with one of my colleagues: we have reduced our usage of Secure Input in 1Password 8. We no longer activate Secure Input in username, text, address, or notes fields. We also no longer activate Secure Input in the search bar. It will continue to be activated for the most sensitive fields such as passwords.

Ben

FogCityNative

Good news. Most websites use my e-mail as my user name. My e-mail is public knowledge. I use Typinator to type my long e-mail address by typing a three letter code. 1PW was blocking that and now it won’t do that anymore. I am happy with your decision. As long as 1PW can paste my password I don’t need Typinator to make any entries to a password field. That is the function of 1PW.

Charles Butcher

Thanks @Ben – although I found this issue hard to reproduce, it did cause me some problems. I assume the changes you refer to have appeared in version 80800143, and I certainly haven't seen any problems recently. Great work!

volts

Big improvement! Thank You @Ben and all involved.

Ben

Glad to hear the improvement has helped! ❤️

Ben