Is keeping 1password locked in the background safe?

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.