1Password's use of Secure Input

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

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

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.

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

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.

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

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. :-)

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.

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