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

17891113

Comments

  • brentybrenty

    Team Member

    @bkh: Hey, thanks for participating. I'll do my best to clarify where I can:

    If I have unlocked 1Password, it is possible for a crash to dump my master password, secret key, and vault contents in plain text. Moreover this remains true after I lock 1Password. Telemetry can automatically ship some or all of this to the app/OS developers. None of this requires malware on my machine. I don't understand which combinations (app crash vs OS crash; app telemetry vs OS telemetry) can do this. I understand that I can configure the OS not to take any memory dump, but I don't understand which 4 combinations of app/OS and crash/telemetry this mitigates.

    1Password does not do this, and I haven't seen concrete examples of where this would occur, but it is possible that other software running on your system could do a memory dump, and that could potentially include 1Password data in memory at the time. That should not happen, but it is not a given that it could not.

    If I am an unprivileged user (no admin access), any process running in my session can read the process memory of 1Password and see the plain text of my master password, secret key, and vaults. Moreover this remains true after I lock 1Password. To do so is considered malware, but it does not require admin, it is a simple failure of process isolation in Windows. General "security hygiene" reduces the chance of this happening, but if I get malware (even without admin) all my secrets are instantly gone, it is not necessary for the malware to persist and collect the secrets over time as I use each one. I can partially mitigate this threat by having two (or more) 1Password accounts / family members to separate my secrets into precious and not precious vaults, and so the precious secrets are simply unavailable to me and malware in my normal computing sessions.

    If targeted, that is also possible, in the same way that the above with a memory dump could include 1Password data in memory.

    While it isn't good news that admin rights are not necessary, this only works "in the existing user context". So, one user account being isolated from another provides a benefit on Windows. I mention it because you mention your family. I'd strongly suggest, as I always do, not sharing a Windows user account. The likelihood of you installing malware may be lower than most, as a security-conscious user; but that may not be true of your whole family; and certainly having a group of even technical, security-minded people using the same user account just increases the odds of a mistake being made by someone, resulting in the rest being put at risk.

  • bkhbkh
    edited February 2019

    it is possible that other software running on your system could do a memory dump, and that could potentially include 1Password data in memory at the time. That should not happen, but it is not a given that it could not.

    Can you suggest a mitigation? This thread has discussed various strategies and techniques that agilebits may be considering for 1Password itself, but I'm wondering if there is anything I can do in the meantime.

    I mention it because you mention your family. I'd strongly suggest, as I always do, not sharing a Windows user account.

    Of course. But shared vaults is one of the principal applications of 1Password Families; shared items have the combined risk of all those having access. I don't have a mitigation for this.

  • @zoup

    Troy recommends if you're that concern just go get a password book

    Yes, but if I use a password book and I need to change or delete a password, is there a pencil eraser out there that I can trust to truly erase it from the paper? :p

  • Can you suggest a mitigation? This thread has discussed various strategies and techniques that agilebits may be considering for 1Password itself, but I'm wondering if there is anything I can do in the meantime.

    You could always quit 1Password if you know you won't need for the time coming. But even this is not a perfect solution, since the data could be retained in memory after quitting and remain theoretically accessible. However you would make the very small probability of having an accidental memory dump leaving your machine even smaller. If it is a deliberate memory dump by Malware, there is no real way of defending against it, since the attacker can just wait until you unlock, use a keylogger etc., since he basically owns your machine if it is compromised.

    But still, if improvements can be made here, I would very much like to see AgileBits implement them as soon as possible, especially removing the ability to dump 1Passwords Memory without having admin privileges with as little as the Task Manager (since this is possible currently, ALWAYS lock your computer if you leave. You should do that anyway, but a reminder always helps).

  • For those wondering what it looks like in a memory dump file and how exposed your passwords are take a look at this picture.

    It's a KeePassXC test vault I created to show you want it all looks like, 1Password looks very similar. Can you guess the password?

    Keep in mind this text file is huge and nothing but this jibberish throughout. Yes, your password is in that file somewhere in plain text but it's not like it's an easy to read novel.

  • @Zoup the idea that if you spend a few days and write some code, you can reliably find location of the passwords (at least for an exact given build of target app). In the original article, researchers didn't search for their known passwords, they had code to extract all passwords without knowing them beforehand.

  • XIIIXIII
    edited February 2019

    Keep in mind this text file is huge and nothing but this jibberish throughout.

    I was initially hoping that random gibberish passwords would indeed be hard to detect (and fearing dice passwords might be less safe), but the situation is much worse in my experiment (both with a memory dump from Task Manager when 1Password was still open and when I manually locked it).

    I see JSON like this (using the Findstr command):

    {"value":"<MY_PASSWORD>", "type":"P", "name":"password", ...}

    where MY_PASSWORD is either the gibberish or the dice password.

    Makes it really easy to find all passwords in that dump...

    I'm really worried now, as I have once sent a memory dump to a software developer to debug an issue (on his request). I definitely made sure I did not have 1Password open at that time, but I'm not sure whether I created the dump after a fresh boot or was logged in before and only locked 1Password before generating the dump file (thinking that would clear memory).

    Does this mean all my passwords are leaked to this developer now?

    Unfortunately I don't have that dump file anymore to check; but my mails about it were from early 2015. Did we still have 1Password 4 back then? And does that make a difference?

  • Additional info:

    From the conversation with the developer I see that I had to debug Microsoft Word in the Windows Debugging Tools. Reproducing the crash with Word opened in the debugger I had to issue this command:

    .dump /ma c:\users\YOURNAME\desktop\winword.dmp

    Does this mean I sent him a dump of Word only? Or is there still a risk I sent my credentials?

  • XIIIXIII
    edited February 2019

    Hm, it's actually only the 1Password password itself (and its old historic values - that's what might have confused me) that's visible as (easy to parse/find) JSON?

  • The silence is deafening.

    There's really nothing else to say, we've all said it all. I'm losing faith anything is going to be done about this in the short term.

  • It’s a true disappointment that up till now no official recommendation is available for mitigation of this vulnerability. The blog post promised is still not there, and most of the official responses in this thread is aimed at playing down this vulnerability, arguing that only a “compromised” machine can lead to the exploitation of this issue. By this definition, few of the machines we use nowadays are immune from the attack, which only requires the execution of a program without admin rights. This means that for whatever app we use, we need to inheritedly trust all of its developers with our life.

    I am sorry but there is just too much risk running 1Password app on Windows right now. If I can’t be sure to protect myself, how I can let my family and friends who has less security awareness use it?

    My personal advice would be

    1. Quit 1Password on Windows
    2. Restart the computer
    3. Never unlock it
    4. Use 1Password X with Chrome. Memory management and protection in Chrome is far better than 1Password on windows. There is no report that 1Password X is also affected in this vulnerability.
  • On the 1password blog post regarding travel mode it says

    Your vaults aren’t just hidden; they’re completely removed from your devices as long as Travel Mode is on. That includes every item and all your encryption keys. There are no traces left for anyone to find.

    Does this bug mean that this is post is wrong? With this bug would I activate travel mode and the still have my entire vault stored in memory?

  • BenBen AWS Team

    Team Member

    @RyanE

    Simply quitting 1Password after enabling Travel Mode (even if you subsequently re-open and unlock it after enabling Travel Mode) should clear any vaults not marked as "safe for travel" from memory. That said, I'd recommend shutting down your devices while going through border crossings / airport security / etc if you're concerned they may attack your device's memory. There are potentially lots of other things in memory otherwise.

    Ben

  • Proposal: Team up with the other password managers impacted and lobby Microsoft and Apple to add a "secure string" class to their APIs. That's where the support really needs to happen and it would benefit a lot of software.

  • @Charlie_s: The silence is deafening.

    There's really nothing else to say, we've all said it all. I'm losing faith anything is going to be done about this in the short term.

    Sigh, I know how you feel.

    @alexyang: would you mind helping us test if using 1Password X on the latest version of Firefox (and Microsoft Edge) would exhibit the same memory bump vulnerability? I'd deeply appreciate it!

  • brentybrenty

    Team Member

    Can you suggest a mitigation? This thread has discussed various strategies and techniques that agilebits may be considering for 1Password itself, but I'm wondering if there is anything I can do in the meantime.

    @bkh: Restarting the device will clear the memory. Absolutely not ideal, but as noted previously there is no definitive time frame in which memory would be cleared by quitting the app as opposed to locking. I'm sorry that I don't have a better answer than that for the time being.

    I mention it because you mention your family. I'd strongly suggest, as I always do, not sharing a Windows user account.

    Of course. But shared vaults is one of the principal applications of 1Password Families; shared items have the combined risk of all those having access. I don't have a mitigation for this.

    I may be misunderstanding you here, but it seems to me that the mitigation would be on the Windows account level -- i.e. if each of you use a separate Windows user account, one (non-admin) user accidentally running malware in their environment would at least not affect the others; whereas if everyone is using the same Windows user account, only one of those people would need to make a mistake in order to compromise everyone. Does that make sense?

  • @derek328 Sorry but I am really not in the position to test that. In either way my answer would not be official, and it is up to the 1Password X team to say that whether their product is immune to this kind of attack or not, as they know the product better than anyone else.

  • XIIIXIII
    edited February 2019

    @MikeT Can you (or one of the other Windows developers) please explain why it's exactly all 1Password credentials that I see in JSON in a memory dump? (And only those?)

    • 1Password username
    • 1Password password
    • 1Password Secret Key
    • 1Password 2FA setup code
    • Historic values for these entries
  • @alexyang totally understand that. thanks for helping us test Chrome to begin with! mad respect.

    @brenty: [...] if each of you use a separate Windows user account, one (non-admin) user accidentally running malware in their environment would at least not affect the others [...]

    um.. i mean no offense brenty but, i don't think that's an accurate assessment. there are a myriad of ways that a malware can be run as a non-admin Windows user account, and still affect others. it is a whole category of malware, and even has its own name (privilege escalation malware).. and that's just one category.

    other types of malware can also breach a non-admin user account to do harm beyond its current environment, like overtaking the default hidden Windows admin account, infecting common drives, infecting portable / connected devices, etc.

  • derek328derek328
    edited February 2019

    @XIII: Can you (or one of the other Windows developers) please explain why it's exactly all 1Password credentials that I see in JSON in a memory dump? (And only those?)

    • 1Password username
    • 1Password password
    • 1Password Secret Key
    • 1Password 2FA setup code
    • Historic values for these entries

    Now that's worrying. If what you said is true, you should check to make sure no other ppl have accessed your 1Password account recently (in case the developer saw your logs decides to be a little too curious), and change your master + secret keys. If you see devices / access records that you don't recognize, you should assume your accounts are compromised.

    Also I really agree. 1Pwd needs to reply to you because their so called "rare" scenario just happened.. to you..

  • Now that's worrying. If what you said is true, you should check to make sure no other ppl have accessed your 1Password account recently (in case the developer saw your logs decides to be a little too curious), and change your master + secret keys. If you see devices / access records that you don't recognize, you should assume your accounts are compromised.

    That developer is working on the antivirus software that I use on my PC. That means I have to trust him anyway...

    I sent the dump early 2015. There are a few things that make me think I should be OK:

    • no unknown devices in the login log
    • I changed my 1Password password a few times since then
    • there probably was no 1Password.com (with Secret Key) back then
    • there definitely was no 2FA (with setup code) back then
  • brentybrenty

    Team Member

    @brenty: [...] if each of you use a separate Windows user account, one (non-admin) user accidentally running malware in their environment would at least not affect the others [...]

    um.. i mean no offense brenty but, i don't think that's an accurate assessment. there are a myriad of ways that a malware can be run as a non-admin Windows user account, and still affect others. it is a whole category of malware, and even has its own name (privilege escalation malware).. and that's just one category.

    @derek328: Sure. Hypothetically, an OS vulnerability could be exploited by malware for privilege escalation. But in that case, again, we're no longer in the realm of likelihood during normal operation of the OS. That's like saying that AES is broken because at some point in the future someone may find a flaw or just be able to brute force it using technology which does not today exist. It's a bit of a logical leap, and also isn't at all helpful to the user who is asking what they can do, practically speaking, to reduce risk -- which is what I was replying to.

    other types of malware can also breach a non-admin user account to do harm beyond its current environment, like overtaking the default hidden Windows admin account, infecting common drives, infecting portable / connected devices, etc.

    That would be malware running with elevated privileges.

  • brentybrenty

    Team Member

    The silence is deafening.

    @Charlie_s: On the contrary, it's difficult to keep up with the discussion. I've got a few drafts here I'm trying to finish, but
    people are commenting again to ask for a response before I can finish them. :tongue: I don't see where you asked a question though. If you asked one that hasn't already been answered, and I missed it, I'm sorry. Please let me know.

    There's really nothing else to say, we've all said it all. I'm losing faith anything is going to be done about this in the short term.

    I'm not sure that there's nothing left to say, but certainly a lot has been said on the subject already, to the point where there's a lot of repetition. As mentioned previously, there are some things we're working on in this area, but we're not able to offer release dates for unreleased software. When we have something to share publicly though we will provide an update.

  • brentybrenty

    Team Member

    @XIII: I'll do my best to cover your various comments here:

    I'm really worried now, as I have once sent a memory dump to a software developer to debug an issue (on his request). I definitely made sure I did not have 1Password open at that time, but I'm not sure whether I created the dump after a fresh boot or was logged in before and only locked 1Password before generating the dump file (thinking that would clear memory). Does this mean all my passwords are leaked to this developer now? Unfortunately I don't have that dump file anymore to check; but my mails about it were from early 2015. Did we still have 1Password 4 back then? And does that make a difference?

    It could make some difference. 1Password 4 was completely different code, and the new 1Password (6/7) app did not exist at that time. It's really hard to say at this point, but the reasonable likelihood is that, if you were using 1Password at the time (literally, actively), when the dump was created it would have included some (but not all) of your 1Password data. As Mike mentioned earlier in the discussion, 1Password 4 did not have Watchtower or some of the more advanced search capabilities (which I guess are very similar in a sense), which do require a lot of information to be decrypted at once in memory to parse it. So in that regard, it's less concerning, in addition to the fact that so much time has passed that you would probably know in 2019 if anyone malicious was getting into your stuff. But if you do have important accounts today that you may have been using at the time, you could always change their passwords to err on the side of caution (since you don't really know if 1Password was even open then).

    Additional info:
    From the conversation with the developer I see that I had to debug Microsoft Word in the Windows Debugging Tools. Reproducing the crash with Word opened in the debugger I had to issue this command:
    .dump /ma c:\users\YOURNAME\desktop\winword.dmp
    Does this mean I sent him a dump of Word only? Or is there still a risk I sent my credentials?

    Again, I can't say definitively, but a dump of only Word should not include memory from other apps. But of course there may have been a bug that resulted in more being collected at that time. I'm not sure it would be possible to ascertain that now though.

    Hm, it's actually only the 1Password password itself (and its old historic values - that's what might have confused me) that's visible as (easy to parse/find) JSON?

    I admit I'm not sure what you're asking here. Can you elaborate?

    Can you (or one of the other Windows developers) please explain why it's exactly all 1Password credentials that I see in JSON in a memory dump? (And only those?)

    The full JSON of an item needs to be decrypted in memory in order for it to be used, say for filling, full text search, etc.

    That developer is working on the antivirus software that I use on my PC. That means I have to trust him anyway...
    I sent the dump early 2015. There are a few things that make me think I should be OK:
    no unknown devices in the login log

    That is good news indeed, if you haven't seen any strange logins to your accounts since then.

    I changed my 1Password password a few times since then

    One less thing to worry about now then.

    there probably was no 1Password.com (with Secret Key) back then

    It was launched as a beta in November 2015, so it does sound like you weren't using that at all at the time.

    there definitely was no 2FA (with setup code) back then

    For a 1Password account? That's correct. If you mean using 1Password to generate TOTP codes for other accounts though, that was possible in 1Password 4.

    Apart from the question I had a question about, I think that covers it, but if there's something I've missed please let me know!

  • brentybrenty

    Team Member

    would you mind helping us test if using 1Password X on the latest version of Firefox (and Microsoft Edge) would exhibit the same memory bump vulnerability? I'd deeply appreciate it!

    Sorry but I am really not in the position to test that. In either way my answer would not be official, and it is up to the 1Password X team to say that whether their product is immune to this kind of attack or not, as they know the product better than anyone else.

    @derek328, @alexyang: I'm afraid this may not be very helpful if you are looking for absolutes, since browser extensions don't have control over memory, but 1Password X's encryption and obfuscation, the sandbox isolation (both from the OS and other browser processes) do offer an advantage in the context of memory. It would be more difficult for a malicious app to collect data from a browser child process than another app running in the same context, because the browser itself has additional security measures in place. That's interesting of course, because usually we think of the browser as being less secure, but as always it depends on the type of threat. Of course, a browser vulnerability which allows penetration of the sandbox could represent a threat either locally or remotely, but the vendors are incredibly efficient when it comes to patching known exploits, especially of that magnitude, so there's some relief.

  • brentybrenty

    Team Member

    It’s a true disappointment that up till now no official recommendation is available for mitigation of this vulnerability. The blog post promised is still not there, and most of the official responses in this thread is aimed at playing down this vulnerability, arguing that only a “compromised” machine can lead to the exploitation of this issue. By this definition, few of the machines we use nowadays are immune from the attack, which only requires the execution of a program without admin rights.

    @alexyang: "Compromise" just means that malicious software is running on the device. There are varying degrees of compromise, of course, but we should assume that if someone has gone to the trouble to create malware for you to infect yourself with, they're going to do their best to use any foothold they gain, whether that's just monitoring the clipboard (with very limited privileges) or installing a rootkit (if they have sufficient access). I see a lot of people going back and forth about "admin" versus "normal user", but we need to keep in mind that even the weakest level can be a stepping stone to something more powerful, due to bugs, user error, or targeted exploits. So I do think it's best to think of it in terms of "compromised" or "not compromised".

    Regarding recommendations, as mentioned previously, the ISE paper makes some good ones:

    • Keeping the OS updated
    • Enabling or utilizing well known and tested anti-virus solutions
    • Utilizing features provided by some password managers, such as “Secure Desktop”
    • Using hardware wallets for immediately exploitable sensitive data such as crypto currency private keys
    • Utilizing the auto lock feature of their OS to prevent ‘walk by’ targeted malicious activity
    • Selecting a strong password as the master password to thwart brute force possibilities on a compromised encrypted database file
    • Using full disk encryption to prevent the possibility of secrets extraction in the event of crash logs and associated memory dumps which may include decrypted password manager data
    • Shutting a password manager down completely when not in use even in a locked state (If using one that doesn’t properly sanitize secrets upon being placed into a locked running state)

    And certainly restarting the device will clear memory if you want to be sure, since otherwise it's up to the OS to reallocate as needed.

    This means that for whatever app we use, we need to inheritedly trust all of its developers with our life.

    Slightly exaggerated, but I think that's a pretty good philosophy. It's always been the case that we need to trust the software we allow on our systems, not just in the context of this discussion.

    I am sorry but there is just too much risk running 1Password app on Windows right now. If I can’t be sure to protect myself, how I can let my family and friends who has less security awareness use it?

    I disagree with this wholeheartedly. Someone using 1Password is not more at risk than someone who is not. Even the researchers recommend that we continue using our password managers. Their point is that there are weaknesses, and we're all in agreement that there's room for improvement, and what some options are; it's just much easier said than done, so there isn't a magical solution that can be provided today -- or we'd all be using it. It will take time and effort.

    My personal advice would be
    Quit 1Password on Windows
    Restart the computer
    Never unlock it
    Use 1Password X with Chrome. Memory management and protection in Chrome is far better than 1Password on windows. There is no report that 1Password X is also affected in this vulnerability.

    I touched on that above, but you're right that because the browser is a much more hostile environment, there are many security measures in place which are not in the OS (as, frankly, they would break a lot of software), which was designed first and foremost with an implicit trust of the applications. Security is something that was not considered in the design, and it's only after problems arose that changes were made to lock things down bit by bit over time -- though the implicit trust still exists in many forms. That's the challenge that not only 1Password and other password managers, but rather all software, faces.

  • Charlie_sCharlie_s
    edited February 2019

    Comment deleted.

  • brentybrenty

    Team Member

    Proposal: Team up with the other password managers impacted and lobby Microsoft and Apple to add a "secure string" class to their APIs. That's where the support really needs to happen and it would benefit a lot of software.

    @HeartfeltSarah: While it's much easier said than done, I think that's a great idea. We've gotten some really great stuff on iOS and Android like this, and while it's more complex on desktop OSes with a long legacy, perhaps that can happen...even if it would probably be a ways off no matter what, since OSes would need to be updated. If nothing else, I'm sure that Apple and Microsoft are following this research as well, as it affects all apps, not just password managers.

  • um.. i mean no offense brenty but, i don't think that's an accurate assessment. there are a myriad of ways that a malware can be run as a non-admin Windows user account, and still affect others. it is a whole category of malware, and even has its own name (privilege escalation malware).. and that's just one category.

    @derek328 the "great article" that you refer to actually acknowledges this

    Please Note: memory attacks are generally not possible unless an attacker has physical access to your machine or a malicious application is running. If your computer is compromised in this way, then there is very little a program can do to protect its data.

    Your best defense against this threat is to have an up-to-date virus scanner and keeping your computer physically secure. Nonetheless, here are the techniques KeePassXC uses to protect your data:

    • We specifically disable reading the memory of KeePassXC.
    • (Note: it is not possible to prevent an administrator from accessing memory)
    • We also disable “core dumps” which can expose secrets if the application crashes.

    Here's a fact check on 1Password:

    1. 1Password data can only be read from the memory if you are an administrator (same as KeePassXC)
    2. Core dumps are already disabled in 1Password despite elsewhere you suggesting (in respect of "core dumps for KeyPassXC") that 1Password don't:

    You then said:

    If KeyPassXC has done more to protect its users from this type of attack vector / memory dump vulnerability than 1Password delivers right now

    "1Password is already coded to opt out of the Windows Error Reporting (WER)"

    I've read all of this discussion and I'm struggling to understand what more you're asking 1Password to do.

    You point to other password managers but then don't mention that those other password managers suffer from exactly the same problems even with the 'mitigations' in place.

    Then the stuff that 1Password are doing to protect users against these types of attacks (e.g. disabling WER) you don't acknowledge.

    Going forward the only way for a balanced discussion is for you to explain what you want 1Password to do, how to implement it (top-level) and why. If you don't want to explain this (or don't have time) then I understood but it fatally undermines the validity of any point you're trying to make regarding the security of 1Password.

    KeePassXC said "this is a very complex topic with a lot of nuance" and references to what banks do on completely different systems, non-consumer facing, with entirely different architectures don't assist with finding a solution.

    This isn't a personal attack, it's me asking what you would suggest because without concrete information it's just a wish list of what you'd like in an ideal world.

This discussion has been closed.