Secure Input is Enabled

jms_1p

Note that I would have added to an earlier forum entry,
https://discussions.agilebits.com/discussion/comment/269613/#Comment_269613, but it was closed.

When attempting to enter text into a 1Password field (when editing a 1P item) using Keyboard Maestro, 1Password blocks the text entry. KM reports that Secure Input is Enabled and the message even suggests that 1Password is likely the culprit. When this occurs, the KM text entry is even blocked when switching to a different application (e.g., Text Edit). After closing the 1Password "edit" (using Save or Cancel), KM operation resumes as expected.

I understand that this is likely for security reasons, but is it necessary to prevent these attempts with all 1Password fields (e.g., Notes)? If the answer is Yes, might it be possible to add a text scratchpad (global to 1Password) that is unrestricted? If so, one could open the scratchpad, use KM (or TextExpander) as desired, copy the text, and then paste it into the desired 1Password entry field.

Thanks in advance for considering the issue.

---

1Password Version: 1Password Version 6.8.8 (688001) Mac App Store
Extension Version: 4.7.4
OS Version: 10.14.6
Sync Type: iCloud

Henry

Hi @jms_1p,

We use Secure Input all over 1Password for Mac to let macOS know that other apps shouldn't be able to see what you're typing into your vault. Users have the expectation that everything in their 1Password vault is protected from anyone other than themselves, so we do not disable Secure Input even for theoretically "less" sensitive fields like notes.

We've done our best to make sure that this is minimally intrusive for folks who use awesome time-saving programs like TextExpander (which we ourselves use) or Keyboard Maestro. However (recognizing that this isn't perfect), we don't currently have the means to disable Secure Input when you enter text into other apps while having an item in edit mode in 1Password in the background. Done otherwise, this could open up what you're typing in 1Password to more than just TextExpander.

I like the idea of the scratchpad, but to stop Secure Input from being active, the item would have to be saved and then re-edited. Unfortunately, I don't think there's a way to use TextExpander or Keyboard Maestro in 1Password.

In short, we've chosen security over convenience here—it's important that we take every precaution possible to make sure that what users type in 1Password stays in 1Password, private to them.

jms_1p

@Henry, thanks for the reply. Surely the smart and agile 1Password programmers :) could temporarily disable Secure Input if a user was using an embedded scratchpad (even if a 1Password item was in Edit mode). But, in the name of security, if there is even reluctance to do this, an embedded scratchpad would be more convenient than opening another program (e.g., TextEdit). The scratchpad could include a feature (or option) to automatically update the clipboard with the scratchpad contents when the user exits the scratchpad.

littlebobbytables

Hi @jms_1p,

I have no doubt that some users will feel some of the decisions made are a bit paranoid, the fact that 1Password will only work with whitelisted browsers is a common one but it is all done with the focus on keeping your data as secure as possible. As a user of Text Expander I do sometimes bump into this issue as well, especially when during testing filling when I'm often editing an item. Our approach is maybe a bit blunt but it is effective. The trouble comes if we try to get smart and a bug creeps in. The reward would need to justify the risk and I'm not sure it does here. One great thing about the forum being public though is if other people agree with you then hopefully they'll post and we'll realise there was a demand we didn't know existed.

jms_1p

@littlebobbytables, thanks for the reply. Earlier posts related to this topic have been closed. I'm sure this stifles feedback on a topic such as this. Also, I suspect that a very small percentage of 1Password customers read (let along write to) this forum. If AgileBits is waiting for an outpouring of support for my suggestion, I won't hold my breath. ;)

I'm not sure what is meant by "keeping your data as secure as possible." For example, our data would be more secure if all 1Password entry fields were masked like password fields. However, would that level of additional security be worth the user inconvenience?

From my perspective, the current Secure Input approach is like using a sledge hammer for a job that could be done better with a more delicate and refined tool.

AGAlumB

