Secure Memory Management in 1Password 7 for Windows

A report by a group called Independent Security Evaluators was published today, which claims that 1Password 7 for Windows is failing to implement basic secure memory management controls. The report is available here.

In short, the findings are that (1) when unlocked, 1Password keeps in memory, unencrypted, every item in its database (i.e., all passwords are loaded into memory, rather than just the password for the item you are viewing); and (2) when transitioning from an unlocked to a locked state, 1Password fails to clear from memory the Master Password, Secret Key, and the decrypted items.

The researchers claim to have developed a tool that is able to read, without any administrative permissions whatsoever, the memory that is allocated to 1Password to extract all of these items, with the only requirement being that 1Password had at some point during the session been running and unlocked (even if it had since been locked).

With a closed-source password manager such as 1Password, customers place a tremendous amount of trust in the developers to ensure that the security best-practices are baked into the SDCL -- more so than with any other product, save for (perhaps) an OS. The findings that were announced today, if true, cannot but put a dent in that trust. Customers deserve a thorough response from the 1Password team.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @GuilhermePS,

    Thanks for writing in. As we expect a lot of folks will ask about this, our security team will write a post about this with more details.

    This isn't a new security issue, this has been known systemic issue with most OSes for a while; you have to compromise the system to read its process memory. Once a malware have access to the system memory, there's not much that can be done. Memory scrubbing wouldn't help if the malware runs all the time and capture the data and a malware keylogger can still capture your password even if memory scrubbing is working a bit. There is a reason almost all password managers are having issues with this, this is a deeper issue than just the password manager itself.

    You still have to keep your system protected at all times, using a password manager is not enough to protect yourself.

    1Password fails to clear from memory the Master Password, Secret Key, and the decrypted items.

    This is due to the fact that we use Microsoft's .NET and WPF, which is a managed garbage-collected runtime plus any visible strings can be stored in memory. It won't clear the memory until 1Password is terminated fully. There is no secure memory management within .NET/C# that works reliably.

    However, we do plan to explain more on this and there are plans to reduce our memory storage and use of .NET in future updates.

  • MikeTMikeT Agile Samurai

    Team Member
    edited February 2019

    Here's our security team's response to the Washington Post article on this as well;

    https://www.washingtonpost.com/technology/2019/02/19/password-managers-have-security-flaw-you-should-still-use-one/?commentId=463ed554-3c4b-4885-a19c-eb49b3fb6392&outputType=comment&utm_term=.b9b7ddb0fd6f

    I am Jeffrey Goldberg, the Chief Defender Against the Dark Arts at 1Password. I thank Geoffrey Fowler for reaching out to us and for discussing the need for using password managers. And it is definitely correct to explore and probe the security of password managers themselves.

    As I attempted to explain in my "lengthy emails" this is a frequently discussed issue. (It seems that my counterparts at KeePass (correctly) called it "old news." Because this is something that has been publicly discussed many times before, we did not seek to enforce the bug bounty non-disclosure rules in this case.) In that exchange, I attempted to explain why any plausible cure may be worse than the disease. Fixing the particular problem introduces new security risks, and the on balance we have chosen stick with the security afforded by high level memory management, even if it means that we cannot clear memory instantly.

    Keep in mind that the realistic threat from this issue is limited. An attacker who is in a position to exploit this information in memory is already in a very powerful position. No password manager (or anything else) can promise to run securely on a compromised computer. But still, other things being equal, it would still be nice clear secrets from memory as soon as they are no longer need. The difficulty is that "other things" aren't equal. As I mentioned there are security gains in programming in a way that has the side effect of limiting our ability to clear memory instantly.

    Long term, we may not need to make such a tradeoff. But given the tools at our disposal, we have had to make a decision, and it is one that I stand by. We are not going to return to the bad old days of corrupted program memory.

    Security questions rarely have simple responses (thus leading to my "lengthy email"). And security designs often involve security/security tradeoffs that require reasoned consideration of risks. I hope that readers will see that we do engage in that process.

  • MikeTMikeT Agile Samurai

    Team Member
    edited February 2019

    Just to be clear, Secure Memory Management can't be done reliably/consistently/correctly if the OS itself doesn't have a way to isolate process memory securely and reliably. It is one of the most difficult software development issues to resolve, especially when the hardware themselves have no way of isolating memory either.

    Recall Intel's Meltdown issues and cold boot attacks.

  • Hi @MikeT ,

    Thank you for the response and for pointing to Jeffrey's comment. I can certainly appreciate the many security benefits you get from relying on high-level languages and frameworks and, as Jeffrey points out, it likely is the right call to make. I'll look forward to the details in your team's post.

  • MikeTMikeT Agile Samurai

    Team Member

    Thanks for understanding and you're welcome. I am also looking forward to his writings, they're always a great read.

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @GuilhermePS,

    You mean want to read Goldberg's post here.

  • Are these issues limited to Windows, or do they exist on iOS and macos as well?

  • GregGreg

    Team Member

    Hi @burhan,

    Please check this reply from Jeffrey Goldberg about macOS. I hope it helps.

    Thanks!

  • One cant help but ask that if authentication occurred via a method that users have asked for over the course of ... years .. if this issue either could have been mitigated or at least another option would exist that would help somewhat mitigate this problem:

    u2f.

  • brentybrenty

    Team Member

    @notauser: What "authentication" are you referring to?

  • @brenty instead of authenticating to the 1password application via a master password locally on the device, such could ... maybe should be offloaded to a dedicated hardware solution that does nothing but authentication.

    Of course the situation is much more complicated and there is no easy answer - and of course a compromised endpoint is a compromised endpoint. But at least your master password wouldn't be stored within memory.

  • brentybrenty

    Team Member

    @notauser: Thanks for clarifying. Indeed. 1Password's security is built on encryption though rather than authentication, and authentication would not be involved when we're talking about a local attack on memory.

  • MikeTMikeT Agile Samurai

    Team Member

    Hi guys,

    In order to make sure we can answer your security questions, please reply here: https://discussions.agilebits.com/discussion/101551/article-just-published-in-washington-post-is-saying-1password-and-others-have-security-flaws#latest

    I'll close this thread for now to ensure all new questions go in that thread.

    @notauswer,

    instead of authenticating to the 1password application via a master password locally on the device, such could ... maybe should be offloaded to a dedicated hardware solution that does nothing but authentication.

    1Password doesn't do authentication, it does decryption; you can't unlock 1Password without a key. If the hardware authenticates you, the hardware still has to give 1Password a key to decrypt with.

    This was what Intel's SGX was supposed to help with but it had some technical restrictions and complexity that it was not sustainable. Not to mention, 99% of our users didn't have SGX capable hardware that'd help. This is a chicken and egg situation.

This discussion has been closed.