Feature Request - Make Any Field Hideable

jamestalmage

A couple scenarios:

Scenario 1:

I use 2FA on a number of accounts, and many provide "recovery codes".
It seems the natural place to store these is in the "Notes" section of that particular login.
However, the notes section displays as in the 1Password-Mini popup.
I screen-share while developing, and that includes occasionally logging into an account with 2FA.
In this scenario, I've just shared my recovery codes with whoever I'm screen sharing with (and anyone watching).

Scenario 2:

I use a service that does not have a native app (only a webapp). Their solution for mobile is to provide a long, randomized https URL which can be saved as a shortcut on the mobile devices home-screen. Knowing the URL serves as your login to the mobile web-app. I don't love this obscurity as security approach, but I need the service. I want to save that as a URL alongside my login information for the site, but again - those are displayed in the 1Password-Mini popup.

TL; DR.

Every field should have an icon next to it that allows you to set it as hidden/visible by default.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Feature Request - Make any Field Hideable

Vee_AG

Hi @jamestalmage,

Are you familiar with the option to add custom fields? You can add those sensitive recovery codes and login URLs to a custom field rather than the Notes field, and set the custom field type to "Password" so it will be obscured like passwords are. Will this work for your needs?

jamestalmage

Some services provide a dozen or so recovery codes (separated by newlines usually). The password field does not work well in that case, since it does not handle multiline data well. My current workaround is to put them in a ".txt" file, and save as an attachment. It works well enough, but not super efficient.

I did discover custom fields after writing the original post. My only concern there is accidentally clicking the "generate" button in edit mode (something I did once and caught). For some services, losing your OTP device and recovery code means you are irrevocably locked out of that account. So wiping out the backup codes with a single inadvertent click is scary. It's less scary now that I can sink OTP keys across all my devices thanks to 1Password (which is totally awesome).

I guess maybe my real complaint is that it is too easy to wipe out an existing password with the generate button. I don't like having the generator button in the editor at all really. When is that useful? Using the top-level "Password Generator" link, and then confirming to overwrite after a successful password change is my preferred UX flow.

Drew_AG

Hi @jamestalmage,

The password field does not work well in that case, since it does not handle multiline data well.

That's true, but to be fair, password fields aren't meant for multiline data. The idea would be to put each recovery code in its own custom password field. But if putting them all in a text file attachment in 1Password works better for you, no problem! :)

My only concern there is accidentally clicking the "generate" button in edit mode (something I did once and caught).

I'm glad you were able to catch that! Keep in mind that the password generator button is only available once you click the Edit button for an item, and your changes won't be saved unless/until you click the Save button. If you accidentally click the password generator button, just click the Cancel button, then click Don't Save.

In case you're entering Edit mode in order to view a password field (since they're concealed by default), there's a much easier way to do that. Instead of entering Edit mode for the item, simply hold down the Option key on your keyboard to temporarily see the passwords.

So wiping out the backup codes with a single inadvertent click is scary. It's less scary now that I can sink OTP keys across all my devices thanks to 1Password (which is totally awesome).

There are a couple other options I wanted to mention:

If you accidentally change the main password field in a Login item and then also save the changes, the previous password is not lost - there will be show previously used passwords button in the item, and you can click that to see your previous password(s) for that item. You can copy it from there, then edit the item and paste it in the password field.

Now that only applies to the main password field, but if you accidentally change a custom password field and save the changes, you can restore your data from one of the automatic backups that 1Password creates. Just go to File > Restore, and you'll see the available backups and when they were created.

I don't like having the generator button in the editor at all really. When is that useful?

It's not part of my own workflow either, but some customers prefer to generate passwords within items instead of using the generator in 1Password mini. Lots of customers also need to create passwords for things other than websites, and therefore don't go through a 'change password' form in a web browser.

I hope this helps, but please let us know if you need a anything else! :)

netweb

I came across this topic a short while ago, looking to store some 2FA recovery codes, for now I have stored them in a custom password field.

I write this reply now only because another use case, I've just stored a private PGP key this same way, as a custom password, as the password field does not handle multi line data very well as pointed out above I'd like to add my vote also to be able to make any field hidable.

Formatting information and hiding that information should not be mutually exclusive, I should be able to have formatted text AND have it hidden.

ag_kevin

Hi @netweb ,

Thanks for letting us know. You make a good point that formatting and hiding should not be mutually exclusive. We have a request open with our development team to consider it.

Cheers,
Kevin

ref: FR-45

netweb

Thanks

Drew_AG

:+1: :)