Article just published in Washington Post is saying 1password and others have security flaws

1789101113»

Comments

  • @XIII

    After having done that I now know that (some) passwords are visible as JSON in the dump.

    And they are even marked as password in that JSON data...

    This makes it rather easy to (either manually or automated) find the ones that are leaked (and which you don’t know a single character of) using the metadata in the JSON.

    Wow, this makes retrieving unknown passwords from memory unbelievably easy. Is there an easy possibility to automate the readout with the tools readily available? This would make for a nice Proof-of-concept for @jpgoldberg and @MikeT.

  • alexyangalexyang
    edited February 27

    Wow, this makes retrieving unknown passwords from memory unbelievably easy. Is there an easy possibility to automate the readout with the tools readily available?

    @oneagilebits Not only it is possible, I think the people doing that research has already created it to extract just the valuable items (master passwords and all secrets) from the screenshots of the research paper.


    I am not a Windows developer, but I guess any decent native Windows application developer who knows how to access the memory can eventually write this kind of program to just read the useful bits, let alone the hackers, because there are a lot of patterns around the data.

    I am thinking whether a HIPS product like Comodo could be used to define the rules to prevent third-party memory access to 1password process. I may test it out tomorrow if I have some time.

  • alexyangalexyang
    edited February 27

    It has been over a week since the research paper came out and news report emerged. I now have just three simple yes-no questions for 1Password team. @jpgoldberg

    1. Is 1Password team currently working on a fix or mitigation of the issue reported? (I’m not talking about Rust, which no one promised)
    2. Will there be a formal communication from 1Password to the general users informing about this vulnerability and how to take some actions to protect themselves? (I’m talking about a blog post or email communication to all registered users)
    3. Will 1Password hire an independent security firm to audit and do penetration testing of the latest Windows app?

    Thanks.

  • RyanERyanE
    edited February 27
    1. Is 1Password team currently working on a fix or mitigation of the issue reported? (I’m not talking about Rust, which no one promised)
    2. Will there be a formal communication from 1Password to the general users informing about this vulnerability and how to take some actions to protect themselves? (I’m talking about a blog post or email communication to all registered users)
    3. Will 1Password hire an independent security firm to audit and do penetration testing of the latest Windows app?

    @alexyang
    Completely agree. After all this discussion, it comes down to these questions. After reading all this, I think this is what people want, and they aren't getting it.

  • RSaundersRSaunders
    edited February 27

    @fritzophrenic

    Much more troubling is the "whole password database in unencrypted JSON structures".

    Watchtower checks for various potential problems with your saved items, including: ...

    OK, so this makes sense, if there is a "run Watchtower check" button. When the user clicks the button, you read in the database, run the checks, overwrite the decrypted data, and display the answer. Even if it does this automatically every day (to use updated leak data), that's once a day exposure for the CPU time of the algorithm == almost nothing. Somebody making a crash dump for analysis is not going to catch that. Of course, I don't like automatic things, so having an option like "only do Watchtower test when I click the button", seems quite reasonable.

    None of this even sorta explains keeping the decrypted data on-hand all the time, even when the program isn't active.

  • brentybrenty

    Team Member

    This thread has become pretty unwieldy, so we'll probably need to try to organize things a bit better, but I wanted to follow up here to address something a few people have mentioned: SecureString.

    Apologies for not being able to keep track of everyone who's brought this up, but the question was raised about the "SecureString" API on Windows, as far as if that would be a solution. In short, no; but I don't blame anyone for thinking that something called "SecureString" would be a no-brainer to adopt for security, since that's certainly what it sounds like.

    While SecureString can be applicable for some very specific use cases*, practically speaking there are two main reasons we can’t use SecureString to help mitigate this:

    1. You can write a new "secure" string using the SecureString API, but you can't read it when you need it; and
    2. it has to be converted to a "regular" string for 1Password to use it, which then defeats the purpose because those "regular" strings will remain in memory.

    It's not really designed to be used for storing encrypted content in memory, but for *passing on encrypted content to another process, which is not what 1Password needs it for. When 1Password is decrypting passwords for you, it's got to have them be readable, by your eyes and/or by the browser to send to a website -- you can't login somewhere with an encrypted version of your password, only the real thing. Put another way, we can’t convert it back and expect the strings to go away in memory, as that brings us back to the original issue here.

    For example, when we display a password or fill it in the browser, it must exist in the form of a "regular" string, meaning it will be waiting for garbage collection to move or clear it sometime in the future anyway. So even if if and when we use SecureString for something, as far as the topic of this discussion -- minimizing sensitive data in memory -- we need to create a "regular" string instead to actually do something with the password, and then we're back to garbage collection. And, as Microsoft points out,

    Even if the SecureString implementation is able to take advantage of encryption, the plain text assigned to the SecureString instance may be exposed at various times:

    Ultimately, it suffers from the same sort of challenges that we're dealing with now anyway:

    Overall, SecureString is more secure than String because it limits the exposure of sensitive string data. However, those strings may still be exposed to any process or operation that has access to raw memory, such as a malicious process running on the host computer, a process dump, or a user-viewable swap file.

    In short, SecureString isn't something we can rely on, and is not usable when 1Password needs to display, search or fill data anyway -- which are the reasons we bother to decrypt data at all.

  • @fritzophrenic

    Just overwriting the decrypted data with 00000000 doesn't solve the problem, because the various frameworks and APIs they use make internal copies and such that they don't have full control over.

    That's what's so elegant about the "Run Watchtower" button as a risk exposure reduction. If you don't click the button, 1Password doesn't make those framework and API calls. Your data doesn't get to a bunch of programs that make copies and leaves them lying around for garbage collectors to clean up. It makes your system safer, without regard to how this vulnerability (or future vulnerabilities) work. With this side-effect documented in the help file, folks might run the check once a week before their routine reboots to load patches.

  • BenBen AWS Team

    Team Member
    edited February 27

    Hello everyone,

    First and foremost I'd like to thank everyone who has been contributing to this and related threads. This is an important topic, and it should not be taken lightly. Everyone needs to evaluate what their threat model is and see what protections are appropriate based on their situation. There will never be an all-encompassing piece of software which will allow you to say that you are "secure." That said... 1Password, including 1Password 7 for Windows, can absolutely help you move toward that goal. In summary: we agree that there are improvements that can and should be made both by us and by the industry as a whole. Using a password manager is still better than not using one. We'll continue to look for ways in which we can address these concerns without creating others.

    We have published a knowledge base article on this issue. That article is available here:

    Managing 1Password Secrets in Memory

    If you have specific questions that have not been addressed in this thread or in the above article, or if you'd like clarification on any points, please feel to reach out directly to our security team at [email protected].

    Thank you.

    Ben

This discussion has been closed.