Bogus Reused Passwords

bencurthoys

In this topic I posted last year:
https://discussions.agilebits.com/discussion/78487/changing-password-process-needs-work

I complained that when I used the password generator feature it saved the password to an entry just called "Password". But I got used to it.

I've just noticed the "Watchtower" feature of the latest version, and it's telling me that I have loads of reused passwords... guess what. It's the password for each site, plus the extra stray "Password" entry that the password generator created.

Also, there's still no "merge" function. So if there is one account that I log into two different ways (e.g. an IMAP account which also has WebMail) there's no way of merging the "Web Form Details" from one login to the other entry, which also shows up as a duplicate (which isn't).

Same with a website which has different login forms

So: really like the Watchtower feature, but need to be able to merge entries before it is useful, and I need to have one single password record with multiple website and web form details attached.

---

1Password Version: 7.1.567
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Not Provided

littlebobbytables

Hi @bencurthoys,

You're quite correct, 1Password for Windows needs to do better with Password items. At least now it correctly titles the Password items and includes the URL for the page open when the Password Generator was used but 1Password should be cleaning these up when you update an existing Login item automatically and 1Password should also let you fill as well as copy from within the Password Generator. In this regard 1Password for Windows has some catching up to do with how it works on the Mac.

For email accounts where you have a web interface, this issue exists regardless of platform and this is my personal approach to it. If an email account can only be accessed via the likes of IMAP or POP (pretty rare these days) then I store all the details in an Email Account item. If the email also has a web interface then I use a Login item as I would for any other site and the Email Account item only stores the details relevant to the IMAP or POP server, basically they become a template for any and all accounts for that server. That doesn't just eliminate the issue of the password appearing twice but it means that I can update the Login item's password like I would any other site and it keeps the item current. That's just my take on it. The Email Account item still has value but the Login item is still the superior way to store the actual account credentials.

For the last one, are those two URLs simply two views onto the same account? If they are, could having a single Login item that has multiple website fields be a solution? That's the primary reason we allow multiple website fields although it isn't often you find a single account can be accessed from very different domains.

ref: opw-793
ref: opw-1051

bencurthoys

For the last one, are those two URLs simply two views onto the same account? If they are, could having a single Login item that has multiple website fields be a solution?

Yes. But. How do I manually add web form details to an existing login?

I can have two URLs for an existing item, but how do I have two sets of web form details, one per URL?

If I've got two entries with the same password but different web form details, what I'd really like is an option to copy the website & web form details from one to the other. Or copy the Android Linked Apps details. Or, as I said, merge the two entries.

That's the primary reason we allow multiple website fields although it isn't often you find a single account can be accessed from very different domains.

I have a few examples of single account from different domains, but mostly the duplicates are because 1Password saves duplicate records at some point in the password creation / update process.

littlebobbytables

Hi @bencurthoys,

A Login item can only have a single web form details but that doesn't mean 1Password can't fill different pages regardless. A number of the filling strategies are designed to handle a previously unseen page for a variety of reasons. Going back to your join.me/logme.in example, try adding the second URL to one Login item and see if it fills everything correctly even though the web form details only came from from the first URL.

bencurthoys

Cool. I'll give it a try. It's not that big a deal anyway.

If at any point you're redesigning how you store the data, I'd suggest having "places this password can be used" (viz: mobile apps, window apps, websites) have a many-one relationship with the password object, and each website where the password can be used would store its own URL and forms and so on, in a self-contained blob.

I've just had an idea though and I'll put it in a separate thread.

AGAlumB

We've got a few things in the works that can help: "hiding" these generated Password items, and a special vault type in 1Password.com accounts to similarly maintain a safety net while staying out of the user's way. Cheers! :)