Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
I was (and am) surprised that there are only two entries in JSON format (in plain text; maybe more in some binary format?) in the entire dump file and both entries are for 1Password itself (all the data I listed). I'm curious why it's only those. Maybe I should try a Watchtower check and dump again to see whether anything changes? (I don't have access to that Windows PC for several hours)
@XIII: Ah! I understand completely. Thank you! Indeed, that's the thing that sucks about all of this, it's just non predictable. It would be much better for all of us if it were possible to say something like "if you do X then Y data will remain in memory for Z time". That's much more manageable, both technically and at a cognitive level -- much less frustrating, as everyone could make decisions based on that understanding. I just don't have a good answer for you there, though I do suspect you would get different results after a Watchtower update, especially if something changed and the check had to be performed against the database again. Again, I'm sorry I can't offer you more than than. :blush:
0 -
@brenty Thank you very much for your reply. I know it must be very busy for you guys in the last couple of days, and I totally understand you guys will need some time to think of a strategy to cater for that. What I wanted to emphasise is the high risk of exposure due to the low barrier of attack and high value of the target.
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).
Because this attack does not require privilege escalation, nor exploit any OS security vulnerabilities, nor stay in memory as a background process, its behaviour would be very similar to normal apps, and make it hard for antivirus or HIPS applications to detect. The attacker doesn't need to target any specific person. He just need to distribute the program as a game, a utility tool, or even embed it in an existing legitimate app, and then sit and wait for data to flow in. There is no remote control, no further compromise, and little to no footprints on the system during the entire attack session.
It's true that some clipboard monitoring tools don't necessarily need privilege, but that has severely limited its capability to gather the valuable information. It has to stay undetected for a long time, and if it's lucky, steal the password while you copy and paste. But with password manager extensions like 1Password X in Chrome, passwords are no longer filled using clipboard, further reducing its capabilities. That's why hackers won't bother with these little tricks nowadays.
Password managers are an entirely different kind of targets. It not only stores credentials for websites, it also includes legal documents, passports, bank account and passwords, credit cards, medical files, and much more. Any of this can be classified as SPI (Sensitive Personal Information). In addition, people can store job-related secrets in it, such as company VPN credentials, production server credentials, trade secrets and patterns. It is virtually a invaluable information warehouse, with every kind of information being the target of hackers for decades. In the old days, hackers design sophisticated malware, rootkits, key loggers, or remote control agents to penetrate user's machines, but because sensitive information are scattered in a number of places, information gathering is limited and require huge human efforts. But with this vulnerability, hackers just need to hide a small un-elevated program to be executed, and then wait to collect this huge collections of high-value secrets to compromise not only a person, but a company, or even a country.
If you want people to put so many secrets in your app, you have got to do everything in your power to keep it secure. This vulnerability is a single point of failure in the entire security system in the digital world. It is so easy to exploit, yet has so much value. I bet it will become a very hot target in the coming years in the security industry. If the current technologies in the market cannot support the centralised management of so many secrets, then I think the time for password managers are still yet to come.
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.
I was not saying we shouldn't use 1Password, or password managers in general. In fact, I am quite an advocate of password managers and especially 1Password. I was simply suggesting people not using a broken software that is known to leak secrets until it's fixed. That's why I was saying using 1Password X with Chrome instead of the Windows app for the moment, because Chrome has better memory protection than the 1Password Windows app, which you also agreed. Having secrets scattered in different places is no worse than having all secrets store in one place and leak them to an attacker in an easy attack.
I hope you understand my concern as a software developer and a heavy user of 1Password. If I don't want to use your app anymore, I would not spend 40 minutes writing this thing.
Thanks again.
0 -
Thank you very much for your reply. I know it must be very busy for you guys in the last couple of days, and I totally understand you guys will need some time to think of a strategy to cater for that.
@alexyang: Likewise, thanks for your patience and willingness to have a dialogue. Indeed, it's good to be busy because that means people care about 1Password, but...yeah, I think in a perfect world all involved would be better off not having to worry about something like this. :)
What I wanted to emphasise is the high risk of exposure due to the low barrier of attack and high value of the target.
I'm really sorry to belabour the point, especially because I understand the objections to this, but this is exactly our concern: you're not wrong, but there is a very low risk of exposure except in a situation where the machine is compromised, either locally or remotely. I get that the conversation doesn't stop there, but it's really important that we don't blow this out of proportion. For the average person who is security conscious and practicing good hygiene, they're still better off using 1Password or another password manager in the list than not, because the alternative is, in most cases, not having anything encrypted at any time and using the same crappy passwords we all used to when we didn't know any better. No one's 1Password data is going to spontaneously end up in the hands of bad guys. I know you're not suggesting that, but someone reading a discussion like this and not understanding the full context or all the particulars sees words like "leak", "exposure", "hack", etc. and gets that impression. That's why we're so tiresome about reiterating this point. Thanks for bearing with us.
Because this attack does not require privilege escalation, nor exploit any OS security vulnerabilities, nor stay in memory as a background process, its behaviour would be very similar to normal apps, and make it hard for antivirus or HIPS applications to detect. The attacker doesn't need to target any specific person. He just need to distribute the program as a game, a utility tool, or even embed it in an existing legitimate app, and then sit and wait for data to flow in. There is no remote control, no further compromise, and little to no footprints on the system during the entire attack session.
While I don't agree with using the term "attack" since there is not one as far as we know, you raise good points. I'm sorry that we don't have a solution to that currently. Ironically, 1Password already often gets flagged by antivirus software because of it's use of encryption (which I can only guess is triggered by heuristics meant to catch ransomware). We need to move toward more aggressive handing of unencrypted data, and that will probably result in more false positives, but there will always be tradeoffs.
It's true that some clipboard monitoring tools don't necessarily need privilege, but that has severely limited its capability to gather the valuable information. It has to stay undetected for a long time, and if it's lucky, steal the password while you copy and paste. But with password manager extensions like 1Password X in Chrome, passwords are no longer filled using clipboard, further reducing its capabilities. That's why hackers won't bother with these little tricks nowadays.
Very true. I didn't have passwords specifically in mind with the clipboard thing, but I should have been more clear about that. Anyway, you're right.
Password managers are an entirely different kind of targets. It not only stores credentials for websites, it also includes legal documents, passports, bank account and passwords, credit cards, medical files, and much more. Any of this can be classified as SPI (Sensitive Personal Information). In addition, people can store job-related secrets in it, such as company VPN credentials, production server credentials, trade secrets and patterns. It is virtually a invaluable information warehouse, with every kind of information being the target of hackers for decades. In the old days, hackers design sophisticated malware, rootkits, key loggers, or remote control agents to penetrate user's machines, but because sensitive information are scattered in a number of places, information gathering is limited and require huge human efforts. But with this vulnerability, hackers just need to hide a small un-elevated program to be executed, and then wait to collect this huge collections of high-value secrets to compromise not only a person, but a company, or even a country.
You're right of course, though I think you're running the risk of hand-waving the part where someone needs to download and install the malware, which needs to get past antivirus at that point and not get detected reading all that memory, just as we're sort of hand-waving the part where 1Password just needs to clear memory, etc. It's complex on both sides, but that's not to say that it's not important for us to do more to keep your data safe, just because attackers have to work at it too.
If you want people to put so many secrets in your app, you have got to do everything in your power to keep it secure. This vulnerability is a single point of failure in the entire security system in the digital world. It is so easy to exploit, yet has so much value. I bet it will become a very hot target in the coming years in the security industry. If the current technologies in the market cannot support the centralised management of so many secrets, then I think the time for password managers are still yet to come.
I have no doubt that we'll see malware that targets password managers at some point, and you're right that we need to continue to do more, even if I end up being wrong about that. Better safe than sorry.
I was not saying we shouldn't use 1Password, or password managers in general. In fact, I am quite an advocate of password managers and especially 1Password.
I understand completely. Thank you.
I was simply suggesting people not using a broken software that is known to leak secrets until it's fixed.
This is the thing that's the problem for me. We can argue back and forth about whether or not 1Password (and all password managers, and other apps, allowing the OS to manage their memory) meets someone's definition of "broken", or about there being a "leak". I'd argue that's not the case, but I think you also can have a good case if you define things a bit differently. What I'm concerned about is that rhetoric like that says to most people "don't use a password manager", when that's really the opposite of the message that either of us wants to convey. I'm sorry to be a pain about that, but I hope you get where I'm coming from. I definitely appreciate your position. Again, my concern is that the message many people are receiving as a result of coverage of what is actually a really solid research paper which comes to the conclusion that we should all use password managers, but that password managers need to get better, is "don't use a password manager"; and that's not going to help anyone. Heck, what's the point of improving 1Password if nobody uses it because they've been scared off? So I think that we need to be careful about overstating things.
That's why I was saying using 1Password X with Chrome instead of the Windows app for the moment, because Chrome has better memory protection than the 1Password Windows app, which you also agreed. Having secrets scattered in different places is no worse than having all secrets store in one place and leak them to an attacker in an easy attack.
I"m not sure I understand the last bit there, but yes browsers have some great security measures in place because they've grown up in such a hostile environment. If Windows and macOS had first been created early this century I think it would be an entirely different story. :)
I hope you understand my concern as a software developer and a heavy user of 1Password. If I don't want to use your app anymore, I would not spend 40 minutes writing this thing. Thanks again.
100%. Thank you. <3 We're really lucky to have not only passionate users, but also some really knowledgeable ones -- with a special thanks to you, DMeans, gazu, derek328, and others here I'm missing who have been contributing. I'm enjoying the current discussion, but I'll look forward to when we have more information to share on this matter.
0 -
@mzman (edit - and, it looks like @derek328 as well! :) ) - I appreciate your suggestion that we re-code our entire app in a different programming language and remove large chunks of its UI and functionality, but since neither of these approaches are anything that would be possible quickly, I recommend anyone who believes what you've just said you believe (that 1Password is adding no practical security to your passwords and that security through obscurity would be better/preferable) go with their instincts and use whatever alternative method seems most secure to them. To you. I think an honest read through the thread should serve to show that those claims aren't even close to accurate, but obviously when it comes to one's own digital security, each person's responsible for pursuing what they think best. Indeed, my recommendation is essentially what we've always said: that we're glad there's competition in the password manager space, and that security is a process and not a product (any one product, including ours), so if people believe other options work better for their personal needs or their estimation of their own security, then by all means, go pursue those, with our blessing. As long as people are using something better than sticky notes on their monitors or re-using the same half-dozen passwords because that's all they can remember, we'll be happy. Thanks for your comments. :)
0 -
1Password data can only be read from the memory if you are an administrator (same as KeePassXC)
This is incorrect, on windows you don't need to be an admin to read 1Password memory, you only need to run in the same user context. And then you have access to the whole database.
This can be mitigated by using existing (since win7) antimalware protection (far from a quick fix I'm sure) or starting 1password as administrator.
0 -
Proponent: I'll show you. I should tell you that there's one catch though. Everything I said only applies if you don't open 1Password and actually use it.
I think everything you said here is a valid critique, but can you not say the same thing about every password manager Security Evaluators tested? And password managers in general to one degree or another given that many of the discussed limitations are OS related?
0 -
Proponent: I'll show you. I should tell you that there's one catch though. Everything I said only applies if you don't open 1Password and actually use it.
This would be the same as other password managers. I listed off the results earlier in this thread what other password managers are affected by this same issue. At one point, the vault needs to be decrypted if you want to use it. There is no magic way to get decrypted data out and make it useable without making it plain text.
There was only a few password manager that did not decrypt the entire vault which is good but many of them did reveal the master password in plain text which is just as bad as revealing the whole vault. The ones that did not decrypt the entire vault and cleared out the master password still would need to have the encryption key in plain text if you want to decrypt any data. So they may have cleared out the master password but they just substituted it for the encryption key which is more valuable because its what does the work directly.
In other words, all password manager suffer from this but it does not mean you should stop using them. This whole thing has gotten blown out of proportions. It's like people are acting like the world is going to end because it might get struck by an asteroid. Sure, it's possible but the odds are not in your favor.
0 -
Thanks, dev team, for allowing an open discussion here!
@brenty, regarding the suggestion above about Secure Strings, I think I saw earlier than 1Password7 is C#? .Net does have a SecureString class, and in fact I reported a similar vulnerability a few years ago to the maker of a corporate, IIS-based password manager, and they were able to fix the problem entirely by switching to use this string class. Could be worth a look.ETA: Regarding the principle that once your computer is compromised, it's no longer your computer - that's valid only to a point; it's still important to build a time boundary around that. Malware will hit a user with a password manager. It will eventually get detected and removed. Perhaps every action they took during that time is leaked, but it should be contained to that. So the item I'd most like to see fixed is the caching in memory of passwords that haven't been viewed during the session. Even in a managed coding framework, this is doable and a way of containing the blast radius of a memory leak to the tiny fraction of a user's passwords that were accessed during the breach.
0 -
But is there a password manager program out there that we know 100% isn't vulnerable in the same basic way? I'm not a coder, but based on what I am reading, it appears that all password managers write either the master password, database entries, or both in clear text to memory. The ones evaluated by Security Evaluators certainly do and they are among the most well known, so I would be highly skeptical of any claim otherwise by any other developer.
The point is, what 1Password is doing is not unique - everybody else is doing it too. That's by no means an excuse. But there are a few here that act like what 1Password is doing is some uniquely horrible, inexcusable failure. If so, then all other password managers need to be viewed the same and held to the same standard.
Put simply, this doesn't appear to be just a 1Password problem, but an inherent problem to password managers (and all other consumer software for that matter).
Clearly, if there were an easy solution, everyone would use it.
0 -
One of the recommendations given here is to reboot your PC.
How does Fast Startup affect that?
(Would 1Password data be saved to disk or flushed?)
0 -
Great discussion, I'm from Brazil and I followed much of the discussion. (even if you do not know English and have Google Translate help).
But I still had a question, in the case of current Macbooks Pro with Touchbar, does this security problem exist? Because it comes with a separate security chip and the Secure Enclave for the secure boot capabilities and encrypted storage. As I use one of these I wonder if I am affected by the problem or not. Thank you.
0 -
You've both stated that a simple spreadsheet file could be better than 1Password, because you would probably open 1Password to use your passwords, rather than needing to search for a file on disk.
If you want to use your passwords, you'll open the spreadsheet too, and it will be in memory in the same way.
@mzman claims an unencrypted spreadsheet offers equivalent protection at best. For this particular attack vector that might be true. However, the encryption of password databases was never really primarily meant to protect from local malware. It is meant to protect:
- system or file backups
- copies used for any sort of synchronization process (manual or built-in) <-- especially this one, you can't safely sync without encryption
- accidental disclosure from sharing user profile directories, etc.
- portable copies of the database (the "put it on a thumb drive" method for the old standalone client, or other password managers)
- other users on the system with read access to your directories (including sysadmins). Yes I know they could install malware and probably get your stuff that way...but it's a little different for a sysadmin on a corporate network to intentionally install malware versus "only" snooping in their coworkers files
- probably other similar cases I'm not thinking of right now
@derek328 's idea of an encrypted spreadsheet is probably equivalent in terms of protecting the data while not in use, but would also be missing a lot of the features that actually make the password manager usable. Security at the expense of usability tends to drive people to do less secure things. Plus it would rely on copy-paste, and the clipboard is a whole other attack vector you'd need to deal with. The most recent Windows update, for example, has features to automatically keep a history of everything that goes into the clipboard, and sync that between devices. I think it might be opt-in for now but that's not entirely a new issue. And clipboard sniffers have been done in javascript alone in the past. Plus, if it gets synced to another device, the clipboard is very easy to monitor from an Android app. Linux desktops as well, but I doubt that's one of the supported sync devices.
1Password is aware of the problem and is working on it. We even know the internal name for it now which they use to tag all their related issues (LML).
In the meantime, just exit your password manager while you're not using it.
0 -
What a fascinating discussion.
I clearly represent an obscure use case, I don't use any of the browser-plugin/automatic entry/... features. I open the program, copy the one password I want, paste it into a web page, and quit the program. I run on a Mac, not logged in as admin (though even on Windows I don't let the wife and kids have admin accounts - they complain a lot but I'm just becoming hard of hearing about it). I shutdown my computer when I'm not using it.
I don't get the "I searched a dump and found my password" concern. If you hadn't already known the password, how would you have found it? With Address Space Layout Randomization (ASLR), even knowing the location from one dump won't help you interpret the next dump. I accept that the string I typed (and potentially other strings I typed) might be lying around in some OS/GUI buffer, along with that password I pasted into the browser.
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??
Everything in security is a compromise, and adding more features means there can be more attack surface. These features seem to have dramatically expanded the attack surface, particularly on Windows. There can be compromises on a client, that's why there is anti-virus, and certainly developers aren't suggesting that nobody with good enough hygiene to run 1Password doesn't need anti-virus on their Windows machines. The key is damage control, compromise doesn't get the whole database every time a single item is stolen. It seems that 1Password isn't contributing to good damage control procedures. For what features? Maybe we don't need all those features all the time if it comes at such a cost.
0 -
@HeartfeltSarah Bingo! That's the right, long term solution - get the platform providers (who control when memory is cleared) to provide the functionality.
Part of my job is to help companies assess cybersecurity risks across their entire enterprise architecture and prioritize security investments (I lead a team of 20 security architects that do that work for hundreds of companies every year). There's always variance in the results due to different regulatory and compliance frameworks, corporate culture and risk tolerance, and unique situations - in many cases it's a judgement call, and that's by definition unique to the individual or organization.
For the vast majority of regular Windows or MacOS users, the risk (probability*impact) - at present - associated with this vulnerability is low. For iOS it's extremely low, and for Android somewhere in between. We may (and probably will) see malware emerge that targets it, at which point the risk calculation changes, because probability increases. I'd argue that it will probably remain relatively low even in the presence of targeted malware (especially once the signatures and/or behavioral heuristics are known and can be detected and blocked) because the actor will still have to get that code onto the system - either through social engineering to install software, physical access to a running/unlocked machine, or via exploitation of a different vulnerability to surreptitiously install the malicious code. If I can do that, it's game over anyway. Note that all three vectors could compromise passwords _even if/when this vulnerability is mitigated_ by installing a keylogger or other credential harvesting malware. Once compromised, the malware would have to phone home to a C&C server to upload the data (another mitigation is having those C&C servers discovered and blocked via firewall rules or DNS records - for home users Quad9 or OpenDNS, also provide help).
So the difference between this particular vulnerability and general credential harvesting here is the impact of compromise - because the entire vault is loaded into memory, all passwords are exposed at once, versus over time. That's not trivial to be sure, but remember risk=impact*probability, so with good hygiene and appropriate countermeasures taken (e.g. stay off the seedy side of the internet, lock the machine when you leave it, only install software signed by a known developer, etc), it's still relatively low. Now if someone chains it to an exploit that dumps memory automatically when you plug in a USB device, to that device, that's a higher risk. At that point, superglue in the ports becomes an option :-).
For most users, the risk of credential stuffing by low-level actors using dictionary or social profile scraping attacks against targeted sites is far higher than this vulnerability. Given that, I continue to recommend that folks use a password manager. For those with unique threat models, killing the app periodically and/or rebooting the machine (or shutting it down - e.g. border crossings) may be a good idea.
Let me be clear, AgileBits does need to mitigate the vulnerability - attacks only get better, and I really do expect to see malware targeting all password managers now that it's been widely publicized. They have window to complete that work, and I suspect it's a hot topic internally. As I noted in my last post, regardless of the actual risk, they do need to address LML as this has made people feel as if trust has been broken, and trust is a critical business asset. Unfortunately it's much larger that it might be for Agile and their peers is that people are really bad at assessing risk, especially personal risk. If they were better, most social media sites would have far fewer users than they do :-). So regardless of the actual security risk, mitigations of the business risk are required, and fairly soon.
0 -
The authors singled out 1Password 7 for decrypting most everything and leaving it all in accessible memory. They pointed out that 1Password 4 was better in its protection of data in this regard. This is most painful to me, because I recently abandoned 1Password 4 out of necessity when interoperability with Chrome broke. It's a legacy product that was potentially more secure than the new version. They moved it in the wrong direction, from a security point of view.
1Password knows that good security is difficult. That hasn't stopped them from innovating and taking care with their design in many areas. I think they can do far better in this area. I think they know it too... and I would love to see an announcement regarding a change in direction soon. If that means disabling features and re-coding a lot of their software, they should do it.
I 100% agree with this. I've just gone through similar where I've installed 1Password 7 on Windows out of necessity. Only to find that it's actually worse than the long deprecated, and no longer supported 1Password 4. This really really really disappoints me. 1Password should never go backward in terms of security, and in regards to 1Password 4 vs 7 this is a significant back-step.
The blog post that says 1Password 7 for Windows: The Best Ever... is absolutely not true in this (most important) regard.
It actually offends me that due to 1Password 4 no longer being supported, I'm expected to pay good money for 1Password 7 which in this (most important) regard, is a downgrade from 1Password 4.
It also significantly offends me that the whole Lock-means-Lock (LML) thing is even an issue. That should never ever have been an issue in the first case and it significantly disappoints me that AgileBits have allowed this to go on for as long as it has.
It's time for AgileBits to prioritise the security of their apps over the touchy-feely things. Security should be the first and highest priority in all instances.
There needs to be an announcement/official comment as to the issues and the way forward.
0 -
I don't get the "I searched a dump and found my password" concern. If you hadn't already known the password, how would you have found it
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.
0 -
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.
0 -
Memory attacks are looking pretty relevant again. https://www.bleepingcomputer.com/news/security/thunderclap-vulnerabilities-allow-attacks-using-thunderbolt-peripherals/
0 -
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.
0 -
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
- Is 1Password team currently working on a fix or mitigation of the issue reported? (I’m not talking about Rust, which no one promised)
- 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)
- Will 1Password hire an independent security firm to audit and do penetration testing of the latest Windows app?
Thanks.
0 -
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.
0 -
- Is 1Password team currently working on a fix or mitigation of the issue reported? (I’m not talking about Rust, which no one promised)
- 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)
- 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.0 -
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.
0 -
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:
- You can write a new "secure" string using the SecureString API, but you can't read it when you need it; and
- 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.
0 -
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.
0 -
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.
0 -
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.
0 -
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
support+security@1password.com.Thank you.
Ben
0