@jms_1p: Discussions are automatically closed after more than 6 months of inactivity. It's certainly come up in the past, but not frequently at all. We hear from thousands a week via this forum, email, and across multiple social media channels, about a wide variety of things, and far more often than they have issues with Secure Input, our customers are overwhelmingly concerned about the security of their data, and want to be sure it's safe in 1Password. Apart from the risks of introducing bugs with added complexity, trying to split hairs and say "your data is secure in 1Password, but only in these places and/or under these conditions" can unnecessarily confuse things for users. We know this from experience, because we didn't used to use Secure Input for everything. To be sure, it can be inconvenient for those individuals who both happen to use these kinds of tools and want to use them in 1Password itself, but that's not a large number of people. And because Secure Input is a great security feature that we can get "for free" on macOS, we have no plans to discontinue its use. Perhaps Apple will add more granularity to it in the future, or introduce something newer, but that's not within the scope of 1Password, and far outside the perspective of you and me, not being Apple engineers working on their OS.

jms_1p

@brenty, thanks for the reply. I appreciate the forum and especially hearing from the 1Password Team Members.

Unless there's some advantage of closing a thread, I suggest leaving them open indefinitely.

Does AgileBits need added granularity to activate and deactivate Secure Input? As it is programmed now, Secure Input is deactivated when a 1Password item is closed (from Editing). I suspect that Secure Input could also be deactivated if the user's cursor was in a less-sensitive field (e.g., notes). If so, is that the level of complication that AgileBits prefers to avoid?

AGAlumB

@brenty, thanks for the reply. I appreciate the forum and especially hearing from the 1Password Team Members. Unless there's some advantage of closing a thread, I suggest leaving them open indefinitely.

@jms_1p: I'd agree with you in principle, but leaving old threads with outdated information open does more harm than good in practice. And, frankly, there's a consideration for those who started/participated in a discussion, like the one you referenced from more than two and a half years ago, getting email notifications in 2019 if and when you or someone else resurrect it. Similarly, this thread can remain open for a time, but if there is no activity for more than six months, it will likely be closed (I say "likely" because it's possible that setting could be tweaked at some point, if it's deemed necessary).

Does AgileBits need added granularity to activate and deactivate Secure Input? As it is programmed now, Secure Input is deactivated when a 1Password item is closed (from Editing). I suspect that Secure Input could also be deactivated if the user's cursor was in a less-sensitive field (e.g., notes). If so, is that the level of complication that AgileBits prefers to avoid?

I considered mentioning this earlier but thought it was a bit too far into the weeds. But since you mentioned it, yes, there's additional complexity with trying to do something like that, but not only for 1Password. Secure Input isn't our feature. It's built into the OS, so we don't have control over its granularity or behaviour, and, frankly, when it's enabled and disabled rapidly (as is the case navigating between different fields, some using Secure Input, some not), it doesn't always disable as it should. Sometimes I've got to restart macOS to get it working again when it gets "stuck", as TextExpander will not work anywhere because a password field in Safari invoked Secure Input but did not release it afterward. So not only is using Secure Input when interacting with text fields in 1Password more secure (as opposed to discriminating and saying "we don't care about this field, only that one"), it's more reliable this way. And, of course, it's always possible that if we're trying to do a dance like that, the added complexity in our own code can result in bugs. So, given all of that, I do think it's best to have 1Password activate Secure Input in its text fields when adding/modifying data in items. It keeps things working consistently, and the user doesn't have to second-guess themselves either. "Is the text I am entering in this field safe, or not?" is not really a question we want 1Password users to have to ask, and from experience that's what most users expect.

jms_1p

@brenty, I appreciate the detailed explanation!

Working around someone else's bug (e.g., the macOS Secure Input behavior you described above) is no doubt frustrating and a bit risky.

Sounds like folks like me that want to use TextExpander and/or Keyboard Maestro will need to: 1) take the 1Password item out of Edit mode, 2) Open a text handling application (e.g., TextEdit), 3) Use TextExpander/Keyboard Maestro within the text editor, 4) copy the contents of the text editor, 5) change the 1Password item to Edit mode, and 6) paste the clipboard into the desired 1Password field (e.g., notes).

For those that have Unclutter (included in Setapp), the six steps above can be streamlined a bit: 1) take the 1Password item out of Edit mode, 2) Display the macOS clipboard using Unclutter (it can be accessed from the macOS menu bar) 3) Use TextExpander/Keyboard Maestro to modify the contents in the clipboard pane, 4) change the 1Password item to Edit mode, and 5) paste the clipboard into the desired 1Password field (e.g., notes).

AGAlumB

