Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
Do you want a medal?
@arabbit: No, just respectful discourse. If you are unable or unwilling to contribute in that regard, you can go somewhere else.
Forum guidelines
You've made some good points, but that doesn't entitle you to behave however you wish. Please keep that in mind before commenting further. Thanks.
0 -
I think you guys are making this a lot harder than it needs to be. Look at what keeper does:
https://keepersecurity.com/blog/2019/02/20/ise-research-study-response/
When Keeper users click on “Logout” from their Keeper Desktop application, we perform an app reboot to ensure that the processes which contained data in memory are completely cleared. This includes the Master Password, 2FA tokens, stored vault data and any encryption keys required to decrypt user data.
For the sake of your business, ship this next week. This will buy you time to implement Rust and LML properly.
As stated before in this thread, this will not really solve the problem - even after the process has died, dirty memory pages hang around (and thus will be readable) until the OS sees memory shortage and re-allocates them to other processes. Shipping this will lead to a false sense of security for users.
0 -
Your post shows a clear lack of knowledge for how application security works.
@derek328: Similarly, it isn't incumbent on anyone participating in this discussion to prove their worthiness to you personally. While we've dug you out of spam purgatory at this point, if you continue to be rude and troll by demanding answers and then ignoring them, and making threats and innuendos, you won't be in the future:
Forum guidelines
You've also contributed some good questions and suggestions, but that doesn't give you the right to insult and dismiss others. Please keep that in mind in the future. I think we'd all much rather read the more thoughtful things you've had to say. Thank you.
0 -
As stated before in this thread, this will not really solve the problem - even after the process has died, dirty memory pages hang around (and thus will be readable) until the OS sees memory shortage and re-allocates them to other processes. Shipping this will lead to a false sense of security for users.
@oneagilebits: I think we're in agreement on that. While it is certainly better to prevent local attacks on memory wherever possible, the real issue here is one of the perception created by the locking mechanism. I'm sorry that we've let you and others down in that regard.
0 -
@brenty Apology accepted. Medium-term I think you need to redesign the 1Password clients. Separate them in two parts: One for the UI and one core part. The two will have different threat models, making it easier to mitigate risks in the core, while allowing for fast innovation in the UI part. Short-term you should think what user configurable options make the current 1Password implementation more secure, think of it as a "Paranoid Mode". This would e.g. disable all operations and features known to mass decrypt passwords (WatchTower, search etc.). Implementing this should be rather trivial, given you surely have an abstract model of the data-flows of decrypted passwords etc. in your own code base. :)
0 -
@oneagilebits: Likewise, thanks for the dialog! While I agree that may help, re-designing the app is not something that is quick or easy, even relatively speaking. I'm not certain that's the best solution, but it's certainly one worth pursuing. In the mean time, I do agree with the researchers and their recommendations to end users. Quitting the app can help, and restarting the device releases memory, if you're in an environment where a local attack is a real possibility. I know that's not ideal, but a little inconvenience is a good tradeoff for protection from that sort of threat I think.
0 -
@Charlie_s your suggestion won't help. Memory does not become scrubbed just because you close an application.
Sure, closing the app would mean LML but it would not solve the underlying problem.
I think you guys are making this a lot harder than it needs to be. Look at what keeper does:
For the sake of your business, ship this next week. This will buy you time to implement Rust and LML properly.
See above
Support @ Charlie_s suggestion here, please look at what Keeper has done @ jpgoldberg.
Keeper has a history of security vulnerabilities.
If you talk about Keeper being vulnerable, they'll sue you.
Using emotive language like "For the sake of your business" doesn't help the discussion. 1Password has been proven multiple times to be one of the most secure password managers around.
KeePass receives bug bounty funding from the EU and they were still affected by this vulnerability.
In fact KeePass laughed it off as "old news". Those people who argue that the whole database isn't exposed to memory are correct but the developer of KeePass accepts that if this vulnerability is exploited the attacker will still trivially capture the whole database anyway.
The problem needs careful time and thought. No other password manager is immune - any who say they are are practising security theater.
As users we're not experts. We work in different industries (perhaps even information security) but it is naive for any of us to think we know better and then to wring our hands saying what a bad job 1Password are doing and how we know better. We don't. Not a single detailed solution has been advanced by anybody commenting (who isn't staff).
So whilst I read the comments with interest, and they're useful input for the debate, we're not in a position to say we know better.
0 -
Guys, I know a solution!
Restart the app and launch a bunch of Chrome tabs! Chrome is such a memory hog it will for sure eat up all the free ram! lol
0 -
So -- after reading this entire thread, the bottom line is this: the folks at agilebits don't expect their software to defend your passwords on a "compromised computer." This means my passwords are ONLY protected while the data is at rest and the application is not running -- similar to keeping my passwords in a spreadsheet which is locally encrypted with something like PGP.
Yes, I see the entire discussion above, but I also know folks who work in fintech and have similar problems which have been solved in some way. Yes, I know security must be multilayered, a complete system rather than a single thing (after all, I have and still do design and deploy secure networks).
But the point is that each layer of security should be as hardened as possible. Agilebits says "if your computer is compromised, all bets are off, so don't let someone compromise your computer." Then the operating system maker says "if your network is compromised, the OS can't defend you, so don't let your network become compromised" (and yes, I've heard this in the past). Then the network admin says "if your firewall is compromised, all bets are all, so don't let your firewall be compromised." Then the firewall maker says...
None of this is acceptable. If I didn't worry about my computer being compromised, I'd just store my passwords in a spreadsheet. Once I run the application, all the security devolves to the security of my system sign-in, and nothing more. There seems to be little point in a password manager, other than security theater, at this level of protection.
Again -- none of this is acceptable. Agilebits needs to either fix this, or hire someone who can fix this.
0 -
This means my passwords are ONLY protected while the data is at rest and the application is not running -- similar to keeping my passwords in a spreadsheet which is locally encrypted with something like PGP.
Correct.
No application can protect your data when it's unencrypted.
To use an example from the financial technology sector: this is when credit card data gets leaked into memory or stolen.
Hackers aren't stupid. They won't try and break the unbreakable AES-256. They'll wait around until the data is decrypted and then pounce.
But the point is that each layer of security should be as hardened as possible.
Then the only option is to revert to pen and paper.
The only way a criminal could steal your passwords would be to steal your notebook or use malware to secretly record each password as it's inputted.
Technologically you're asking for the impossible. 1Password hardens your data at rest and in transit but when you come to use the data it has to exist somewhere.
None of this is acceptable. If I didn't worry about my computer being compromised, I'd just store my passwords in a spreadsheet.
A PGP encrypted spreadsheet of the data would be just as secure.
But you'd lose the convenience of automatic input, easy use between different platforms and devices, warning when an account or password has been compromised, the ability to share passwords etc.
Again -- none of this is acceptable. Agilebits needs to either fix this, or hire someone who can fix this.
If it's not acceptable to your risk model, stop using the software and revert to pen and paper - the Russians did for their most valuable secrets.
Any person who can fix this would become a multi-billionaire overnight because you're asking for something not possible with technology today.
A password manager is a convenience feature which keeps your data reasonably secure. It's better than using the same password on every website but it's not a magic cloak that'll protect you when your computer is compromised.
The researchers outlined what users need to do to keep secure - that's all you can do...
or revert to pen and paper.
0 -
I find it deeply worrying how concerned users are being shut up here and pointed to the forum guidelines, threatened to be removed, just because they become a bit uncomfortable to deal with from an AgileBits perspective. What is also worrying is how you guys deal with these individuals. Moderational comments should not be visible in public but be sent to "offenders" in private as to not publicly shame them. First rule of forum moderation.
0 -
But the point is that each layer of security should be as hardened as possible. Agilebits says "if your computer is compromised, all bets are off, so don't let someone compromise your computer." Then the operating system maker says "if your network is compromised, the OS can't defend you, so don't let your network become compromised" (and yes, I've heard this in the past). Then the network admin says "if your firewall is compromised, all bets are all, so don't let your firewall be compromised." Then the firewall maker says...
Full ack. This is not how security works. Still @jpgoldberg and @MikeT have been trying to tell us "once your machine is compromised you're f*cked anyway" and "1Password would be crippled beyond recognition if it were more secure" here again and again.
Again -- none of this is acceptable. Agilebits needs to either fix this, or hire someone who can fix this.
It seems the team responsible for 1Password 3 (where it all really started) has long left the building. Altough feature-laden in comparison 1Password 7 seems a cheaper copy security design wise.
0 -
@oneagilebits - every company has turnover, but for a tech outfit, we're pretty unusual in that regard. The two people who wrote the initial code of version one (and subsequent versions), our founders Dave and Roustem, still work beside us here every day, and jpgoldberg was part of the 1Password 3 for Mac effort as well. So let's skip that canard, OK? :)
0 -
@oneagilebits: Certainly you can take a true statement about how all bets are off once a malicious entity has a foothold in your system out of a greater context, and change our words regarding the tradeoffs involved in building features people use (which also help them be more secure, by the way), but you're missing the bigger picture. Some people will agree with you because they're angry/frustrated/etc. (and rightly so, to some extent), and others will dismiss the things that are valid in your comments as a result of the hyperbole. I don't think that really actually benefits anyone ultimately. :(
0 -
@cryptochrome - users aren't being shut up, unless you consider being asked to stick to substance and the forum guidelines you each agreed to by creating an account here in your opinion to be equivalent to "shutting people up." The internet is full of forums, a large number of them technology-focused, where people can opine at any length with like-minded people in a venue not controlled by us. Even at most of those, there are terms of service that must be agreed-to when creating an account. Those terms may be different than ours, but that may be because those forums have different goals and audiences. This particular forum is maintained and staffed by us to answer user questions about and assist users with difficulties regarding 1Password. It's not anyone's personal soapbox nor are we (or any of you, for that matter) required to answer or reply to everything posted regardless of its content or tone. From the Forum Rules & Reminders:
The long and short of it is: be kind. Be respectful of other customers and of the AgileBits Team Members that are here to help you.
Questions, comments, opinions about 1Password; even vigorous disagreements are fine -- even welcomed. We wouldn't run this forum if we didn't want that kind of engagement with our users. Badgering, insulting, threatening or abusing other users or staff, are not welcome and never have been, and bad-faith arguments (or arguments that assume bad faith on our part) don't tend to get much traction, either. Hope this helps clarify things, but feel free to ask any questions. :)
0 -
@Lars it is funny how you quote your own forum guidelines and pick the part where it says "be kind and respectful", because when I look at some of the responses, particularly from Brenty, I get the feeling these guidelines only apply to your users but not yourselves.
Point is, if you have beef with a user because he violated your forum guidelines, the least you could do is take this beef to private messaging and deal with the offender there instead of publicly discrediting and patronizing them.
You own this house, I get that. But a more levelheaded approach in dealing with such people would instigate less drama and look more professional.
There is at least one person on your staff that doesn't exactly choose his words very wisely. In a heated debate such as this, you really don't want to turn on your users and vise versa.
0 -
@tesmi and @brenty Thank you both for your responses on the MacOS question. One last (promise) followup: my original question applied to BOTH MacOS and iOS and the presence of the discussed issues for those versions of 1Password. I feel like I get the MacOS answer, but can anyone respond with respect to the iOS version? Thanks!
0 -
As stated before in this thread, this will not really solve the problem - even after the process has died, dirty memory pages hang around (and thus will be readable) until the OS sees memory shortage and re-allocates them to other processes. Shipping this will lead to a false sense of security for users.
I fully understand this isn’t going to completely solve the problem. However this will limit the time that this data is in RAM. Yes it is not guaranteed that it will go away once cleared, but there is an infinitely higher chance it will be cleared than with the current approach 1Password currently takes (which is not to release anything).
This would be a small step forward toward LML (even if it isn’t included in the final implementation).
If I had to pick a theme of this entire conversation and why this problem occurred to begin with, it would be “perfection is the enemy of the good enough”.
They could even make this an optional feature and put a disclaimer about what it does and doesn’t do. I would tick that box every time even with the understanding it doesn’t fully mitigate my risk. They’re at least doing all they can do in the current circumstances. I would much rather have them do something like this as an (imperfect) stop gap to limit risk than have nothing done for months while they convert to Rust and implement the full LML.
0 -
I disagree with the characterization that that would "limit" anything since we don't have direct control. But I do agree that it could help in some limited fashion, even if we couldn't really offer any real assurance of to what extent. No one is arguing it needs to be perfect. But that really doesn't sound "good enough" for most people, at least those in this discussion. It may be worth doing, but let's not oversell it.
0 -
The owner of the project ksperrin says:
Bitwarden clears any sensitive vault data, as well as encryption keys from memory whenever the application enters a locked state. We also use other techniques, such as reloading the process after 10 seconds of inactivity on the lock screen, to make sure any managed memory addresses which have not yet been garbage collected are also purged.
My understanding is they also use C# / .net.
I know I’m a broken record on this but if Bitwarden, keeper, KeePass, and now LastPass (with a recent software update to address this issue) do it...why not?
0 -
https://threatpost.com/1password-dashlane-keepass-and-lastpass/142037/
ISE’s Bednarek argues that data sanitization in the context of memory and clear text passwords is 100 percent possible.
“RoboForm does a good job of managing memory and sanitizing secrets, but had one issue where the master password was left on the stack during some function calls and never cleaned up,” Bednarek said. “They were the first to address this issue as they value having a locked password manager that does not give up secrets.”
He also pointed out while 1Password, Dashlane, KeePass appear to view memory management issues as an acceptable risk, LastPass did rush a patch out after being contacted by the members of the media.
“Fundamentally, the core issue is that the ‘lock button’ can give users a false sense of security and this may result in password managers running in the background which can be mined for secrets,” Bednarek said. “The easiest fix is to change the functionality of the lock button to simply terminate the process, letting the windows kernel zero out any unreferenced pages before re-issuing them to other applications that allocate memory.”
0 -
I know I’m a broken record on this but if Bitwarden, keeper, KeePass, and now LastPass (with a recent software update to address this issue) do it...why not?
Because that technique isn't guaranteed to work @Charlie_s ; it's marketing tosh to silence ignorant customers.
The Windows kernel won't "zero out any unreferenced pages" until the Windows kernel is ready to.
I'd still like to see this implemented however (just so people can be told LML)... and when it fails to protect somebody it can be blamed on the:
- operating system
- hardware
- user
Some of the brightest brains in the world (Google security researchers) have said that such attacks are "here to stay".
Confidentiality is at risk when code of different parties share resources such as a processor core, processor, processor package, memory bus, DRAM, cache, or disk.
In either case, Spectre allows for low-level read access to all of the addressable memory.
This puts arbitrary in-memory data at risk, even data “at rest” that is not currently involved in computations and was previously considered safe from side-channel attacks.
Devastatingly
From our first attempts at modeling recently-disclosed vulnerabilities to our work on software mitigations, it has become painfully obvious to us that we are facing three massive open problems:
Finding µ-architectural side channels requires enumerating and modeling relevant µ-state, a difficult task for processors that are closed source and full of valuable and carefully-guarded intellectual property.
Understanding vulnerabilities requires us to model how programs can manipulate and observe µstate, which also requires us to understand complex µ-state in black-box processors.
Mitigating vulnerabilities is perhaps the most challenging of all, since efficient software mitigations needed for extant hardware seem to be in their infancy, and hardware mitigation for future designs is a completely open design problem.
Concluding that these type of attacks (such as Spectre, Meltdown and memory problems) will be here for years to come
And complexity makes these three open problems all that much harder. Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time.
So, there's little you can do in software to protect your memory because hardware mitigation isn't currently possible meaning mitigation through software alone is nothing more than security theater.
0 -
@gazu You argued repeatedly that restarting the process won’t clear the memory immediately 100% of time. We get it. We are not asking 1password to have a “perfect” solution to solve the side-channel attack scenarios once and for all. What I want 1password to do is
- Acknowledge that this issue is a real serious issue that can lead to easy password stealing, and at least partly due to their design and implementation.
- Apply “good enough” mitigation (might not be the full or perfect fix) so that any non-privileged apps cannot read master password and ALL secrets even long periods after 1password is locked.
Is that clear enough?
Restarting app might not clear the memory immediately, but it releases the memory so Windows CAN recycle it anytime, thus reducing the attack vector significantly. This is what I called “good enough” mitigation that puts defence boundaries forward.
Another mitigation is probably have an option to only decrypt an item only while interacting. Or have separate vault that store different levels of secrets which would only be decrypted when opened. This even minimise the risk of local attack stealing ALL secrets at once when 1password is unlocked. For example, I can do banking in a mostly isolated environment where I only install Chrome and whitelist the banking site, and do normal gaming and browsing using another machine. If the normal machine is somehow infected, I would hope that the banking secrets that I never viewed will not be decrypted and stolen. I understand a lot of convenience features rely on that full decryption of secrets, but I believe some security-contious people would rather disable and opt-out those features than having each and every secrets exposed in the memory.
0 -
Until this issue is mitigated, I am not going to use 1Password on any windows machine (I ‘m lucky because I used mac and iphone most of time, but I do have several windows machines at home)
One question I want to clarify is whether 1Password X is affected by this. I am inclined to think it is not due to the sandbox design in Chrome, but I am not sure. Anyone from 1Password can answer this? Thanks.
0 -
Acknowledge that this issue is a real serious issue that can lead to easy password stealing, and at least partly due to their design and implementation
There's not much 1Password could have done. Rust isn't a solution as Google researchers have pointed out when discussing so-called 'secure' languages.
The design of 1Password was intentional as was its implementation. Changing this won't make much of a positive difference to security; it may even degrade security.
The weakest link breaks the chain applies and the weakest link is hardware. There's no such thing as secure software when you're running it on insecure consumer-grade hardware.
Apply “good enough” mitigation (might not be the full or perfect fix) so that any non-privileged apps cannot read master password and ALL secrets even long periods after 1password is locked.
The problem you have is defining "good enough" - the current state of hardware and software doesn't allow an even mediocre (let alone "good enough") level of memory scrubbing.
Closing 1Password is the only solution and I did this well before this report was published.
The other solution is for the lock button to cause 1Password to exit and restart (LML) but even this isn't "good enough" to protect you in the scenario you hypothesise about.
Restarting app might not clear the memory immediately, but it releases the memory so Windows CAN recycle it anytime, thus reducing the attack vector significantly.
No it doesn't. See below.
Another mitigation is probably have an option to only decrypt an item only while interacting. Or have separate vault that store different levels of secrets which would only be decrypted when opened. This even minimise the risk of local attack stealing ALL secrets at once when 1password is unlocked.
As Emmanuel Schalit said
"any attacker sufficiently sophisticated enough to remotely take control of the user’s device would go around these solutions very easily"
If an attacker has bypassed your:
- Browser sandbox
- Software Firewall
- Internet Security (Anti-Virus / Anti-Malware)
- Integrated operating system protections (ASLR etc.)
then it's time to kiss goodbye to your data.
1Password is not a total security solution, it's a password manager. It's imperative that users also practice good security hygiene.
I understand a lot of convenience features rely on that full decryption of secrets, but I believe some security-contious people would rather disable and opt-out those features than having each and every secrets exposed in the memory.
Your best option is to compartmentalise your credentials.
Use two password managers - one for your more sensitive logins, another for your less sensitive ones.
Until this issue is mitigated, I am not going to use 1Password on any windows machine (I ‘m lucky because I used mac and iphone most of time, but I do have several windows machines at home)
Macs are still affected, they obey the laws of physics (how memory retains data) much like a Windows PC does.
The default Mac protection is slightly better than Windows but it still doesn't protect you from the attack outlined in the research paper.
iOS is similarly affected, the problem actually being more acute because other apps can view the clipboard or siphon off data (even though this breaches the App Store T&Cs app-makers still do it). Apple do work hard to remove the malicious apps that slip through the net.
One question I want to clarify is whether 1Password X is affected by this. I am inclined to think it is not due to the sandbox design in Chrome, but I am not sure.
Yes it is affected.
If malware can get past both your browser and system defences to extract the contents of your memory then it can certainly view the content of an browser plugin (which is far easier).
The most secure method of accessing your vault is via the desktop app. That's not to say 1Password X is insecure, but the unpredictable nature of the browsers (and the constant updates) increase the numbers of vulnerabilities and exploits.
0 -
We're begging you to take concrete, actionable steps to provide a basic necessity (secure memory management on Windows), and that you remove any misguiding / false marketing promises your software cannot deliver on Windows at the moment. That's all.
Like what @alexyang & so many of us have said, we're not asking for only 100% perfect solutions because none exists. Security products like 1Password need to own the corporate responsibility - to make sure all available tools & best practices at your disposal are deployed, because you're asking people to entrust their lives to you.Thank you, great boil down.
0 -
After reading the full 10 pages of this thread, I have to admit some recurring posts are quite repetitive and contribute so little to the discussion relative to the volume of text that I just started to gloss over them. Props to the Agilebits members for almost always on point responses, and mostly restrained sentiments. Many sentimental posts regarding security policies and philosophies misses their agreement with the team and fail to recognize that ultimately the resources for development is limited and the Agilebits team has repeatedly expressed their willingness to continue work on solving this problem but only from a position of honest caution that they refuse to make any promises about what they are uncertain with. I for one confidently awaits the version that fixes the problem, and don't want to see their time wasted too much by pointless posts.
The key technical problem here is that 1Password for Windows, written in C#, doesn't manage the memory directly but through a garbage collector, and therefore sensitive data cannot be scrubbed. My question as a student in programming though, is that C# does have escape hatches from the garbage collector. There is
GC.Collect()that forces a collection,System.Memory<T>which allows memory access (rather) directly, as well asunsafekeyword. Could the team share some insights on whether those help in this situation and why?0 -
Troy Hunt on the situation...
https://youtu.be/cDHe5d93fUw?t=331I just want to add to what he said. Troy recommends if you're that concern just go get a password book but if your computer is infected that would not help either. At one point you'll have to enter a password which means a keylogger would get it.
0
