Why is it that when I manually duplicate logins the password history is also saved?

mikeyb

It's possible that this is by design. I have use cases where I create a lot of fields and notes for similar logins that I can pass to team members. After I get all the formatting done and generate or create a new password I noticed that other old passwords form the originating account were saved in the history. Essentially giving passwords various users to each other.

This would not be a big deal except that I can not delete the history.

Thanks,
-Mike

---

1Password Version: 1Password 6.01
Extension Version: 1Password 6 Version 6.0.1 (601003) AgileBits Store
OS Version: 10.11.1
Sync Type: Dropbox / Team
Referrer: forum-search:Duplicating Login also duplicates history

chadseld

Hi mikeyb,

You are right, duplicate should not be duplicating the previously used password history.

I'm curious how you are duplicating the item -- you mention the phrase "manually duplicate".
Are you using Duplicate from the Item menu (Command-D) or the Context menu? If so, the password history should be stripped out.

mikeyb

I stepped through the process again. I should be more clear. I duplicated a login and then changed the password. The old password was saved in the history and I can't delete it. I knew I needed to delete it but could not.

Perhaps this is a feature request.

To be clear I was doing it on purpose for creating redundant user login information. Then I would edit the copy, changing the user name and password. I noticed it when I was manually creating vendor accounts for active directory logins. I let vendors have temporary domain admin rights on occasion. When they are done with the project I disable the account. I like to write in the notes all of the relevant domain information like server addresses, dns, switch info etc. 1password does great prints that I can hand to someone hired to work on something like a server migration. A frequent vendor I use was going to join a Team view. Anyway I almost ended up giving my enterprise admin password to them through the history. Not totally tragic in this case but potentially dangerous if you are not paying attention.

I mentioned manually as there were people having trouble with unintentional duplication. I saw that when I searched the forum for answers before I posted.

It's not really a big deal. It's a use case that seems reasonable given the new team 1password ecosystem.

Thanks,
-Mike

chadseld

Ah, I understand now. I see how that can be a problem. I'll talk to some folks and see if there is something we can do better there.

littlebobbytables

Greetings @mikeyb,

I've added your voice to a feature request I found regarding this.

Like yourself I would duplicate then edit so if I was in your situation I would fall into the same trap. Now it's a bit more convoluted but I believe the following will work for you right now rather than waiting for a fix later down the line.

So you've created your item and you've got it set up just as you want it.

1. Duplicate the Login item and edit the title to include the word template.
2. Save.
3. Edit the template Login item and change the username and password to those for the first person.
4. Save.
5. Duplicate the template Login item and edit the title for the user in step 3.
6. Repeat steps 3-5 as often as required.

So it could be viewed as a bit annoying but what we're doing here is making sure all alterations to the username and password fields happen before the final duplicate action. This means that the new Login item created will have the password history removed given that we currently don't have this feature which the developers agree is probably going to become more and more desired if you have a central person that is setting up a number of items for a team and needs to use the idea of an existing item acting as the template but without as you say, the ability to see the previous password. Hopefully this extra step doesn't seem too clunky while we wait for something to be properly baked into the application.

ref: OPM-1962

mikeyb

Thanks for the feedback @chadseld . And @littlebobbytables thanks for the workaround idea. That does seem reasonable. I do similar things with VMs. It's like a sysprep step for your logins.

-M

rickfillion

On behalf of Chad and Adam, you're welcome. Let us know if there's anything more that we can help you with.

Rick