A case for Zero Trust 1Password

At the company I work for we are avid users of both Cloudflare and 1Password to handle our internal and external security and password policies.
Cloudflare specifically we use for their Workers, Caching and, more recently, their Zero Trust product, which will be important later in this blog post.

We are a consultancy firm developing and guiding customers on the Zendesk platform. And as such, we come into contact with hundred of customer environments and have temporary admin accounts on most of them.
We store those passwords in dedicated 1Password Vaults split per geographic region, with 2FA TOTP, Device Version and geographic restrictions on all vaults to prevent any misuse (and log any actions).

But recently, after diving into Cloudflare’s Zero Trust documentation and approach a question came up: why is 1Password infrastructure build like a traditional network with no control on actions once you’ve got (legitimate) access to a vault?

“What is Zero Trust security?

Zero Trust security is an IT security model that requires strict identity verification for every person and device trying to access resources on a private network, regardless of whether they are sitting within or outside of the network perimeter. ZTNA is the main technology associated with Zero Trust architecture; but Zero Trust is a holistic approach to network security that incorporates several different principles and technologies.

More simply put: traditional IT network security trusts anyone and anything inside the network. A Zero Trust architecture trusts no one and nothing.”

— https://www.cloudflare.com/en-gb/learning/security/glossary/what-is-zero-trust/

1Password allows Businesses to store credentials in Shared Vaults. Access to those vaults is managed on a group or user level, with admin, write or read roles per user for that specific Vault.

Our high level workflow works like this:

1. A customer signs a contract with us.
2. We get access to their instance via a securely shared login.
3. We store the password in a SharedCustomers Vault.
4. Anyone on the Developer or Project team can see those credentials securely in that Vault.

But here’s where the 1Password modal falls short:

Once an employee gets access to a Vault, there’s no further restrictions on their actions anymore within that Vault.
1Password’s logging service service only logs “Vault Items. Updating (creating, editing, archiving, and deleting items).” but doesn’t log what the employee accesses or views.

From a security standpoint that’s the equivalent of the above mentioned traditional IT network: once you’re inside the network, you can access any file or share without limits.

The issue

So imagine the following scenario: An employee logs into a customer environment with a shared credentials and breaks something.
Or worse: An employee logs into a customer environment with a shared credential and steals something.

Currently there’s no way to identify that employee.

There’s a couple of ways to prevent this:

1. Use personalised accounts instead of shared accounts.
   Not always an option in a shared consultancy environment. Or when using application or API Tokens for a specific customer API.
2. Don’t put items in a shared vault.
   Centralise the logins with one person who handled the changes/deployments. But this kinda defeats the purpose of the 1Password Vault system and creates a big overhead.
3. Temporary Access and Validation (similar to this Cloudflare solution).

A proposed solution

A solution might be a specific type of vault access which only exposes the metadata of a Vault Item, but not the actual credentials.

When an employee needs to access a resource from the Vault, they can request access which will then open a popup that ask for a why and when.

An admin or team lead can approve the request (similar to how Access Recovery currently works), and the agents gets temporary access to the Vault Item in question. Approved/declined access is logged in the admin console.

Will this prevent misbehaviour? No.
Will this prevent copying the password to a notebook? No. But you loose access to the 2FA TOTP so the password is mostly useless.
Will it create an actionable log in case of misbehaviour and create barriers for unwanted behaviour? Yes.

Feel free to reach out if you need more information on this 1Password.