Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
@brenty I've gone through the discussion above, as well as 1Password's response to the WP article. However, like some commenters have discussed, I also feel the reasons given right now are not including enough detail.
As a starter, take the secret key as an example. Is there a reason why this needs to be kept in memory (hence increasing exposure), even though it is only ever needed during initial device authentication / recovery? in fact, shouldn't this be authenticated with 1Password's cloud servers directly only? that's one of the biggest benefits behind shifting to a cloud model, right?
Another example, is there a legit reason why 1Password 7.x needs to decrypt + place all password entries into memory, instead of only performing this action on the entry that's been selected on-screen? I understand the use case to cache everything, but surely this usability improvement should not have been justified if your current technical stack means it'd open up such a serious attack vector?
We're not demanding 1Password to remain bulletproof in a seriously compromised system, but fact of the matter is, most computers are vulnerable to at least some form of malware / virus attack at any point in time, and there are basic safety practices that 1Password seem to have omitted without providing us with enough justifications. Any changes incoming?
0 -
and besides that, it is absolutely feasible to scrub memory.
@DMeans that is absolutely correct. I'm also a PM from the tech & financial sector, and I can absolutely assure you this is not just feasible, but abso-freaking-lutely necessary.
the fact that 1Password continues to carry a dismissive attitude (aka if your machine is compromised it's your problem) is a more serious red-flag to me than this vulnerability.
0 -
Once a malware have access to the system memory, there's not much that can be done. Memory scrubbing wouldn't help if the malware runs all the time and capture the data
Thanks for your post, but that's categorically a straw man argument. This is like saying we chose not to install seat belts, because installing seat belts is not going to help if you crash your car in so & so ways. As a starter, take the secret key as an example. Is there a reason why this needs to be kept in memory (hence increasing exposure), even though it is only ever needed during initial device authentication / recovery? in fact, shouldn't this be authenticated with 1Password's cloud servers directly only? that's one of the biggest benefits behind shifting to a cloud model, right?
Another example, is there a legit reason why 1Password 7.x needs to decrypt + place all password entries into memory, instead of only performing this action on the entry that's been selected on-screen? I understand the use case to cache everything, but surely this usability improvement should not have been justified if your current technical stack means it'd open up such a serious attack vector?
We're not demanding 1Password to remain bulletproof in a seriously compromised system, but fact of the matter is, most computers are vulnerable to at least some form of malware / virus attack at any point in time, and there are basic safety practices that 1Password seem to have omitted without providing us with enough justifications.
Another user here, @DMeans, also makes it clear the need for proper memory scrubbing & other practices (which your team at 1Password is refusing as unnecessary)
I've been practicing information security for over 25 years, in implementation, software development, and as a Security Architect. These days, I'm doing AppSec in the Financial Technology sector.
In the FinTech world, it is a regulatory requirement to scrub and clean memory after secrets are accessed and used (read passwords and keys). Not only do FinTech applications routinely comply and conform to that requirement (at least, mine do), we are tested and certified by qualified 3rd parties. Not only do we scrub memory in Windows, Linux and Unix, we even have Delphi and Mobile apps that do it.
Applications that do not comply with that standard, are routinely hacked (which is why your credit/debit card numbers are for sale on the Darkweb).
I'm also a PM from the tech & financial sectors, and I can categorically agree what he said is very true. You guys may be able to satisfy laymen users, but as a professional, 1Password's dismissive attitude & poor technical justification are really VERY bad red-flags in my opinion.
0 -
@derek328: Please stop spamming multiple threads with the same thing, and actually take the time to read the discussion before commenting further:
https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044
https://discussions.agilebits.com/discussion/comment/493079/#Comment_493079Thanks!
0 -
@brenty I've already done so, but would like to have a proper response to the concerns I raised instead of merely being asked to stop repeating myself.
@MikeT thank you very much for your help. I appreciate it.
In addition to my post above, I see from an earlier post by svondutch (a 1Password alum) that:
- We do not keep your master password in memory. Your master password is available to us when you type it into the unlock window. Immediately after we have used it to unlock your vault, we zero it out.
- Your encryption keys are in memory for the shortest life span possible. When you lock your vault, we then zero them out. Because 1Password is designed to automatically lock itself, your encryption keys should never be in memory for any longer than a few minutes.
Surely this is ironic, considering the security firm is now able to use a memory dump to extract both our master key & secret key?
0 -
@brenty actually I did not specify a specific threat in my inquiries, but rather why 1Password chose to build its product in such an easily compromised fashion (memory dump extracting our encrypted data, master key, and secret key).
As a starter, take the secret key as an example. Is there a reason why this needs to be kept in memory (hence increasing exposure), even though it is only ever needed during initial device authentication / recovery?
Is there a legitimate reason why 1Password 7.x needs to decrypt + place all password entries into memory, instead of only performing this action on the entry that's been selected on-screen? surely this usability improvement should not have been justified if your current technical stack means it'd open up such a serious attack vector?
Can you further elaborate, in greater technical detail, why memory scrubbing is not, I quote, feasible for implementation in 1Password, even though it is a routine requirement in the financial industry?
Can you further explain why your team would state in the public forums that "We do not keep your master password in memory", and yet today's research paper clearly shows the ability to use a memory dump to extract our master key, secret key, and saved password entries? was this security design deliberately removed, and was additional communication made to the public of this change?
a proper technical explanation to these inquiries would be deeply appreciated. thank you.
0 -
@derek328 and @DMeans asks some really good questions and make some extremely good points
Is there a reason why the Secret Key needs to be kept in memory (hence increasing exposure), even though it is only ever needed during initial device authentication / recovery?
No. There is no need for this. 1Password does not need it beyond initially unlocking. The same is true of the Master Password. 1Password does not need it once 1Password is unlocked. The difficulty that I tried to describe is that we have no reliable way to actually clear this data from memory after we no longer need it.
Another example, is there a legit reason why 1Password 7.x needs to decrypt + place all password entries into memory, instead of only performing this action on the entry that's been selected on-screen?
This has been story of back and forth over the years. In the old days, 1Password worked as you wish, decrypting items just when needed. This was because decryption was expensive and memory was limited. But this meant that searching items was limited. And in the days of Agile Keychain Format it meant that URL and Title information wasn't encrypted at all. Later we developed the OPVault format, which encrypted that information that we needed for listing and lookup but did so with a different key (the overview key). That way, we could decrypt the information needed for listing, searching, and sorting without having to decrypt everything.
But we left it to platform developers to decide whether they wanted to decrypt everything (overview and details) at unlock at one or just the overview data at unlock. This is because the memory and processing power differs from device to device. So I am going to have to ask people from our Windows development team to address specifically the choice that they made. @MikeT, @SergeyTheAgile, can you help out here?
The fact that 1Password continues to carry a dismissive attitude (aka if your machine is compromised it's your problem) is a more serious red-flag to me than this vulnerability.
I'm sorry that you consider this dismissive, but to what extent do you think we should (or can) protect the user when they use 1Password on a compromised machine? This is a sincere question.
We are certainly willing to learn from the memory scrubbing techniques used in the financial technology industry. If there are viable techniques that don't introduce other problems we will definitely consider them. I have not seen those specifically detailed at BSides or DEFCON, but I'm not a Windows developer and so haven't specifically looked for them. But if they all start with "don't use garbage collecting languages" then I hope you will understand why progress on such things is going to be slow.
0 -
Please see the discussion above. It isn't feasible to "scrub memory", and an attacker who has access to memory could get the data anyway as you access it by virtue of having a foothold in your system.
And besides that, it is absolutely feasible to scrub memory.
@DMeans: I think you're taking my comment to someone else out of context, but I apologize if you did not have the full context yourself. please see the following comments for that:
https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044
https://discussions.agilebits.com/discussion/comment/493079/#Comment_493079Thanks!
0 -
And a follow up answer to @derek328 and @DMeans.
As I mentioned before, the Windows team has started to do some work with Rust. This would give us the ability to scrub memory when we need to as well as giving us strong memory and type safety.
What I can't do is promise at this point that that is what our solution will look like or when it may arrive. But there are (small) parts of 1Password for Windows today that are written in Rust.
0 -
actually I did not specify a specific threat in my inquiries, but rather why 1Password chose to build its product in such an easily compromised fashion (memory dump extracting our encrypted data, master key, and secret key).
@derek328: Thank you for clarifying. That was my understanding from reading your comments, but I wanted to be sure I hadn't misunderstood you. I was a bit confused because @jpgoldberg addressed this directly in his earlier comments, which I directed you to above. If you have questions about that, I'm sure that he'll be happy to address them.
0 -
@jpgoldberg sincerely many thanks for your thoughtful response - would love to follow up on your answers, if you don't mind.
No. There is no need for this. 1Password does not need it beyond initially unlocking. The same is true of the Master Password. 1Password does not need it once 1Password is unlocked. The difficulty that I tried to describe is that we have no reliable way to actually clear this data from memory after we no longer need it.
proper memory scrubbing (and in combination with other techniques) like those @DMeans mentioned are absolutely possible, and are quite common in the financial industry. if your team has been struggling to clear memory in Windows / macOS / Linux / mobile environments, you guys need to hire a few security architects & devs from the financial sector (most likely from major banks like JPM / HSBC etc) to refine your stack, because this is a highly critical design flaw. As for the chances of this occurring, it is actually irrelevant to the conversation because while we don't expect 1Password to remain bulletproof in a completely compromised system, most end-points today are vulnerable to a degree of malware / virus attack at any point in time, so the point is kinda moot in itself.
But we left it to platform developers to decide whether they wanted to decrypt everything (overview and details) at unlock at one or just the overview data at unlock.
To limit potential attack vectors, only 1 entry should ever only be entered into memory. We all live and learn I suppose?
to what extent do you think we should (or can) protect the user when they use 1Password on a compromised machine? This is a sincere question.
It's not in my place to coach your team what to say. However, I'd hope 1Password can at least adhere to its own public statements, such as this one which states "We do not keep your master password in memory" for starters. second, the secret key (once generated) really should not exist in memory for any reason whatsoever; the fact that the security paper showed a memory dump that can extract our security key is incredibly worrying to me.
as discussed above, because most end-points are going to be vulnerable to a degree of malware / virus attack at any given point in time, 1Password's role as a data custodian will need to evolve as well. in banking, we're often assuming the user's device may already have a few viruses onboard, so the question becomes what can we do to ensure even such a compromised machine would not necessarily expose the user's lifelong savings to hackers. with 1Password 7's cloud model, you have a unique opportunity here - use it to your advantage and rebuild your authentication model.
0 -
It's not in my place to coach your team what to say. However, I'd hope 1Password can at least adhere to its own public statements, such as this one which states "We do not keep your master password in memory" for starters. second, the secret key (once generated) really should not exist in memory for any reason whatsoever - use 1Password 7's cloud model to your advantage and rebuild your authentication model.
@derek328: Stefan wrote that regarding the version of 1Password that existed at the time. I don't think we can reasonably expect him to know about future versions of 1Password or the tools in use in 2019 to develop it back in 2015. But I do apologize for any confusion stemming from that.
0 -
The fact that the security paper showed a memory dump that can extract our security key is incredibly worrying to me.
You do know that the Secret Key is not designed to be kept secret from anyone with read access to the user's disk? We assume that any local attacker with fairly minimal local powers can get the Secret Key.
This is why I keep focusing on the Master Password and other secrets in memory, as that better illustrates the threat (and your points) than the Secret Key.
0 -
@brenty thanks for your response as well. i agree it'd be crazy to expect Stefan to know, back in 2015, what 1Password may look like years down the road.
but on that point, if 1Password was already able to not keep our master password in memory even back in 2015, then what this means is that - at some point since 2015, the 1Password team has internally decided to settle for a downgrade in security, and failed to communicate such a critical change to the public (while leaving incorrect information in public view). i want 1Password to succeed as much as you guys too, but this is a security flaw you guys need to get on top of fast.
0 -
@jpgoldberg I think that's a fair response, but 1Password would most definitely fail compliance requirements if it is evaluated as a financial industry product (which is a little worrying, considering that even some banks with greater security architecture & design than 1Password also get hacked once in a while).
on the other hand, as I've mentioned to @brenty above on our master password, if 1Password was already able to not keep our master password in memory even back in 2015, then what this means is that - at some point since 2015, the 1Password team has internally decided to settle for a downgrade in security, and failed to communicate such a critical change to the public (while leaving incorrect information in public view). this really is a security flaw you guys need to get on top of, and fast.
another thing i'd recommend for 1Password to do, is to commission security audits on a regular basis, completed by a proven third-party like Deloitte, EY etc. this would seriously strengthen your design thinking, and lend greater confidence to your work as well.
0 -
@derek328 , you have been directed several times to a post that details the reasons the master password is now available in memory when it was not available before. The old version of 1Password was coded in an entirely different programming language. For the newer version, they switched to another programming language that gave them many specific benefits from a security standpoint, unfortunately with the trade-off of losing the ability to control when memory addresses get zeroed out. The language and the APIs used simply do not support it and 1Password considers the security gained from them to outweigh this particular issue. It's not strictly a downgrade, it's a trade-off. You're welcome to disagree with the trade-off but it's not like they didn't give it any thought or are as incompetent as you seem to be insinuating.
To the 1Password folks: there is a setting in the Windows app that automatically locks the database after a configurable time. In light of these revelations, is there actually any value in this option? My computer locks automatically after a certain time which will keep people from stepping in and manually revealing my passwords from a running password manager, I wasn't really relying on this feature for such in-person attacks. However I did think this setting would limit the time my passwords are available in case someone gains access to read my memory, possibly by pivoting from somewhere else on my network at work. I often leave my work computer running for a week or more, without explicitly exiting 1Password, assuming the "locked" state is equivalent to the "hasn't ever been unlocked" state. That assumption is apparently incorrect.
KeePass (which also is affected by this story) has an option to exit the app after a timeout, rather than just locking it. I cannot find a similar option in 1Password. That seems like a simple way to decrease the exposure to this attack method. However, I normally use 1Password through the browser extension. Does the browser extension likewise leave decrypted passwords floating around? For the sake of this particular discussion, I'm interested in the "standard" one which talks to the 1Password app, not 1Password X which decrypts the vault within the browser. If I exit 1Password, I understand from the paper that the 1Password memory is safe, but would the browser memory still contain it, or is the password retrieval delegated to the app in some way? Luckily browser memory is probably more quickly re-used once it is deallocated but your talk of immutable memory has me a little concerned. I don't really want to fully exit my browser after entering a password anywhere.
Thank you for the detailed responses in this thread explaining the trade-offs behind the vulnerability, it's a lot better than the dismissive "needs a compromised machine anyway" responses I've seen so far.
0 -
Whew! All this discussion almost makes me move to the 3M system for managing my passwords. ;)
0 -
My two cents. I personally believe these discussions are informative, necessary, and beneficial for the overall health of 1Password and this sector as a whole.
0 -
I personally believe these discussions are informative, necessary, and beneficial for the overall health of 1Password and this sector as a whole.
Of course I agree. Because the alternative is suppression of public scrutiny.
But if you take a look at some of the comments on the Washington Post site, you might weep. There are people recommending truly terrible schemes. And there are people who are going on about how using 2FA to unlock their password manager keeps them safe from this kind of thing.
0 -
But if you take a look at some of the comments on the Washington Post site, you might weep. There are people recommending truly terrible schemes. And there are people who are going on about how using 2FA to unlock their password manager keeps them safe from this kind of thing.
Unfortunately, the WP site requires you buy a subscription to read the article, so I was limited to ZDNet's discussion until I was directed to this thread. My take-away so far is that, as a layman, I seem to have a better understanding of what the Agile folks go through trying to make a usable (but secure) product than do some outside "experts". I commend Aigle on all that they have done over the years for me. I suspect that my first impression of the ZDNet article was correct.
0 -
But if you take a look at some of the comments on the Washington Post site, you might weep.
Yeah, I get it. I was attempting to console poor, distraught @romad above who was ready to go back to pink Sticky Notes!
Having spent my career as a C/kernel developer, I fully get the trade-offs required between fast, efficient programming languages for speed/memory critical code vs. the development convenience provided by frameworks and higher-level languages. All of us old-timers know all too well the great care that is required to manage memory in such an environment, and how easy it is to just miss one. And it only takes one. Anyone who'd consider going back to developing a medium to large GUI app in C needs some help. The downsides are just too great.
0 -
Thank you @MrC!
I get it. I was attempting to console poor, distraught @romad above who was ready to go back to pink Sticky Notes!
And I thank you for that. @nomad (and others) should be reminded that all of this is "part of the process". Sure it isn't fun when something gets blown out of proportion in the press, but that kind of thing is a price we pay for open scrutiny.
All of us old-timers know all too well the great care that is required to manage memory in such an environment, and how easy it is to just miss one. And it only takes one. Anyone who'd consider going back to developing a medium to large GUI app in C needs some help. The downsides are just too great.
Yep. Everything that I used to love about C: the power, the closeness to the machine, the "everything is an expression" and so on are the things that from a security perspective make me hate it. Memory management in it is like juggling chainsaws. We (as a community) have to move away from that approach.
I do think that Rust can give us the best of both worlds. Extreme memory safety and the fine control of the data. And while we are trying it out here and there, I just can't promise that this is something that we will deliver in the long run.
0 -
We got that, and it was just a good gender-inclusive color choice (like using the pronoun she vs. he).
(there's a very old inside joke w/someone at AgileBits/1Password, about fuchsia-colored text).
0 -
It seems the major error in judgement was using a programming language that would not allow them to scrub memory. Full stop.
I would have thought that would have been a primary requirement, from the get go. And it's quite disappointing to know the product I'm relying on has that flaw.
0 -
I think we're at the point now, where we know why (taking into account commercial-in-confidence decisions) we're in the situation that we are currently (change of programming languages in the rewrite between 4 & 7), the inherent trade offs in memory management, and how it "may" be fixed in the future by moving to another (yet again) programming language.
We know that there is little we can do about a compromised machine, but I think we're all missing the point in "What can we do short term to increase our security posture?" There seems to be little appetite on AgileBits part to make any drastic changes (other then potentially moving to Rust), and to be frank if you don't agree with this approach, move to another product.
Why can't there be some type of compromise here and do similar to what LastPass has done in response to this article - https://threatpost.com/1password-dashlane-keepass-and-lastpass/142037/
Could it be as simple as shutting down the application instead of locking it after the timeout period? This would not only clear out the memory of the unencrypted passwords, master & secret keys, but it would also return us to the security "safe" state of not having any data recoverable should a memory dump occur (or other malware hijack ATTEMPT).
Let's look at moving forward in a way which is beneficial to both parties (consumers & developers)
0 -
As a thought experiment: I wonder how much it would complicate things to keep the main "locked" screen where the user has to enter their password on a separate process? Then when the vault is locked the main process could be killed, but that UI could still be shown. My guess is it would be a non-trivial change, as coordinating the window placement and using IPC everywhere sounds painful, but I imagine something like this would be technically possible with the current programming language/garbage collection memory model.
(As an aside: personally I totally agree with the stance and trade-offs made by the AgileBits team here and do not see this is a major issue given the very specific/unlikely threat model. I'd rather have a more stable application that is less prone to memory bugs than one that clears data from memory immediately).
0 -
Does this mean that any application running with in the same user context as 1Password has read access to master and secret keys (once 1Password is unlocked first time) and can get full access to all passwords in a helpful format, together with urls, usernames and 2fa data?
I can understand being vulnerable to an elevated process -- the system is truly compromised at that point. But exposing the whole lot of helpfully decrypted passwords to a non-elevated user context is game over for a lot of otherwise benign cases.
It is relatively easy to run unelevated code on random machines (comparing to additional step of exploiting something and getting elevation). Consider a developer running a package manager (pip, npm, etc) that can download and execute any number of binaries in user context. Compromising one thing in the dependency chain seems sufficient to get dumps of 1password that in turn might give access to more packages and more developers.
Re: cleaning memory when locking, a cheap but transparent fix for that is to exit and relaunch the applicaton when user clicks "Lock".
Please also consider splitting core of the application into a protected service and leaving only UI running in user context:
https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services-
This adds protection for DLL injections and memory reads, if I understand it correctly.0
