Reversing 1Password's Proprietary SRP Authentication Protocol | Token Security

Use Cases

Resources

Company

Platform

Use Cases

Resources

Company

Back

Platform Overview

The Token Security Agentic AI and Non-Human Identity Security Platform

MCP Server and AI Agent

A real-time natural language interface that lets security teams interact with their environment.

Integrations

Token Security connects with AI, cloud services, CI/CD pipelines, on-prem systems, and more.

Discover

Complete AI Agent Visibility, Inventory, and Context

Understand

Align AI Agent Access to Intent

Enforce

Govern AI Agents at Scale

Agentic AI Security

Shadow ai and mcp server discovery

AI agent ownership and accountability

AI agent access control and right sizing

Traceability in multi agent

Non human identity security

Continuous discovery and contextual visibility

NHI lifecycle management

NHI threat detection and response

NHI remediation at scale

Security programs

Security posture management

Zero trust security

Compliance

Third party security

Mergers and acquisitions

Learn

Blog

Resource Hub

Guides

Token Research

The Agentic Pulse

Glossary

Tools

AI Privilege Guardian

Free interactive tool helps right-size permissions for AI agents

GPTs Compliance Insights (GCI)

Open-source tool to discover Custom GPTs, owners, and access

About

News Center

Careers

Trust Center

Book a Demo

Book a demo

Blog

Jul 16, 2026 | 8 min

Reversing 1Password's Proprietary SRP Authentication Protocol

Multi-Author

Gil Portnoy<br>Core Team Engineer

Henry

What if the credentials you created to access a single vault had broader organizational read visibility than you’d expect from its scope?<br>That’s exactly what we uncovered when a simple customer question led us down a rabbit hole of undocumented APIs, reverse-engineered cryptography, and a proprietary authentication flow built for 1Password’s own clients.<br>Over three days, 960 failed attempts, and one very strange Beatles lyric, we tore apart 1Password’s SRP-based authentication to answer a basic question: what does the CLI actually see that the SDK masks?<br>The answer wasn’t just “more data.” It was everything (users, groups, permissions) accessible with a token whose vault scope leads many practitioners to expect narrower visibility than the org-wide read access it actually carries by design.<br>This isn’t a story about breaking encryption. The encryption is excellent. It’s about what happens when a token’s real reach is objectively broader than its vault label implies, and a defender’s mental model never catches up to the gap.<br>SRP (Secure Remote Password) is an RFC-standardized zero-knowledge password proof protocol (RFC 5054). Both sides compute a shared secret via modular exponentiation without the password ever crossing the wire.<br>One of our customers needed full identity visibility over their 1Password deployment – users, groups, vault access, and permissions. Our existing integration used the SCIM bridge, which required self-hosted infrastructure and couldn’t surface half of what they needed.<br>The customer asked the obvious question:<br>“I can get more data from the CLI than the SDK or SCIM. Why can’t your collector use the CLI’s API directly?”<br>We looked into it. What we found pulled us into three days of binary reversing, MITM captures, ARM64 disassembly, Frida instrumentation, and a Beatles lyric embedded in a cryptographic constant.<br>The Gap Between the CLI and the SDK<br>We audited both the CLI (op v2.32.1) and the Python SDK (v0.4.0). The difference was stark:

Capability<br>CLI (op)<br>SDK (Python)

List users<br>op user list (all org users)<br>Not available

Get user detail<br>op user get (includes last_auth_at)<br>Not available

List groups<br>op group list (all groups)<br>Not available

Group members<br>op group user list<br>Not available

Vault users + permissions<br>op vault user list<br>Not available

Vault groups<br>op vault group list<br>Not available

Rate limits<br>op service-account ratelimit<br>Not available

The same token reaches three very different surfaces, and each shows a different slice of the org:

Diagram 1‍<br>The SDK exposes client.vaults and client.items. No client.users. No client.groups. For our use case (mapping identity relationships across an organization) this gap was a significant limitation.<br>Here’s the part worth sitting with: a service-account token scoped to one vault can read all org users and all groups through the CLI,  not just the members of that vault. Names, emails, states, last_auth_at timestamps, group memberships, vault-level ACL permissions. This is by design: 1Password supports vault-management workflows where a service account legitimately needs to add users or groups to a vault. But it is far more reach than the token’s vault label suggests.<br>The SDK wraps a compiled Rust FFI binary (libop_uniffi_core.dylib). We tried monkey-patching the internal invoke() method with ~35 invocation names guessed from the binary’s symbol table – UsersList, UsersGet, GroupsList,...