How to change all identical credentials shared by multiple URLs?

c__

Hi,

I recently migrated from LastPass. In LastPass' model, I had a bunch of "distinct" logins per URL for company internal sites that all used a SSO / LDAP authentication model. So the username/password portions are all the same, but cover a variety of URLs.

Unfortunately, there are two different sets of credentials, and there isn't really a rhyme or reason to which specific URLs use which set of credentials. So I do need some way to track "URL X uses credentials A" and "URL Y uses credentials B."

When I migrated my passwords from LastPass, each existing URL-credential pair got imported as-is. So far so good.

Now, my IT department is still in the 20th century, and requires password rotation every few months. Here is the problem: I need to update the password on all accounts that shared the same username+password, to the new password′. In LastPass, when I logged in with the new credentials on a single site, it would prompt me to update the password for all matching sites. 1Pass doesn't seem to do that, so I have a bunch of stale credentials.

I'm looking for a good way to either:

1. Update all username+passwords that match exactly, or
2. Merge all usernames+passwords that match exactly in some way that tracks the set of URLs the merged credential applies to

I'm struggling to find anything about this in the FAQ or forum already, but I'm sure someone has asked it before. Thanks!

---

1Password Version: iOS latest
Extension Version: Firefox/Chrome X latest
OS Version: FreeBSD (browsers), iOS
Sync Type: Don't know

MrC

@c__ ,

In the Desktop version, you can add the distinct URLs to a single record, and click the one you want to Open and Fill. I'm not sure about 1PasswordX.

c__

@MrC ,

I don't think 1Password makes a desktop version for Linux or FreeBSD, unfortunately.

MrC

Understood @c__ - I just haven't played with 1PasswordX enough yet to know if you can add (i.e. there is a UI to add/use) multiple URLs. The underlying record data structures are the same in all versions of 1Password.

c__

@MrC sure, that makes sense. I think the 1PasswordX extension is pretty limited — it isn't capable of editing credentials, for example. Instead it sends you to the 1password website, which (as someone with some familiarity with computer security, the web, and javascript's trainwreck history re: cryptography and security) makes my skin crawl a little bit.

AGAlumB

@c__: Since the purpose of 1Password is to not reuse passwords, we haven't built it with updating login credentials for multiple items in mind. I realize that in this case you may not be actually reusing passwords, but 1Password has no way of actually knowing that, and having it work differently would encourage password reuse overall.

1Password does, however, allow you to add multiple URLs to any Login item for just the use case of having a single account you need to sign into in different places. This also works with 1Password X and the 1Password.com web interface. I don't understand your comments here though:

I think the 1PasswordX extension is pretty limited — it isn't capable of editing credentials, for example. Instead it sends you to the 1password website, which (as someone with some familiarity with computer security, the web, and javascript's trainwreck history re: cryptography and security) makes my skin crawl a little bit.

Browser extensions are also Javascript and, no surprise, run within the browser environment. So I'm not sure what threats would apply to 1Password.com but not 1Password X. Can you elaborate?

Many of the precautions we take for security can and are applied equally to both -- for example, CSP and penetration testing. Ultimately, if your computer is compromised, neither would be safe to use anyway, as with a native app.

c__

Since the purpose of 1Password is to not reuse passwords, we haven't built it with updating login credentials for multiple items in mind. I realize that in this case you may not be actually reusing passwords, but 1Password has no way of actually knowing that, and having it work differently would encourage password reuse overall.

Sure; I'm not asking for the exact same solution LastPass used here and in fact I think LastPass's solution to this was utterly stupid. I like your model a lot better.

As you surmise, they're not "reused" between distinct sites in any way. They're just the same LDAP credentials used to authenticate to multiple URLs in the same organization. Unfortunately, the way they were imported, they show up as distinct credentials rather than a single credential with multiple URLs.

1Password does, however, allow you to add multiple URLs to any Login item for just the use case of having a single account you need to sign into in different places. This also works with 1Password X and the 1Password.com web interface.

Ok, that sounds like exactly what I want. How do I do that automatically, or at least somewhat automatically, from 1Password X? I have 100s of these things and clicking around 100s of times doesn't sound fun.

Browser extensions are also Javascript and, no surprise, run within the browser environment. So I'm not sure what threats would apply to 1Password.com but not 1Password X. Can you elaborate?

I don't really want to litigate this, both because it's totally irrelevant to the issue I'm having with your software and because I'm not any kind of browser or javascript domain expert. (I work primarily with C in the operating systems space, kernel and userspace.)

My understanding, which may be incorrect or incomplete, is that browser extensions have the following distinctions from websites:

1. They are delivered via a different and potentially more secure distribution system, which at least leaves an audit trail;
2. They have a different trust domain / privilege level than ordinary website-delivered javascript;
3. They are not subject to the same kinds of code injection issues that ordinary browser javascript is.

But as I said, I'm no domain expert. Maybe these guys have more of a clue?

• https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
• https://tonyarcieri.com/whats-wrong-with-webcrypto
• https://security.stackexchange.com/questions/133277/problems-with-in-browser-crypto/133288 seems to refute some of the previous articles' points, with caveats

I would greatly prefer a native application for Linux/FreeBSD. But you do not provide one. I hope to investigate using the CLI, and/or the Windows client under WINE when I get a chance. But I have not had time to do so yet.

AGAlumB

As you surmise, they're not "reused" between distinct sites in any way. They're just the same LDAP credentials used to authenticate to multiple URLs in the same organization. Unfortunately, the way they were imported, they show up as distinct credentials rather than a single credential with multiple URLs.

