Which 1Password process to kill, to remove possible secrets from memory?

fritzophrenic
fritzophrenic
Community Member
edited February 2019 in Lounge

I really, really don't want to discuss the recent article about decrypted stuff hanging around in memory after locking 1Password. That's been discussed to death already. Please don't chime in to discuss the issue in general terms.

What I want to know is this:

Since 1Password doesn't have a feature to automatically exit the application and close the process after a period of not being used, I am making a scheduled task in Windows that will automatically force-kill the 1Password process when my computer locks (at work) or when my computer sits idle for a half-hour or so (at home).

I notice there are usually 2 1Password processes running, if I have interacted with 1Password at all (not even having logged in yet):

u:\>tasklist /v /fi "IMAGENAME eq 1Password.exe" /FO list

Image Name:   1Password.exe
PID:          17052
Session Name: Console
Session#:     1
Mem Usage:    23,332 K
Status:       Running
User Name:    DOMAIN\me
CPU Time:     0:00:00
Window Title: OleMainThreadWndName

Image Name:   1Password.exe
PID:          19792
Session Name: Console
Session#:     1
Mem Usage:    90,740 K
Status:       Running
User Name:    DOMAIN\me
CPU Time:     0:00:01
Window Title: Hidden Window

The second process changes its Window Title, depending on what I am doing with 1Pasword, the first remains the same. Furthermore, if I choose "Exit" from the 1Password menu, the second process goes away, only leaving the process with window title "OleMainThreadWndName".

If I kill both processes (taskkill /F /FI "IMAGENAME eq 1Password.exe"), obviously all my secrets get removed from memory (eventually). However, doing that makes the browser extension button grayed out and unusable until I manually launch 1Password again, so I'd rather just kill the 2nd process if I can (taskkill /F /FI "IMAGENAME eq 1Password.exe" /FI "WINDOWTITLE ne OleMainThreadWndName"). So, my questions are:

  • Is killing only the 2nd process, presumably leaving 1Password in the same state as if I did the "Exit" command from the UI, enough to make sure my secrets will eventually be cleared out of memory? Or might both processes contain my secrets?
  • If I need to kill both processes "just to be sure", is there a way to launch 1Password again, in the background, so that I can simply launch it again after killing it, but without having the app window all the time when I come back to my computer?

Yes, I know the risk is fairly low. I just want that little bit of extra protection for my own peace of mind.


1Password Version: 7.3.657
Extension Version: 4.7.3.90
OS Version: Windows 10
Sync Type: Not Provided

Comments

  • Hi @fritzophrenic,

    Thanks for writing in.

    The second process is the Native Messaging Host, the middleman between your 1Password extension and the 1Password app; you'd want to kill them both in case you auto-lock while it has a new Login item in memory to save or something like that. This could potentially result in data loss, just make sure you have everything saved before you leave the computer.

    Even if you kill only the main process, it will not prevent your 1Password extension from timing out and disabling itself.

    We usually use this command when we're doing updates and internal testings; taskkill /T /F /FI "IMAGENAME eq 1Password.*.

  • fritzophrenic
    fritzophrenic
    Community Member

    OK, I will probably just kill both, then. Is there a way to start 1Password in the background without popping up the master password UI? I assume there is, since it starts up that way when Windows starts, and I see it in the Startup tab of task manager. But I don't know where to find the command-line arguments or whatever might be used to suppress the GUI.

  • dougl
    dougl
    Community Member

    Keep in mind that there's no guarantee memory will be cleared immediately (or at all). Might be a false sense of security.

    We were kicking this around at work, and the best option we could think of (caveat - unverified) was to use an encrypted virtual machine. If you only use 1P (and no other software or internet connections) in the guest, and your hypervisor properly encrypts the virtual memory file to prevent reading from the host, it should be close to a complete mitigation of the direct memory read (of course, an attacker who can read memory on the host could also read keystrokes, and compromise the master passphrase itself, as well as capture passwords off the clipboard).

  • fritzophrenic
    fritzophrenic
    Community Member

    @dougl

    Keep in mind that there's no guarantee memory will be cleared immediately (or at all). Might be a false sense of security.

    Could be. But it's a heck of a lot more likely than if the process just stays running, still owning the memory. But again...not really interesting in discussing the threat itself any further in this thread.

    We were kicking this around at work, and the best option we could think of (caveat - unverified) was to use an encrypted virtual machine. If you only use 1P (and no other software or internet connections) in the guest, and your hypervisor properly encrypts the virtual memory file to prevent reading from the host, it should be close to a complete mitigation of the direct memory read

    It would also make the password manager mostly useless for me. I'm not interested in manually typing from a displayed password, and I am even less comfortable about having passwords in the clipboard than I am having them in app memory.

    @MikeT
    I think I figured it out (from adding "command line" to the task manager columns). I now have a scheduled task to with trigger "On workstation lock", which will perform two actions:

    Start a program    taskkill /F /FI "IMAGENAME eq 1Password.exe"
    Start a program    %LOCALAPPDATA%\1password\app\7\1password.exe --silent
    

    I'll do something similar at home with an idle time instead of "on workstation lock".

  • Lars
    Lars
    1Password Alumni

    @fritzophrenic - glad you got the "command line" bit sorted. Let us know if you have any further questions about how this might work, or what your experience with it is.

This discussion has been closed.