@jms_1p: Likewise, thanks for the detailed workaround! I wouldn't have thought of putting those particular "pieces" together myself. I haven't actually tried Unclutter yet, but that sounds really cool. :) I'm sorry that we don't have a solution for this that doesn't just cause other problems, either from a security or usability perspective. But it's something we'll continue to evaluate as things develop. Thanks for your understanding, and for your encouragement in this area. Perhaps there will be a smoother solution in the future. :+1:

HenryTheFox

After installing 1Password, I run into the issue with secure input aswell. The only solution I see so far is to cancel my 1Password account.
It happens so often it's very annoying.

It seems that 1Password is activating secure input also when it's not in use! That the main thing which struggles me the most!

I really appreciate it if you have a solution for me! I personally want to use 1Password instead of LastPass because 1 Password seems to be a bit more professional. But with these problems, I can't use it without running in this secure input issue.

Thanks a lot!

Ben

Hi @HenryTheFox

How are you dismissing 1Password when you aren't using it?

Ben

HenryTheFox

Hi @Ben
thanks for your reply. That's the thing, I already dismissed 1Password.

Just to clarify I'm using "aText" also on macOS, it works similar to Keyboard Maestro. And the error message is also related to secure input. I just mixed it up, because I found the "secure Input" issue related to 1Password often with Keyboard Maestro. And because both apps are doing nearly the same I think my problem is related to the problem from @jms_1p

I never ran into this problem since two days ago, the day I sign up for 1Password and also installed 1Password as App von my MacBook and also as an extension for my chrome browser.

It's also very hard to reproduce the error. Here is a diagnostic screen I found in aText which shows the process which enabled Secure Input:

I write it done:
"Secure Input is enabled (by loginwindow).
Try quit this app to release Secure Input.
If it is unkown, try quit your running apps."

As I said it's very hard to reproduce. Often it's working for two hours, and then for no reason, this error occurs. Also, a new start of the system will not help. On the next day: The error is gone

Ben

@HenryTheFox

thanks for your reply. That's the thing, I already dismissed 1Password.

Yes, I understand. My question was how you're going about doing that? E.g. Are you using ⌘Q, or ⌘H, or ⌘W, or clicking on the red close bubble at the top left of the 1Password window, or something else?

It's also very hard to reproduce the error. Here is a diagnostic screen I found in aText which shows the process which enabled Secure Input:

loginwindow is not part of 1Password.

Ben

AGAlumB

@HenryTheFox: For what it's worth, it sounds like an issue with Secure Input in macOS itself. I've had Text Expander correctly tell me that Secure Input is enabled, but it often gets incorrect information from the OS about which app has enabled it. Usually it's Safari, but it will say 1Password, another browser, even iTunes. I know it wasn't those because quitting them had no effect; only quitting Safari did. very odd. Anyway, this isn't something any 3rd party app has direct control over. They just call the Secure Input API, and the OS does the rest.

HenryTheFox

@Ben and @brenty
thanks a lot for this information! I will keep an eye on this problem. Figuring out which program is blocking aText.

@Ben I was just using 1password through Google Chrome. I closed google chrome correctly (using ⌘W) and to make sure it's closed, I right-click in the dock on the chrome icon and clicked on "quite". But I will make sure in the future that I close the apps correctly.

I'm the only one who wants to blame apple for that?

Ben

We try not to point fingers when we can avoid doing so, but this is an area in which we're fairly limited in our ability to solve this directly. :)

Ben

HenryTheFox

Hi, @Ben I totally agree with your statement!

Therefore we should close this thread because the problem is caused by the blocking (or not secure input releasing) software.

For everyone who has the same problem as I have: I just tried to close "loginwindow" (or the process which is using secure input) If I kill this process. macOS will close every open application and throw me out of my system. Then I just see the login prompt like I see when I freshly start my system.

After login, the same error occurs. So I have to finger point to Apple? It's really frustrating.

But props to you @brenty maybe aText just get wrong information about which program is blocking "loginwindow". But I guess with the statement you see in my screenshot above I found the process which is using secure input (maybe it is "loginwindow"?). Sadly killing this did not solve the problem.

• ioreg -l -w 0 | grep SecureInput

I know this is not related to an issue to 1Password, but I appreciated it if someone has an idea how to solve this issue.

So long...
Henry

Ben

I know this is not related to an issue to 1Password, but I appreciated it if someone has an idea how to solve this issue.

I'll leave the thread open in case anyone wants to chime in on that point. :+1:

Ben