Social Security Number imported as password field
Comments
-
When I imported my password from my old password manager, the Social Security Numbers all came in as password fields by default. I had to edit one of them and of course it saved the previous one as a "previously used password", which for that particular type of card is nonsense. I then decided to change the fields to text in all the cards and the one that had a "previously used password" retained it, even though there is no password field for it to refer to anymore.
There are also some password fields that are not self-generated. For example, my Apple ID recover key was assigned to me by Apple and it makes no sense for that field to have either previously used passwords or for it to have a password generator button.
0 -
Hi @kevin_dean,
Thanks for taking the time to write to us about this! Your post is about a slightly different topic than the previous thread, so I've moved your message to a new discussion where we can focus on the things you mentioned.
By default (and as you noticed), the 'number' field in a Social Security Number item is set as a password field. That allows it to be concealed when the 'Conceal Passwords' option is enabled in 1Password. Of course, as you also noticed, because it's a password field, it behaves like a password field - which includes generating a section for previously used passwords if you change that field. That's not normally a problem, as most people will never need to change it.
But if you needed to make a correction to the number in a Social Security Number item, I can understand how seeing the "show previously used passwords" button would be odd. Although there's no option to delete that when editing an item, there's still a simple solution, which is to duplicate that item (right-click on the item and choose 'Duplicate'). The new item won't have the previously used passwords (and you can then delete the original item).
There are also some password fields that are not self-generated. For example, my Apple ID recover key was assigned to me by Apple and it makes no sense for that field to have either previously used passwords or for it to have a password generator button.
Indeed! But although you and I understand that, 1Password doesn't have a way to know that the information you entered in a password field is one that was assigned and can't be changed. If you don't change that field, it won't create a section for previously used passwords.
Also, keep in mind that previously used passwords are only recorded when you change the main/default password field of an item. For example, in a Login item, only the password field at the top (under the username) will update the list of previously used passwords. Do you have a Login item specifically for your Apple ID recovery key? That might not be necessary, and what I've done instead is to store my Apple ID recovery key in a custom field in the Login item for my Apple ID. Custom fields set as passwords won't be recorded as previously used passwords if they're changed (also, you don't need to set a custom field as a password if you don't want it to behave like one).
As for the password generator button, it shows up for all password fields, but that doesn't mean you need to use it - you can simply ignore that button. It's 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.
I hope this helps, but please let us know if you need anything else. Cheers! :)
0 -
It does, thanks. It still doesn't address the issue of the "previously used passwords" section sticking around even after all the fields are switched to text, though as you say copying the card gets rid of it.
0 -
Hi @kevin_dean,
Once the "previously used passwords" section is created, changing the password field to a different type of field won't make it disappear. After all, changing the field type doesn't change the fact that it used to be a password field, and it doesn't change the fact that a list of previous passwords exists in that item. If we programmed 1Password to delete the previously used password section when the password field type was changed, that would lead to data loss for customers who still need that list of previous passwords.
I'm glad the suggestion of duplicating the item to get rid of the password history helped! :)
0
