[ReOpen] Password items should save history

Options
cipri_tom
cipri_tom
Community Member
in Lounge

Hello,

This has been discussed 4 years ago here, yet I don't see any improvement on 1Password side.

There are many things which are not logins but simply passwords: SSH keys, files and directories, safe locks, bike locks and, to a certain degree, computers (because you're only asked for password, not username when e.g. using sudo).

These items do sometimes change passwords, especially the computers. However, 1password does not remember the history.
In my opinion, any password field that can be edited should offer version storage. IF the Password type is only as a failsafe for unregistered passwords, it should not allow editing by hand, nor manual creation of items of this type.

I am just finding myself frustrated in a situation where I have changed a password stored in one of these fields, but somehow the destination didn't catch it correctly and has left the previous password. Being both randomly generated, I am blocked because I no longer know the previous password :unamused:

1Password Version: 7.6
Extension Version: Not Provided
OS Version: OS X 10.15.4
Sync Type: Not Provided

Comments

  • ag_ana
    ag_ana
    1Password Alumni
    Options

    Hi @cipri_tom!

    Thank you for your feedback on this! The main password field in a Login item should indeed store the entire password history when you make any changes. But you are right that other item types currently do not offer this feature automatically. If you are using a 1Password Membership, we built the item history feature, which should help in case you update a password by mistake and would like to revert the change:

    View and restore previous versions of items

  • cipri_tom
    cipri_tom
    Community Member
    edited August 2020
    Options

    Hi @ag_ana ,

    Thanks for your quick reply!
    I am, indeed, a paid user of 1password. However, the Password items do not have a History. At least there is no such option on the Mac app.

    I currently have ~50 items in the Password category. I am quite disappointed that a password manager does not offer full management for Passwords.

  • Ben
    Ben
    Options

    Hi @cipri_tom

    The primary intention of the 'Passwords' category is to store the history from the password generator (context). For better tracking of the items you're concerned about you may want to consider converting them to Logins. Additionally, some functions are only currently available in the web app (this feature being one such example). As noted at the top of the guide Ana linked the first step is signing in at 1Password.com, rather than using 1Password for Mac. You may find what you're looking for there. That said I will certainly bring your use case up with development to see if there are improvements we can make. One of our goals moving forward is to make the experience more consistent across the apps, e.g. such that features like this would be available regardless of which app you're using.

    Ben

  • cipri_tom
    cipri_tom
    Community Member
    Options

    Hi Ben,

    Thanks for the thourough response!
    Indeed, Logins seem to be better supported in the app, but not all things are Logins (see my examples above). There is no website, no form, no username.

    Indeed, I have found the previous version of the Password with the web app ! Thank you ! I did not see in the article that it was for the WebApp rather than for a dedicated app.

    Yeap, feature parity would be indeed great to have. So far, I had always assumed this was the case, or even more, that the native apps would have more features than the web app.

    Cheers,
    Ciprian

  • Ben
    Ben
    Options

    Indeed, Logins seem to be better supported in the app, but not all things are Logins (see my examples above). There is no website, no form, no username.

    Understood. :)

    Indeed, I have found the previous version of the Password with the web app ! Thank you ! I did not see in the article that it was for the WebApp rather than for a dedicated app.

    Ah, fair enough. Glad to hear that tip helped and I was able to get you pointed in the right direction. I'm sorry that wasn't more clear in the first place.

    Yeap, feature parity would be indeed great to have.

    For sure. Increasing parity is definitely on the radar. We've tried a few things in the past to help with this, and in some ways they've furthered us along, but we've got a new game plan now and with any luck that'll get us much closer. One of the big challenges is that we don't want to lose the native feel of our apps and integration with OS-specific features (e.g. Touch ID on Mac/iOS).

    So far, I had always assumed this was the case, or even more, that the native apps would have more features than the web app.

    It isn't a completely unfair assumption but the balance has shifted in the last couple years, and it seems more commonly the case that web apps can be developed more quickly than desktop apps. With our new 1Password for Linux app (in development preview) we're taking a hybrid approach to try and get the best of both worlds: the backbone is written in Rust and the UI is React & TypeScript / Electron. This gives us the typical things people expect from 'native' apps (security, performance, and platform integration) and also the benefits of web apps (design, responsiveness, and rapid development).

    Thanks for the thourough response!

    You're very welcome! If there is anything else we can do, please don't hesitate to contact us.

    Ben

This discussion has been closed.