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 2019

    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 2019

    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.

  • @RSaunders

    Much more troubling is the "whole password database in unencrypted JSON structures". That hardly seems like a good thing. The developer explanation, "we need it for WatchTower and searching to work", doesn't tell me anything. What's Watchtower, and why is it worth this exposure? (Remember I'm asking that and I'm not even on a Windows machine where any old chunk of mobile code can read 1Password's process memory.) What's Searching for? How about we include a switch that turns those features off??

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

    • Logins which have been found in a data breach somewhere
    • Passwords which have been found on previously-breached passwords somewhere (not necessarily associated with your account)
    • Passwords which have been re-used between multiple items in your vault
    • Weak passwords in your vault
    • Websites which are stored in your vault with an "http" address instead of "https"
    • Websites which support 2FA, with no 2FA codes stored in your vault
    • Expired credit card information

    (from the current list I see when opening 1Password)

    The last I know, most of these are opt-in. Nope, I just checked the settings, it looks like only the checks for logins or passwords found in previous breaches, and the 2FA check, can be disabled. But I do remember 1Password asking me to enable each of them. I've disabled the 2FA check, myself.

  • RyanERyanE
    edited February 2019
    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 2019

    @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.

  • @RSaunders

    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.

    If I understand what the 1Password folks have been saying, they don't keep the decrypted data on-hand all the time. They decrypt it, use it, and then discard the memory for the .NET garbage collector to reclaim "later".

    The problem is that "later" takes a very long time to come around, and the decrypted data stays around in unused memory.

    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.

    I'm not 100% clear on whether this is the case for the "in use" state, but I'm almost certain that's what they meant when describing the "locked" state.

    At least, that's how I understand it, mostly from the couple of posts linked directly from post #1 now.

  • @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.

  • @RSaunders

    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.

    ...or they might not. In fact they probably would not. For most people, the feature doesn't do anyone any good if it's not automated.

    In fact one of my logins popped up today as "possibly compromised". I haven't heard about a breach from any other source yet and I never go out of my way to check Watchtower, it just shows up from time to time.

    I'm pretty tuned into these things. I know I should check more often but it's hard to remember to do all the time, for this and plenty of other good computing habits. I think I'm about a month and a half behind on my "weekly" backups at home, for example. And most people don't bother with backups at all.

  • BenBen AWS Team

    Team Member
    edited February 2019

    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.