There’s one question our Security team hears more than any other: Is my 1Password data vulnerable if my device is compromised or infected with malware?
A compromised device involves full control or visibility at the system level1, and password managers like 1Password store data that’s accessible to the system — that’s how they function. In fact, that’s how most typical apps are built.
The short answer is: Yes, your secrets are vulnerable to an attacker who’s fully compromised your device, however unlikely that situation may be. And let me be clear that if you’re an everyday internet citizen who browses securely and maintains their devices, worrying about such local threats is probably unnecessary. The longer answer is nuanced, as they so often are, and presents an interesting paradox.
So, let’s explore that paradox, then dig right into local threat protections in 1Password. After our deep dive, I’ll reveal the crucial non-security consideration involved in our threat-mitigation approach, and explain how the 1Password team strikes an incredibly delicate balance.
The challenge
Keeping information safe on your devices is essentially the reason password managers were created in the first place. Your password vault is a much more secure alternative to spreadsheets and word-processing files floating around because your data is encrypted at rest (on your device).
That means the information you store in 1Password is most secure when 1Password is locked. Attacks on your locked data - like guessing your account password or trying to find an unpatched cryptographic flaw – are passive attacks.
But keeping 1Password locked at all times flies in the face of everything else our product is known for: convenience, security on the go, ease of use, adding efficiency to your workflows, and more. It’s also not realistic because as consumers, we typically choose products we can make use of, right?
Well, using 1Password means the possibility of active attacks.
Active attacks occur when malware targets 1Password as the app is running or being unlocked. An attacker can attempt to steal your credentials as you provide them; they can also steal secrets while the app is open and unlocked. Active attacks are the larger concern for our security and development teams. They’re also the hardest to guard against.
And there’s no one-size-fits-all solution. Our approach, for example, is a bit contradictory.
We face a challenge that’s incredibly common throughout our industry: Protections are largely specific to each platform, operating system, and environment because each has its own security boundaries.
Given the varied conditions and guardrails, the protections we can build differ, and depend on the platform and type of threat we’re addressing. We have to exclude many local threats from our threat model for that reason, and often reject related bug bounty reports. We implement platform-specific protections where we can but are often limited by the operating systems themselves.
Yet we always do our best to protect your data from local attacks, and often accept reports of missing local protections we can add without negatively impacting performance, other security considerations, or the customer experience.
The protections
When 1Password is locked, we make sure your vault contents are encrypted so they’re impenetrable, even to someone with root access to the device. We accomplish this with traditional 1Password accounts by storing the secret that’s required to decrypt the vault contents, your account password, in your mind — a location presumably inaccessible to attackers. Accounts protected by SSO and passkeys rely on security features built into the device.
We also do everything possible to protect against same-user privileged access — a term for malware that runs on a computer with the same permissions you have, and lacks the ability to elevate its privileges.
We can prevent such attacks from targeting open and unlocked versions of 1Password so it can steal your information on devices with specific Linux distributions (Wayland), macOS, Android, and iOS. There are protections in place for Windows systems, as well, but Windows apps are protected in such a way that an anti-malware solution is required to protect against processes that try to debug other applications.
While we account for same-user threats, it’s important to acknowledge this kind of malware is always capable of phishing or otherwise misdirecting you to a fake version of 1Password. Let me reiterate that safe browsing and a secure device are always the first lines of defense.
There’s one other category of security threats we take into account as we fortify 1Password: forensic analysis.
Maybe the would-be attacker has physical access to your device or exploits a vulnerability. However it happens, there are plenty of tools available that allow someone to view your secrets if they get their hands on a copy of your drive (disk) or memory (RAM).
To protect your secrets, we prevent your vault contents from ever hitting the disk unencrypted. And when you unlock 1Password the traditional way, the keys to decrypt your data are unavailable via forensics alone — the account password remains with you.
When you use SSO or a passkey to unlock your 1Password account, your vault information is only accessible if the forensics can gather other data to facilitate a successful SSO or passkey authentication, and that depends entirely on your SSO configuration and local storage protections.
We minimize exposure of your secrets in memory by attempting to clear the 1Password apps of sensitive data, and minimizing the amount and types of data in memory while the apps are unlocked. It’s difficult to guarantee absolute clearance when we talk about things remaining in memory, but we aim to maintain the highest possible level of security hygiene.
While these local protections cover a number of threats at the forefront of our threat model, there’s one local threat without any viable defense.
The balance
1Password lacks the ability to protect against an attacker who’s gained full control over a device with administrative or root privileges. But there’s an important fact to acknowledge here: In this case, 1Password is far from unique.
There’s no password manager or other mainstream tool with the ability to guard your secrets on a fully compromised device.
It’s simply a limitation of the operating systems 1Password runs on: There’s no way to isolate an application to sufficiently limit the damage malware is capable of inflicting. An application can be an annoyance, but there’s no amount of annoying that will stop a determined attacker.
At the end of the day, local threats present a number of issues we’re unable to reasonably address. And that’s the very reason we’re forced to exclude them from our threat model and reject many related bug reports. While we’re unable to defend against a full compromise, we use every option available to make it difficult for local threats to access your secrets.
But there’s a critical balance we have to consider: protection and usability. Many mitigations that make the lives’ of local threats more difficult, make your life more difficult, too.
Runtime Application Self-Protection frameworks, for example, would allow us to make even root level attackers suffer. But these third-party products often have serious performance, reliability, and privacy considerations. The implications are serious enough that we’ve decided not to use them.
When security restrictions clash with convenience and we have to make choices, we’ll always choose to give your secrets the best fighting chance. And when that approach is layered with nearly impenetrable cryptography, same-user defenses, and the minimization of secrets in memory, we find ourselves with the deeply secure design of a thoughtfully secured password manager.
Thank you to the following contributors:
- Rick van Galen – Tech Lead, Product Security
- Adam Caudill – Security Architect
To clarify, full control of the device is not relegated to physical control, but access with administrative or root privileges. ↩︎
Megan Barker
Security Scribbler
Tweet about this post