Introduction to the problem
Backup codes are not standardised and thus come in different formats. Some are just one code while others are multiple codes separated by a special character. Next we also face the problem of different preferences on storing these backup codes. These problems of course would make it hard to implement a specific field for backup codes.
I for example save the backup codes in secure notes with a dash on the top so that they cannot be read before opening. This personally makes me uncomfortable and annoyed by the fact that it is not in the same login item.
Simply add an option to hide the text field contents (a per field option of course). This, contrary to many other implementations, would probably be one of the easiest to implement and yet very effective in solving the problem. It has the flexibility to conform to everyone's preferences and could even be used for other sensitive data rather than just passwords and backup codes.
Of course these are just my thoughts about it. Do you guys agree as well?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided
I was curious to see if 1Password supported concealed multi-line text values, and it appears it does not.
A text field, of type string, can be multi-line, and the UI shows these correctly.
But a hidden value is a special data type called concealed. These will not show up in the UI as multi-line fields even when supplied with the multiline attribute. Any newlines in the data are eliminated in the presentation.
It isn't clear to me why password-type values have a special data type called concealed, rather than just being type string and having a concealed attribute (like the multiline attribute). This lack of orthogonality puzzled me while I was implementing 1PUX support in my converter suite.
The only reason I can think of is that having concealed as a datatype would offer them completely control on how its functionality rather than being limited to that of a string. Then still it gives more weight to the argument that it could be implemented without hassle.
For an even easier solution they could just have a button toggling some sort of hidden attribute, which they probably already have in their script/language.
You can get a slightly better "hiding" experience by putting a blank line at the top of the secure note field content rather than a dash. I'd like this "Hide/Show top line of secure notes in list view" to be an across the application preference though. I had dozens of archive encryption keys stored in separate Secure Notes in LastPass and I'm still only half way through editing all the imported entries :(
Hello everyone, I’d like to add my +1 for the hidden/concealed text fields (incl. multi-line support) feature request.
Thanks folks I've passed your requests on to the team.