Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
That's really not relevant here, and I addressed it in another thread if anyone else is interested. Relevant to this discussion though, U2F would not solve this problem. You still have to decrypt data in order for it to be usable, and that still requires keeping it in memory for a time. The question is how to get rid of it reliably, without taking on additional risk in the process by managing memory yourself.
I disagree. I wrote out a long response but I think I can condense my response to this simple statement - Other password managers have integrated U2f (asymmetric method) into their products for the purpose of decrypting the local database of passwords.
Sure, using a hardware token doesn't solve some of the secure memory management issues - but it does take the issue of a compromised master password off the table. That IS PROGRESS. With or without secure memory management - u2f is a benefit.
I personally think that such secure operations should be offloaded entirely to a dedicated hardware token - which is the route Yubico has taken in a sense with their "Passwordless login". Basically making the token your first factor of authentication, and the password a second, optional method. By your own reasoning, if secure memory management is such a stretch to achieve ... then maybe the writing is on the wall. The solution isn't to dump all your passwords into a password management system (with a monthly subscription) .. maybe instead it should be to point all your accounts to dedicated hardware tokens that are less prone to such events.
0 -
As a principal software architect with a large computer company and 30+ years professional experience, I agree with the conclusion stated by @pwnell above. Something needs to be done to improve memory security.
Secure memory management is hard, but it is not impossible. It would require careful design and implementation. It would certainly require separate implementations for each supported operating system. It would probably require some code written in C and perhaps some assembly language. This means a substantial amount of effort in initial development and ongoing maintenance, but it is necessary for a high security product such as a password manager.
I must confess to being a little surprised by some of the comments from AgileBits personnel in this thread, and my confidence in 1Password has been shaken - particularly with the Windows implementation.
0 -
@brenty I already suggested it, but this thread grows fast, so it might be missed: keeping plain text in memory wouldn't be too bad if non-elevated apps didn't have access to 1password memory. There are some ways this can be done on windows, one of which is existing infrastructure for anti-malware protection. It brings whole process into separate protected context, so it becomes very hard to read process memory and influence it in other ways (by dll injection for example). There is some protection from even elevated processes. The technology is called Windows Protected Processes.
https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services-
1password can be split into core and UI processes, where core is running as protected and securely communicates with UI, exposing only minimal information actually requested by the user.
0 -
One way to reduce exposure on current version of 1password on windows is to always launch executable in elevated context (this is an option in properties/compatibility, "run as administrator"). This removes exposure to browsers and the like, but it also breaks browser integrations.
0 -
Hi, I'm catching up on a few things. A lot of people have made some very good points on why there is a real threat that must not be dismissed.
I do want to remind everyone who is making these points that we are not dismissing the real threats, but we are trying to point out that the many of the fears that many readers get from the Washington Post article are misplaced. We are trying to calm people who are panicking as a result of misunderstandings.
As I've said, we are exploring solutions (or improvements). But because we can't promise either a date or what those solutions will look like in their final form, we were not willing to say to a journalist or the public "a fix is coming soon".
So here are some of the real threats that people have raised.
Forensic style attacks
@pleasantone points out that,
the case in question that you keep saying is rare seems to be exactly the case we’d have with a forensic attack on a suspended (laptop closed, 1p previously unlocked) system.
The attacker would still need the ability to read system memory. So a cold-boot attack might be needed in this case unless the laptop is not protected from a DMA attack (which is something I find more plausible than a cold-boot attack).1
This is why we do worry about this issue. Just because I think that the Washington Post article massively overstated the threat doesn't mean that there is zero threat. And so this is why we are exploring solutions.
Restrictions on when malware is can do its thing isn't implausible
As with the previous point, there are other ways to plausibly imagine an attacker who might only have access to system memory when 1Password is locked.
@luz describe the case
with scrubbing, the malware would have to wait for a user to actually type in the master password, which greatly increases chances of being detected before that happens (by virus scanners, or the user realizing having done something stupid shortly after clicking the install button of that flash update...)
Obviously the less time secrets are in memory, the better. Sort of quick, smash and grab malware would be less likely to get at those secrets if they weren't around. In all honesty, I'm not really as worried about this scenario as I am about something like DMA attacks. When actively using your system, you do tend to keep 1Password unlocked.
Running as admin
[This section added after comments by ... (I will have to look it up)]
As has been pointed out in this discussion by some helpful contributors, many Windows use Administrator accounts as their primary accounts. This gives every process they run some elevated privileges. We have correctly been saying that (most) exploits require an attacker with elevated privileges. That is process A isn't able to read the memory of process B unless A has significant powers. However, I (coming from a Unix-world) failed to recognize that unsafe, but not uncommon, usage habits on Windows may mean that any process launched by the user will have some elevated privileges.
Trust and principle.
A few people have implicitly pointed out what I think may be the deeper problem here. And independent of any particular attack scenario, it is the reason that we have been looking at this problem for a while and have made some improvements over the years. (For example, we did a lot of work some years back on this for 1Password for Mac that reduced the time that some secrets remain in memory, and why we do have sketched out some ideas for how to approach this on Windows).
The problem is that we invite users to understand certain things about what it means for 1Password to be locked. And people will behave according to that understanding. That is people will develop an implicit mental model of what happens when their password manager is locked, and they will base their behavior and choices on that implicit mental model. People feel betrayed by the fact that the mental model that we have encouraged them to develop is substantially untrue or encourages unsafe behavior.
Now in general, the complexity of 1Password means that the mental models that users develop is going to be different from what actually happens. (The long chain of keys between Master Password and keys used to decrypt data is an example of that). This is inevitable. But just because there are inevitable mismatches between the gory detailed technical reality and the invited mental models doesn't mean that we should be happy with just any mismatch.2 And in this case the mismatch between what actually happens (on some platforms) when a user locks 1Password and what they are led to believe happens is wrong.
Our internal discussion of this over the years has had the labels "Lock Means Lock" (LML). And this is less about actual anticipated threats, and more about bringing actual behavior more closely in line with implied mental models.
LML implemented and LML delayed
We have worked on Lock Means Lock (LML). We do want to bring actual behavior and the implied mental model into closer agreement. And effort was focused where we could reasonably do so and where the real threats were the greatest: DMA attacks on Macs. The threat of DMA attacks was most significant on Macs, and the memory management system provided by our development tools and the operating systems made it possible for us to make substantial improvements. It still took a lot of work, and it isn't perfect (as immutable strings do hang out in memory longer than we'd like). But over the course of about six months we did do this. (We don't keep careful track of developer hours on specific issues, so I don't have exact figures.)
A combination of the fact that DMA attacks were less of a threat against Windows (and mobile devices), and the fact that the same amount of effort for 1Password for Windows would bring smaller actual improvements (because of how garbage collection works), we deferred work on this to do other things. (Like bringing full OPVault support to 1Password for Windows).
Because the actual threats are limited3, and in some environments there weren't really practical solutions, this has been deferred. This is ultimately my responsibility. When a development team has a list of things to work on for any three month period, it is hard for me to say, "well drop X, Y, and Z; because LML is more important" when the actual threats arising from not doing so are limited. And so for years I failed to say "you must work on true lock now, even if it means deferring things that users are actively clamoring for."
I dislike the idea of setting priorities for security improvements based on what has gained tracking in the press, but I expect that LML will now be worked on more quickly than it otherwise would.
-
Recall that I explicitly pointed out the threat of DMA attacks to Fowler in one of my "lengthy emails" to him while he was researching the article. We do not try to conceal the real threats. I was also hoping that this would help him see (and communicate to his readers) where the threats are and aren't. (Well so much for that hope.) ↩︎
-
Another oft-discussed case where there is a potentially harmful mismatch between implied mental model and actual behavior has to do with the semantics of a Master Password change. I'll look up the link later, but I gave a talk at PasswordsCon some years back on this. Like the issue of secrets residing in memory after lock, this issue about the subtle semantics of a Master Password changes has been discussed and acknowledged openly for years. ↩︎
-
Again, the threat is far more limited than most people reading the WP article have been led to believe. But that does not mean that we are dismissing the real threat. But we aren't going to fix this in a way in which the cure is worse than the disease. ↩︎
0 -
-
That's a very informative comment, @jpgoldberg. Thanks.
0 -
@arabbit asked
If [the Secret Key is assumed to be available to a local attacker], why is the Secret Key touted as such an important factor in the encryption of our data?
The Secret Key is designed to defend you if someone gains access to your data from our servers. It means that data that we hold on our systems cannot be "cracked" with some automated master password guessing system. This not only protects you if our servers are breached, but it also protects you from various sorts of insider attacks.
Quite honestly, we did not want to host data that could be "cracked". And while we try to encourage people to have strong and unique Master Passwords and we use 100,000 rounds of PBKDF2, we wanted to make sure that nothing can be done with data that might be captured from us. So yes, this really is an important part of your security. It just is aimed at a different threat than you might have thought.
0 -
@jpgoldberg Yes, you nailed it. It’s about the implicit model of assumption of the program’s behavior, and the danger of the inadvertent data leak on exception. Thank you. Lock must mean lock, within a fixed amount of time (in ms or low seconds).
1) If the adversary is bashing down someone’s door, they should be correct in assuming that closing the laptop cover, hitting the screen lock button on the phone, waiting for the screen lock on their desktop to kick in, or hitting the lock command sequence in 1p makes it so that someone needs to threaten your person with a $5 hammer before they can get access to all your passwords.
2) If enough information “ever” (outside a tiny window) leaks due to an exception dump (or privileged memory access from an admin process) that the master (or more than one recently used password) leaks, that’s a deep concern. I agree with your point about key-loggers being a vector, but memory proves and accidental disclosure are also problematic. Root on the Mac shouldn’t compromise an already unlocked 1P process.
I feel for you guys, and I’ve been in the exact same situation in the past. I didn’t like showing up in the WSJ and having to defend decisions when my firm’s trust had been breached. I’m glad you’re looking at it beyond the optics, now.
Fundamentally if we don’t feel we can trust that our password manager does what intuitively we think it does, no feature is a higher priority. I’m sad/glad that this escalated the issue. Hopefully you folks can discover a previously missed solution without too much pain.
Good luck.
0 -
@jpgoldberg thanks for the response, but would like to follow-up with you / MikeT / brenty:
I think based on this single discussion alone (and there are plenty), we've already seen feedback from numerous professionals (be it developers, infosec architects, PMs, etc) that have offered better, more capable solutions that 1Password 7 has failed to implement - but should have. Namely:
1 - why would you ever build 1Password 7, a security product, using a language that does not allow strong memory management? there are plenty of frameworks, languages, and Windows/macOS features that 1Password should've implemented / practiced for better security without need to sacrifice usability, like you can split-up UI & core protected processes.
2 - why would you still then commit the entire 1password db into cache memory, especially since your team already knows 1Password 7 cannot provide secure memory management? that was a poor product design.
3 - why does 1Password consider something as basic as memory & secrets scrubbing to be "unfeasible", even though it is entirely feasible, a functional necessity, and is in fact often a basic requirement in industries like finance.
4 - why claim the secret key + master key combination to be "better" than two-factor authentication? sure, this combination may help if one has compromised AgileBit's servers, but this is just one-side of the coin, and securing just one-side is not good-enough security. statistically, it is a lot more likely that a user's entire password cache leaks out of the end-point due to a memory dump triggered by malware / software telemetry logs.. again, a poor product design choice.
5 - if 1Password 7 caches our master key, secret key, passwords & other stored data in such a way that can be extracted as cleartext via a simple memory dump (be it accidentally by telemetries or maliciously by malware etc) at any point the software is running, why build client-side encryption at all? this is a crippled, almost practically useless implementation against very, very basic attack vectors that require no expert skillset (and on that point, i feel now the support articles here, here, here and other resources from across AgileBits may have included false adverting).
6 - why didn't 1Password communicate to us in its marketing that the lock out function is, it seems, mostly just a UI / visual obfuscation mechanism right now. false advertising again, or just being economical with the truth? :/
7 - why leave information in public view that's no longer accurate, stating that 1Password does not keep our master password in memory, when in fact at some point since 2015, the 1Password team has apparently decided to settle for a downgrade in security, and has your team failed to communicate such a critical change to the public?
8 - why isn't 1Password committing to a critical security fix right now? the cat is out of the bag, and you can bet every black hat out there is eyeing this treasure trove. you need to commit to a security fix, and with a fast deadline.
"I cannot commit" will not protect 1Password from a class-action lawsuit.. or its users like me online..
0 -
"why isn't 1Password committing to a critical security fix right now?"
This one is most important. Now, when everybody knows how to exploit all your passwords. To be honest I am terribly unsatisfied how you handle this issue. This should be top priority issue now. Many users even store 2fa in the 1password.
0 -
@derek123 repeats a number of good questions
1 - why would you ever build 1Password 7, a security product, using a language that does not allow strong memory management?
I've largely answered that question in https://discussions.agilebits.com/discussion/comment/493107/#Comment_493107
You didn't like the answer, but repeating the question isn't going to get you a different answer.
Sure, in a perfect world, we would have started development in Rust instead of C# and we would have separating things out from the beginning. We have been moving in that direction.
there are plenty of frameworks, languages, and Windows/macOS features that 1Password should've implemented / practiced for better security without need to sacrifice usability, like you can split-up UI & core protected processes.
It's not a question of sacrificing usability. It's a question of security/security trade-offs. We aren't going to open up ourselves to a large class of potential security issues in order to address a narrow one. But I repeat myself.
2 - why would you still then commit the entire 1password db into cache memory, especially since your team already knows 1Password 7 cannot provide secure memory management? that was a poor product design.
I will defer to others on that question. (@MikeT ?)
3 - why does 1Password consider something as basic as memory & secrets scrubbing to be "unfeasible", even though it is entirely feasible, a functional necessity, and is in fact often a basic requirement in industries like finance.
That brings up a question that I would also like to ask @DMeans about as well. Are the finTech systems that you are referring to running on consumer systems? If so, I would love to learn about them and how they are developed. But most end user consumers are doing their banking in web browsers. And if you think that C# and .NET have memory retention problems, they are nothing compared to web browsers.
Seriously, we've had people write into us saying that because of the article they were going to switch to a browser builtin password manager! That's not exactly moving away from the problem.
4 - why claim the secret key + master key combination to be "better" than two-factor authentication? sure, this combination may help if one has compromised AgileBit's servers,
That is what it is designed to do. That is what it does.
but this is just one-side of the coin, and securing just one-side is not good-enough security.
Note that 2FA would not solve either the problem of a server breach nor the problem of malware on the machine on which you unlock 1Password. So where the Secret Key solves one of two problems, 2FA solves neither of those two.
statistically, it is a lot more likely that a user's entire password cache leaks out of the end-point due to a memory dump triggered by malware / software telemetry logs.. again, a poor product design choice.
You have bundled a huge amount of local attacks there. And the relevant ones could also apply to 1Password when it is locked. But I repeat myself.
5 - if 1Password 7 caches our master key, secret key, passwords & other stored data in such a way that can be extracted as cleartext via a simple memory dump (be it accidentally by telemetries or maliciously by malware etc) at any point the software is running, why build client-side encryption at all?
Because we do aim to defend against the attacker who gains read access to a users disk. (Note that not all password managers do this. Some do not encrypt locally on disk.)
We have seen malware that scopes up 1Password data on disk (among lots of other things) and sends it off to a C & C. Encrypting data on disk addresses a clear and well defined (and likely) kind of attack.
6 - why didn't 1Password communicate to us in its marketing that the lock out function is, it seems, mostly just a UI / visual obfuscation mechanism right now.
Thank you. You have raised a good and fair point. I do not have a good answer for this. In 1Password for Windows "lock" does not really mean "locked". Yet the UI implies otherwise. This is my single biggest reason for wanting this issue addressed. See my comments in https://discussions.agilebits.com/discussion/comment/493809/#Comment_493809 where I point this out.
7 - why leave information in public view that's no longer accurate, stating that 1Password does not keep our master password in memory,
Seriously? You want to to comb through the forum to fix or remove anything we've ever said that is no longer true? And you know as well as I do that if we removed such content, you or someone like you would be scream at us for trying to re-write history.
8 - why isn't 1Password committing to a critical security fix right now?
Because the issue is no more of a threat to 1Password users today than it was a week ago. And it will be no more of a threat a month from now than it was a month ago.
the cat is out of the bag,
This behavior is not a secret. It hasn't been a secret. This has been a publicly known issue for a long time. But I repeat myself.
For all the good my "lengthy emails" did for Fowler's understanding of the issue, I should have just responded like my counterpart at KeePass and say that this is "old news". (I assume that that their response was more than that, but that is all that was reported in the article.)
0 -
Does this mean that any application running with in the same user context as 1Password has read access to master and secret keys
No. The attacker needs elevated privileges to directly read 1Password process memory. [Update: As @UnFleshedOne correctly points out in https://discussions.agilebits.com/discussion/comment/494032/#Comment_494032 most Windows users run as Administrator, and so in practice anything they run is running with "elevated privileges"]
I don't want to be dismissive of the threat though. If the attacker can force BSOD crash, then by default Windows settings, a memory dump will be written to disk. (This is something I learned about Windows just yesterday.) And as I mentioned in multiple places elsewhere (including in my email to the author of the Washington Post article) that some systems will be vulnerable to DMA attacks.
0 -
@brenty
Hi! Thanks for the response. :) I prefer actionable steps rather than scaring myself.
BTW, what about 1Password on macOS? The "lock" state is (relatively) safer than Windows because of the different mechanism of the OS itself or not? Is there any difference between the MAS version of 1Pass and the standalone version when facing this... whatever memory issue? ( I mean, maybe the app sandboxing could lower the risk of memory dumping?)Donald
0 -
Note that 2FA would not solve either the problem of a server breach nor the problem of malware on the machine on which you unlock 1Password. So where the Secret Key solves one of two problems, 2FA solves neither of those two.
It's as if a "compromised endpoint" is being used here as an excuse for 'we-cant-do-anything-ism'. Why use encryption at all on the local machine?
If the server was breached and lets say they had my master key .. IF ... IF the decryption of my data was dependent upon a two factor setup that consisted of the master key along with my hardware token .. then my data would be no good to an intruder. Presumably.
There seems to be a lot of effort to disregard any notion of a hardware token .. i dont think ive ever read a comment here from an agile employee who had anything positive to say about a hardware token technology other than to state the following:
"u2f cant help here"
If i logged into an a third party service with the traditional password and a second factor, opting to use a hardware security token ... and if my machine was compromised, sure my password could be extracted but that second factor ... that hardware token has kept my account secure.
That ^ is the reality of the situation I believe. Not that Agile cant either integrate with hardware tokens or take other approaches ....
You have said 6 million times that if your machine is compromised then its game over. Your right about that ... except that if your logins are secured with a dedicated hardware token, you have other safeguards in place.
How agile fits that into their model? I dont know. Consumers have been left with ... IMO, no other choice.
0 -
Hi @Donaldd,
I realize that there is no way to read everything that has been posted already. Here is something I said about 1Password for Mac a few days ago
in principle we have the same issue on Mac, but in practice these things play out differently. It appears that these do get cleared from memory faster on the Mac. Some of this can be attributed specific design, some to automatic reference counting versus garbage collection, and some operating system environment.
We were more concerned about this on Mac when DMA attacks were a thing. But fortunately that environment made it easier to make progress on this. But some of the fundamental issues remain.
0 -
@jpgoldberg Thanks for the quick response :) Yes, it's a little bit difficult to catch up everything on this thread. :( Maybe a specific Q&A would be better.
0 -
I can understand you think currently people are blowing this out of proportion due to the article, but I think for most of us that are technically inclined (including the several highly experienced network admins and devs who have commented on this) are now more intrigued about this than anything.
You are saying you CANT do things even though the developers among us know you CAN do it, you are just choosing not to because it would result in instability (which is a perfectly reasonable decision in programming).
However, this whole approach of; "Us fixing this will result in more security issues" I just don't understand.
If you were to hypothetically clear the memory when a user locks their vault, how does that introduce any new security issues? It might introduce some instability issues (Not sure how?), but there is no way I can possibly thing this would introduce new security issues.On top of all this, you should modify your landing page to reflect this as it spreads many false promises that now me and many other users are "trapped" in because we've already paid for the service.
- “Your logins and private documents are securely stored in your password vault. This keeps your information locked away from thieves, hackers, and other unsavory types.” - This is completely invalid now given all of this. It should be rewritten as “Your logins and private documents are stored in your password vault.”
- “Your privacy is our top priority. A combination of policy, innovative thinking, and a deep respect for your right to privacy ensure that your data is always kept safe and secure.” - This entire point is completely invalid now.
I don't want to sound like a jerk, but this is just the facts. You should NOT be falsely advertising these features when your program does not actually have them. Once you have implemented them then you can feel free to add them back.
Also, just as a side note, I really don't like comparing and saying things like “Service X has this, so why don't you” but I'm going to make an exception here because I feel something dodgy is going on in the 1Password team.
Bitwarden is completely open-source, is written in C# (just like 1Password is), and they have managed to do most of this security stuff in regards to clearing memory, etc...
I've never once heard any of the people I know using Bitwarden complaining about "stability", so it's obviously possible to clear the memory without introducing stability issues?
0 -
@jpgoldberg Appreciate the nuanced replies. For what it's worth, I do miss C. Hey, lint free was bug free right? ;-)
If someone has enough access to my machine to do a direct memory read, it's game over anyway, so while I'm concerned about this particular threat, it's one among many. For what it's worth, I have no plans to change my choice of password vault.
I wonder how many people concerned about this, happily go to 1password.com in their web browser (the single most exposed piece of code on the machine), type in their master passphrase, and go into their vault? Or sync their vault via dropbox without a secret key because they use old versions of 1P to avoid the subscription cost? Or have a weak master passprhase (i.e. < 20 characters), or are still using 1P4, probably on XP (absurd that they tested an out of date version). And I could go on....
Regarding the financial systems and clearing memory, those apps are almost always not running code on the client - think J2EE, COBOL, etc on the back end, with a browser-based front end. IAM federation/SSO products handle the authentication, so the actual password exposure is minimal. That's another example of the tradeoff discussion - SSO and/or federation reduces some risks, but introduces others, and getting it right is a finicky business.
You hit the nail on the head in regards to the emotional response being based on mental models. Unfortunately those models are reinforced by the UI design. Bringing the UI state and the security/encryption state into sync would be a good goal, even if it means slower performance, by not caching the entire decrypted vault in memory, or killing the process completely when the lock button is hit. Mental models, right or wrong, need to be respected. Maybe introduce a 'locking' state until memory is confirmed to be cleared, and only then show 'locked'?
In the end, security is a game of whack a mole. So if your team can do something to reduce the time between mole and whack, well, that's a good bit of work.
0 -
I wonder how many people concerned about this, happily go to 1password.com in their web browser
1Password forces this, it's not an option if you want to manage your account or turn on Travel Mode. Seemed to defeat the purpose to me.
@jpgoldberg in travel mode are the vaults truly removed from the device or just hidden from 1password?
What features did you add that meant you couldn't update support pages that describe data as always encrypted when you aren't using it?
0 -
Reducing web client dependence
As @dougl observers, web browsers offer even fewer tools to manage memory and remove secrets. We can argue about the virtues and drawbacks of using C, C#, or Rust for the Windows 1Password client, but with the web client we are stuck with JavaScript.1. Some of the saddest things I've seen in our own inbox or on the Washington Post site are people saying that they are now going to move away from using native client password managers to just using browser built in ones. If you are concerned about secrets not being cleared from memory, moving to fully in browser tools is not going to be a good thing.
@arabbit correctly points out that
1Password forces [use of the web client]
Yep. As we've noted in several places2, the web client can't offer the same sorts of security that the native clients can. (And not just because of Javascript). And so one of the things we are doing is trying to bring more of that sort of functionality to the native clients. Indeed, this has been a big part of the work that has been going on with 1Password for Windows over the past year. Reducing reliance on the web client is a security improvement as well as making things easier and more convenient for people.
This is also why I don't want work on security improvements to be driven by what happens to get traction in the press (and particularly when the actual threats are widely misunderstood). I'd like to continue to work on both reducing dependence on the web client and reducing the risks of the web client.
Travel mode
In travel mode are the vaults truly removed from the device or just hidden from 1password?
It is removed from local storage by the clients.
Docs?
What features did you add that meant you couldn't update support pages that describe data as always encrypted when you aren't using it?
Do we have support pages that state or imply that data is always encrypted in memory? It is always encrypted when written to disk or transmitted over the network. (I have to confess to not having read everything that has been posted in this discussion, so feel free to message me with something that will help me find those support pages.)
-
More correctly, we are stuck with something that compiles to JavaScript. We use Typescript. But we are stuck with JavaScript's memory management. (And before someone suggests WebASM, maybe someday. But we need the technology to mature greatly.) ↩︎
-
I'm not going to hunt for all of the places that this has been discussed, including forums, social media, etc. It is discussed extensively in the 1Password Security Design document. ↩︎
0 -
-
@brenty They're definitely not being glib. I never said they were. But your team's response doesn't come across as anything other than PR fluff. There's no sense from you that it's a flaw that all your passwords can be extracted from memory trivially. Your position seems to be that it's unfortunate people think that it is a problem.
0 -
(Lars) But 1Password has existed in one form or another since mid-2006, and in all the time since then up to the deployment of 1password.com accounts, there has never been a breach reported to us or in the press of a user's encrypted database -- and there have been plenty of lost, stolen devices in that time, including many from rich people, celebrities, and other "high-value targets." Yet in all that time, no reported breaches.
The bad guys don't usually report their success to the hacked do they? Well at least not until the well has been pumped dry. Sometimes the good guys ride to the rescue. A breach (and more) has been reported in the press of an encrypted 1Password database.
The case study released by Independent Security Evaluators, and a story published in the Washington Post on 2/19/19, make clear that dangers lurk in 1Password and other password managers. Read both the case study and the Blog post (links below) to get a complete picture of the research.
Copied from the following link is the conclusion drawn by Independent Security Evaluators in their case study titled: (Bold text was added)
Password Managers: Under the Hood of Secrets Management"Conclusion:
All password managers we examined sufficiently secured user secrets while in a ‘not running’ state. That is, if a password database were to be extracted from disk and if a strong master password was used, then brute forcing of a password manager would be computationally prohibitive.
Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.
This was most evident in 1Password7 where secrets, including the master password and its associated secret key, were present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry is exposed in a ‘running unlocked’ state and the master password exists in memory in an obfuscated form, but is easily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it would comply with all proposed security guarantees we outlined earlier.
This paper is not meant to criticize specific password manager implementations; however, it is to establish a reasonable minimum baseline which all password managers should comply with. It is evident that attempts are made to scrub and sensitive memory in all password managers. However, each password manager fails in implementing proper secrets sanitization for various reasons.
The image below, Figure 21, summarizes the results of our evaluation:
"Technically oriented readers may also be interested in the more detailed explanation, in the link below, including an animation (Gif) demonstrating recovery of a master password from a locked instance in 1Password 4.
Recovering the Master Password from a Locked Password Manager (1Password 4)Lars statement above, $100,000 unclaimed "prizes" offered to hackers, and generally overstating the security of 1Password should be viewed skeptically by consumers. To be clear, 1Password is a leader in password managers, but consumers must perform due diligence before handing over their data and money.
0 -
@bmitchelmore: I'm sorry for not being clearer, and that you got that impression in the first place. My point is that we're saying the same things. We're in agreement on this. :)
To summarize, password managers, including 1Password, do not currently manage their own memory. The upside to this is avoiding a whole class of security and stability issues which affect software that does. As an example, the latest Windows rollup included about 70 critical vulnerabilities, more than half of which were memory-related. That's not a slag on Microsoft. It's a hard problem, and an OS does not have the luxury of utilizing memory-safety for everything. The downside to not managing your own memory is that you don't have direct control over clearing it. That's where the topic of this discussion comes in. But it's not as simple as just switching to managing our own memory, because that causes other issues. And as the researchers pointed out,
Keylogging and Clipboard sniffing are known risks and only included for user awareness, that no matter how closely a password manager may adhere to our proposed ‘Security Guarantees’, victims of keylogging or clipboard sniffing malware/methods have no protection.
Thus, as we've said earlier, that when you're running malicious software on your machine, it can capture your secrets without having to read memory, as you yourself access them. No matter what, data has to be decrypted in memory in order for it to be usable by you. So in a scenario where you have malicious software running on you machine, even once the data has been removed from memory, there was nothing stopping it from capturing it from memory earlier, while you were using it, or doing something much less complex and sophisticated like logging your keystrokes, taking screenshots, monitoring the clipboard, etc. But while this is difficult enough of a challenge that all of the software looked at by the researchers suffers from it, if we can all find ways to get more control over this without giving up the benefits of memory safety, that will be a win for the industry -- which is the reason this research is important, and why it was undertaken in the first place.
I don't think it's fair to complain that we're being "glib" when we're talking to someone else and making an effort to not repeat what they've already read. I feel bad saying essentially what has been said already, since others may be weary of reading it by now, but hope that helps clarify for you and perhaps others new to the discussion.
0 -
Thanks @dougl for helping me better understand the financial tech environment.
Regarding the financial systems and clearing memory, those apps are almost always not running code on the client - think J2EE, COBOL, etc on the back end, with a browser-based front end
That is what I suspected. And that is almost certainly why we hadn't encountered them. (But I do appreciate the suggestion to look at it) Those tools and approaches are just not going to be applicable for something running on someone's home computer.
You hit the nail on the head in regards to the emotional response being based on mental models. Unfortunately those models are reinforced by the UI design.
Yep. And so I think that people do have reason to be angry. There are also other reasons to want locked means locked (LML). It would prevent certain sorts of logic errors from "unlocking" 1Password under the wrong conditions. We could exclude a whole category of potential bugs by simply not having the secrets available within the program when "locked" even if we can't reliably clear from system memory. I should not have let this situation persist as long as it has in 1Password for Windows.
This is one of the things that is making this discussion so hard/ The Washington Post article (and various followups) led a large number of people to completely misjudge the actual risks. It would have been easier to us to say "you'll got it wrong, there are no risks". But there are (much smaller) risks, and there are design and resource allocation choices that we made that left a grossly misleading UI in place long after actual behavior should have been brought into line. I want to apologize for that and discuss a plan to address it1, but we also need to deal with the people who are panicking and making very poor security choices as a consequence of a misunderstanding of the real risks.
So forgive me if the message that I'm trying to get out is "Don't panic. We can't protect you if your computer is substantially compromised." That is the message we need to get out there. That isn't meant to dismiss either the real threats or the real ways in which should have done better. But what I'm trying to repeat is "Don't panic. We can't protect you if your computer is substantially compromised." I would also like to say that with some very special and limited exceptions, anyone who claims that their software is safe when running on a compromised computer is lying.
For what it's worth, I do miss C. Hey,
lint freewas bug free right? ;-)I miss it, too. And I'm even old enough to have used pre-ANSI C. Oh that reminds me. Someone in this discussion, I think it was @DMeans, posted a helpful screen shot of Vim and a memory dump. So I'm going to show off my geezer cred and say that I moved up from
edandextovi. For me, knowing whygrepis called "grep" is not a matter is not having been taught the history. I lived it.-
As you can imagine, there has been a great deal of internal discussion. I know that I failed to push hard for getting this resolved. So I certainly bear responsibility, but on the other hand, we've been doing other things that bring about security improvements. I mentioned earlier that reducing dependence on the web client has been a big part of 1Password for Windows development over the past year or so. ↩︎
0 -
-
I hate to sound like a broken record, but regarding keylogging, wouldn't U2F basically fix/prevent this completely?
Even IF someone infected your entire computer, and they keylogged your master password, as well as compromised your TOTP somehow, they STILL wouldn't be able to get into the vault without the hardware key.However, even if this was implemented, this would be completely circumvented due to the vault being in memory in plaintext.
May I inquire as to why passwords can't be encrypted on a per password basis rather than just the whole vault itself?
For example;
Say you open 1Password, the passwords are all encrypted in memory, once a user clicks "Copy", it decrypts only that 1 password.This way, sure if you're infected the hacker will see this 1 password in memory, but not your whole vault.
That seems like a much better solution to me but I'd be interested to hear any counter points to this.(I'm not sure on the limitations of C# since I'm not experienced with it. However, from friends that work in the game industry I can say for certain that some games are able to do this to protect themselves from cheat developers, so it's definitely doable.)
0 -
@Drewski: This discussion isn't about what you seem to think it is. I'll merge your comments here (and delete the duplicates) with the existing discussion on the ISE paper.
To address your points:
The bad guys don't usually report their success to the hacked do they? Well at least not until the well has been pumped dry. Sometimes the good guys ride to the rescue. A breach (and more) has been reported in the press of an encrypted 1Password database.
I think hackers would only notify the hacked party for purposes of extortion/ransom, but that certainly happens. I'm sure you're aware of that.
The case study released by Independent Security Evaluators, and a story published in the Washington Post on 2/19/19, make clear that dangers lurk in 1Password and other password managers. Read both the case study and the Blog post (links below) to get a complete picture of the research.
Please see the above discussion.
Technically oriented readers may also be interested in the more detailed explanation, in the link below, including an animation (Gif) demonstrating recovery of a master password from a locked instance in 1Password 4.
Indeed. I definitely recommend reading the research paper and blog post:
https://www.securityevaluators.com/casestudies/password-manager-hacking/
Lars statement above, $100,000 unclaimed "prizes" offered to hackers, and generally overstating the security of 1Password should be viewed skeptically by consumers. To be clear, 1Password is a leader in password managers, but consumers must perform due diligence before handing over their data and money.
Let's be honest: if we didn't have a bug bounty program, you'd be criticizing us for that. I'm glad we have one at least. :lol: While I don't think your characterization of us is fair, I do think it's good to be skeptical and informed. Increasing awareness of security helps us all make better choices, and ultimately benefits everyone since we're all interconnected. I'm glad research like this is being done and shared with the public*; information is a good thing.
*Even if sensationalizing it in the media has a "two steps forward, one step back" effect, potentially scaring people away from using a password manager (at least those who didn't read the report itself, since it still recommends doing so).
0 -
So your average user should have known to ask 'wait, do you mean when it's locked, or when it's shut down?'
It is removed from local storage by the clients.
How does travel mode achieve this but normal operation can't?
Per your team, local memory is so difficult to exploit that it's essentially a non-issue, so why is it a problem if a browser does the same thing?
0 -
Seriously, we've had people write into us saying that because of the article they were going to switch to a browser builtin password manager! That's not exactly moving away from the problem.
This exactly what I am going to do after I read your statements on this issue here. If there is no difference, I do not understand why should I pay 60 USD every year. Browser data is also encrypted and more stable in filling (there is even a companion mobile app in development for the one browser). Yes, this does not solve the memory issue, but saves me 60 USD every year.
What did i expect to see? Action plan, commitments, but not the competitor's comparison or story about .NET restrictions. Nobody forced you to choose .NET as the platform. You decide to do this, and I am sure this one is the business decision, that allows you to develop app cheaper and faster. Maybe it is time now to rewrite some critical parts of your app to secure us? You have a subscription model, so stop protecting your current decisions, this looks the most annoyingly for me.
0 -
Thus, as we've said earlier, that when you're running malicious software on your machine, it can capture your secrets without having to read memory, as you yourself access them. No matter what, data has to be decrypted in memory in order for it to be usable by you. So in a scenario where you have malicious software running on you machine, even once the data has been removed from memory, there was nothing stopping it from capturing it from memory earlier, while you were using it, or doing something much less complex and sophisticated like logging your keystrokes, taking screenshots, monitoring the clipboard, etc.
But malicious software, while a very important thing to combat, is not the only problem here. As things are now, there are poorly installed (using hombebrew) 1Password instances in some computers. Also at our office. These installations do not come with the SIP protections that macOS offers, but rather are running in regular user space and you can attach a debugger and dump their memory.
Due to this fault, I can currently walk to an unlocked mac at our office with 1Password locked, and within 30 seconds, dump all the passwords to a file and copy them to the Internet. Without installing anything, and without privileged access. And exploits enabling memory dumps happen quite often, this homebrew thing just being one of them. I'm sure there's other ways to trick 1Password to run without Hardened Runtime enabled. And if I'm not entirely mistaken, this is the state of things on Windows and 1Password, unless you turn on 1Password running in privileged mode which then disables browser integrations.
At the very minimum, I would expect 1Password being locked to mean that the means for unlocking the vault cannot be accessed without privileged access. Currently the means exist in user accessible memory.
0
![[Deleted User]](https://w8.vanillicon.com/v2/87d6bf4bcda1274e7d83320d05f0c74a.svg)
