Hacker News new | ask | show | jobs
by curun1r 2950 days ago
> We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password

Correct me if I'm wrong, but couldn't you re-use the plumbing that you have for the Chrome extension? The blog post was here: https://blog.agilebits.com/2017/07/19/introducing-native-mes...

That way, software could integrate with 1Password by triggering 1Password to prompt the user for the master password, choose a password entry and send that data back to the application that triggered 1Password. That way, the master password is never sent to anything that isn't 1Password. This was the workflow of sudolikeaboss. The implementation of that, however, was hacky since it used a reverse engineered websocket connection behind the scenes. It would seem that the native messaging stuff is a little cleaner and would allow third-party apps to trigger 1Password in a way that, at most, a single password would ever be exposed.

I guess the ask would be to make that native messaging protocol that the Chrome extension uses a documented and stable thing. And since the 1Password application is used by both subscribers and licensees, that can become the preferred way for 3rd parties to integrate with 1Password in a way that users know only exposes individual passwords at the single point in time when they're used rather than the entire vault, for exactly the security reasons you mentioned.

BTW...as much as I've felt frustrated by some of the decisions AgileBits has made, in the few interactions I've had with people at your company, everyone has always been the above-and-beyond type, as you've exhibited here, so thank you for the effort to engage in this discussion, likely long after others have stopped reading this thread.

1 comments

There are a few security related issues with how we handle the native messaging stuff.

There are two important things:

1. We check code signatures and compare them against what we know and expect. 2. The more we approve for this the more it feels like we're screening and supporting the ones we do approve.

We have opted to remove all browsers except those that are mainstream (Chrome, Firefox, Safari and Opera). I believe everything else has been removed. We also don't allow this to be disabled, for security reasons, as of recent versions.

sudolikeaboss would also require that we add their code signature to the app and it breaks the new rule we have on that.

If sudolikeaboss ever came back, it'd be a home grown solution internal from us. It's the only way we could make this work I think.

Security is really tough. We didn't want to start feeling like we had to screen all apps and vouch for them. It's a really slippery slope. Maybe we'll find other ways to accomplish this though. There are indeed some .. plans.. that might actually really impact this in the future! We'll have to see what comes from WWDC this year before we make next steps though.

And thanks for the kind words. I like hacker news, I hang out here and read stuff during my lunch and stuff, so it's a pleasure getting to converse with people here. :)

Kyle

AgileBits