Is keeping 1password locked in the background safe?

sj0123

Hello.
After reading some articles about memory not being cleared when 1password locks, I wonder if it is safe to stay with 1password locked in the background.
I often try to avoid typing long master password by unlocking 1password with master password for a single time, and use windows hello to unlock 1password next time I need to use it.
To prevent unlock with windows hello capability being disabled, I never quit the 1password program and instead of shutting down the operating system completely, I try to put my computer into sleep or hibernation when I'm not using my computer.
Since 1password process exist in memory most of the times while I use my computer and the memory contents can be swapped out to disk in the event of hibernation. I wanna know if decrypted data or encryption keys stored in clear text is instantly deleted when the program is locked with unlock with windows hello capability enabled.
Few of the articles I have read is
https://techmonitor.ai/techonology/hardware/password-manager-security
and
https://blog.securityevaluators.com/recovering-the-master-password-from-a-locked-password-manager-1password-4-5d32cd569907
I suspect that both articles refer to old version of 1password since none of them explicitly say that they tested on 1password 8, so I wonder if memory protection has improved in 1password 8.
I also heard somewhere that 1password is written in a managed language and instant deletion of memory isn't possible(I forgot where that article was)
With entire backend of 1password 8 completely rewritten in Rust is it steal the case?
In short, I want to know if it is safe to just keep 1password locked when I'm not using it and trying to decide whether I should quit 1password completely after I'm done with it or not.
If I make just one another suggestion here, I'd say security of 1password client can be improved if it has an option to run in elevated environment. That way, an attacker would need to bypass UAC in order to access memory of 1password process. I'm not sure if same result can be achieved by running 1password as administrator.
Thank you in advance, and sorry if I'm just over-concerned and asking too many questions.

---

1Password Version: 8.5
Extension Version: Not Provided
OS Version: Windows 11 Home

ag_Christian

Hey there @sj0123,

There's a lot to unpack in your questions, which is fantastic, so I'll do my best to address them one at a time.

... I wanna know if decrypted data or encryption keys stored in clear text is instantly deleted when the program is locked with unlock with windows hello capability enabled.

When 1Password is locked, there are zero accessible* encryption keys in memory. As soon as you lock the app, all encryption keys are wiped once any in-progress syncs have completed. However, its possible that the UI of 1Password, which is written in JavaScript, may still have any secrets that you interacted with in-memory after locking. We've found that the time it takes for these to be cleaned up varies, but generally (in some very unscientific testing) takes no longer then 5 minutes. The only exception to this is the password you enter on the lock screen. We put a lot of effort to try and make sure that it is explicitly wiped from memory ASAP.

It's also worth calling out here that the UI never contains any encryption keys, and will only ever contain secrets (passwords, TOTP codes, etc) that you've visually seen yourself. If you would like to be 100% certain no passwords end up in a hibernation file, you should close the app's window before you suspend it for the night.

... none of them explicitly say that they tested on 1password 8, so I wonder if memory protection has improved in 1password 8.
I also heard somewhere that 1password is written in a managed language and instant deletion of memory isn't possible(I forgot where that article was)
With entire backend of 1password 8 completely rewritten in Rust is it steal the case?

This is one place that I'm happy to say we've improved significantly from previous versions of 1Password for Windows. Due to large architectural changes in how we built the app, we've reduced a lot of the pain points that came from our choice to use .NET in the past. Our principal security architect, Jeff Goldberg, wrote up a great in-depth description of these and how they affect the security of the app during our last AMA, if you'd like to learn more. I'll just cover some of the highlights so I'm not rehashing everything.

Firstly, as mentioned in an earlier paragraph, we've isolated what the garbage-collected portion of the application's code can see. This means that unless you see a secret in the UI, JavaScript never has the value "hanging around."

As another benefit from the split, we get to keep all of your account's encryption keys in the Rust core. Like you mentioned, Rust doesn't have a memory-managed runtime so we have very tight control over what happens to encryption keys and when. The Rust Core zeroizes encryption keys and super sensitive secrets like your account password on top of making sure that the memory the secrets occupied is freed back to operating system very quickly.

So, its not "completely solved" because we use a lot of Rust now, but we've significantly reduced the problem.

If I make just one another suggestion here, I'd say security of 1password client can be improved if it has an option to run in elevated environment. That way, an attacker would need to bypass UAC in order to access memory of 1password process. I'm not sure if same result can be achieved by running 1password as administrator.

In general, we recommend not to run 1Password with administrator rights, for a few reasons. Most prominently, this opens up a lot of attack surface if a vulnerability was ever found in 1Password that let an attacker, remote (with a shared vault) or local (from random malware), abuse it for privilege escalation. While its our job to make sure this doesn't happen, the reality is that a lot of code makes up 1Password for Windows and mistakes can happen.

In short, I want to know if it is safe to just keep 1password locked when I'm not using it and trying to decide whether I should quit 1password completely after I'm done with it or not.

I think the answer here, personally, is "it depends on your threat model." If you aren't expecting targeted attacks on your physical computer, you will more than likely be just fine. As a teaser, we're looking to bring support for TPM-based unlock to 1Password 8 in the near future. This will help fill in some of the gaps that exist today today.

Thanks again for your questions. I'm also happy to expand on anything or clarify areas that I missed the point on.

* When Windows Hello is enabled, 1Password keeps an encrypted unlock key in-memory (which goes away when the app restarts, as you've observed). To encrypt this key, we rely on the Data Protection APIs provided by Windows that give us an encryption key no other process can access. However, as Windows has complete control over this key, it is very possible that it may be put inside a hibernation file. Unfortunately, Microsoft doesn't document this for us so we can't know for sure what happens. If it is written out, an attacker with physical access to your computer would need to locate the encryption key, and then locate our encrypted unlock key. This is not impossible by any means, but is statistically much harder then looking for a high-entropy ASCII password.