@c__: It sounds like you just need to add those URLs to a single Login item, and then delete the redundant Logins. Does what make sense?

Ok, that sounds like exactly what I want. How do I do that automatically, or at least somewhat automatically, from 1Password X? I have 100s of these things and clicking around 100s of times doesn't sound fun.

I'm not sure what you mean by "automatically". We really don't want 1Password making assumptions about where login credentials should be used. It should only offer to fill them at a URL matching what you have saved in the Login item. This is an important phishing protection.

My understanding, which may be incorrect or incomplete, is that browser extensions have the following distinctions from websites:

You make a lot of really good points, especially with regard to distribution. Unfortunately malicious and/or shady browser extensions are not uncommon. So it's important to only install one you trust, from a trusted source, and verify that you're not granting it permissions you might not want to. There are definitely risks with both, just as there are with native code running on your computer, just slightly different ones. We build all of our apps -- web and otherwise -- from the solid foundation of our security model, and we stay agile so we can respond quickly to any changes in the landscape. Apart from our own efforts in this area, we participate in external audits and cooperate with independent security researchers to find any flaws so we can fix them.

I would greatly prefer a native application for Linux/FreeBSD. But you do not provide one. I hope to investigate using the CLI, and/or the Windows client under WINE when I get a chance. But I have not had time to do so yet.

WINE unfortunately has only very rudimentary .Net support, so 1Password for Windows will not work there. The CLI app is useful for automation though -- and perhaps you could utilize that to try to deal with some of the "extra" items mentioned above. It's not something we're able to do right now, but I'd love to see us have a native Linux app as well. Thanks for letting us know. :)

c__

It sounds like you just need to add those URLs to a single Login item, and then delete the redundant Logins. Does what make sense?

Yep.

I'm not sure what you mean by "automatically".

Automatically identify identical credentials; present them to me to yes/no for deduplication into the same credential item. If I approve, add the URL to the one item and remove the duplicate. Maybe the CLI would be the best way to do something like this, I'll take a look.

WINE unfortunately has only very rudimentary .Net support, so 1Password for Windows will not work there. … It's not something we're able to do right now, but I'd love to see us have a native Linux app as well.

Ah, that's unfortunate. On the other hand, I think .NET has started moving to having pretty good Linux support, so maybe a Linux native client wouldn't be too much additional work?

Thanks!

littlebobbytables

Hi @c__,

Sadly I don't think any of the existing, purpose built features in 1Password will help here but for the motivated person the CLI should definitely be able to handle this. The scenario is so narrowly focussed that I suspect while it would be neat, its usage would be so infrequent that 1Password would benefit from developer time elsewhere.

AGAlumB

On the other hand, I think .NET has started moving to having pretty good Linux support, so maybe a Linux native client wouldn't be too much additional work?

I think it's still far too early, but I agree that there's some interesting stuff happening for Linux in Redmond lately -- words I never imagined I would say. :lol:

c__

@littlebobbytables Ok, I've had the chance to investigate a little bit. Unfortunately, it seems like the CLI is incapable of updating/editing items, which is a pretty significant blocker for my needs as described in this thread. It seems like the CLI can delete items and create new items; but delete+create has obvious drawbacks: the item uuid is changed, itemVersion is reset to 1, and createdAt is reset to the replacement time. In general that seems like the wrong method to update an item. And permissions doesn't seem to be the issue — if we're allowed to delete an item (including flushing Trash), there's no reason we shouldn't be allowed to update an existing item. It's just a gap in the command line API.

It is also not clear to me from the documentation or the --help usage if the op create item command accepts multiple --url arguments or not, which is something I need to deduplicate my LDAP credentials. (I have not tried it experimentally yet.)

In addition to the lack of update capability, the op utility is poorly and insufficiently documented, both online and with the various --help menus. I'm not trying to be overly critical, but it is difficult to write software against an underspecified, closed source API. For an example of something like the level of detail needed to write against a program, you can find good examples in manual pages, such as man git-log. I'm looking for at least that level of detail.

Is there any reason the op source code cannot be published, even if it is some restrictive view-only, no-derivatives-or-redistribution license? I trust that the API's security does not depend on the client code remaining secret. Providing source code could be a lower effort way to provide 3rd party developers full documentation of the command line interface than writing good docs, if writing good docs is something you don't have the people-hours for at the moment.

Another alternative that I would be very happy with is a well documented, public HTTP+JSON API. Invoking a Go program repeatedly just doesn't make for a great programming API. And you've already got the publicly accessible, versioned HTTP API; it's what op interacts with. It's just not documented for end users. It would be fine for my purposes if it wasn't particularly stable, so long as it was well documented (and documentation was kept up to date).

I'll go ahead and lay some of the groundwork for the utility I want to have — a library interface to interact with the op utility and do session management, etc — but I won't be able to complete it until op at least gains the ability to update existing items.

Thanks for providing the op utility and considering feature enhancements from the community; despite my criticisms, I do appreciate it. I just think it could be even better. Thanks for considering it, and happy holidays and new year!

Best regards,
C

AGAlumB

Indeed, there's a lot of stuff we'd like to do with the CLI app that we haven't yet -- hence the beta, so we can get feedback like this from people actually using it:. All good suggestions. So, likewise, thank you for coming along with us on this journey! :chuffed:

We'll continue to improve the app and its documentation over time as we evolve it, which is why both remain unfinished. ;) I think it would be really cool to open source it, but I think there's a lot of work to be done yet before we'd even really consider doing that.

Happy holidays and a happy new year to you as well! We're excited to keep making 1Password better in 2019, for you and everyone else. :sunglasses: