Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
For securing master password and removing it from being handled by .Net UI it is possible to use a separate (native if necessary) process to ask user for master password, use a secure way of relaying it to .Net side (encrypted pipe for example) and storing it in SGX or another appropriate construct, unbeholden to .Net GC whims.
0 -
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.
If this is the case, why is the Secret Key touted as such an important factor in the encryption of our data? If we accept for the sake of argument that readable secrets in local memory are an inherent and thus known vulnerability, how is keeping the Secret Key and Master Password in the same relatively easy-to-access place even equivalent to 2FA, let alone better? I lock my front door, but I also keep my really important documents in a safe and I don't tape my password to my monitor. How is 1P more secure than a hidden file on my otherwise locked computer?
One does not expect that when they lock an encrypted vault, it remains decrypted until they close 1P. Since this was evidently such old news that no one saw the need to tell users about this limitation, I cannot for the life of me understand why there's an option to lock 1P after a time-out, but no option to close it or restart it instead. This seems an awful lot to me like security theatre.
I agree wholeheartedly with @envoy510 and the points brought up by @derek328 regarding FI security. 1Pass is not the service I thought I was paying for, and I'm struggling to see how it's more secure or convenient than allowing Chrome and/or Windows to store all my passwords.
0 -
Are we one browser exploit away from having malicious ad banners being able to steal password databases wholesale? Or am I missing something?
0 -
This is such a hard problem to solve that no password manager has successfully done it.
Scrubbing secrets makes no difference - if a malicious actor has access to your computer: you. are. compromised.
The best advice is given by the researchers:
- Keeping the OS updated
- Enabling or utilizing well known and tested anti-virus solutions
- Utilizing features provided by some password managers, such as “Secure Desktop”
- Using hardware wallets for immediately exploitable sensitive data such as crypto currency private keys
- Utilizing the auto lock feature of their OS to prevent ‘walk by’ targeted malicious activity
- Selecting a strong password as the master password to thwart brute force possibilities on a compromised encrypted database file
- Using full disk encryption to prevent the possibility of secrets extraction in the event of crash logs and associated memory dumps which may include decrypted password manager data
- Shutting a password manager down completely when not in use even in a locked state (If using one that doesn’t properly sanitize secrets upon being placed into a locked running state)
I always make sure to shut down 1Password once I'm finished. As the researchers point out:
This renders the “lock” button ineffective; from the security standpoint, after unlocking and using 1Password7, the user must exit the software entirely in order to clear sensitive information from memory as locking should.
@UnFleshedOne if a browser exploit is able to to read the entire contents of your RAM then no password manager can protect you.
There is, however, always room for improvement.
0 -
@gazu there is a difference between accessing a last used password (same risk as keylogger) and accessing whole unencrypted database. A browser is already able to read whole memory (of all processes running in the same user context). If you are running anti malware it might tell you that "chrome is trying to access memory of 1password.exe", but if you don't that's it. An exploit that allows remote actor to jump outside of JS sandbox and inject code into browser process is not inconceivable, given the sheer surface size of a modern browser.
0 -
The points @arabbit and @derek328 bring up are exactly my points as well.
I trust you guys because I was told by your website you take security seriously. "By Design", the fact that my passwords are literally no safer than an excel document on my locked Macbook makes me see now I'm better off with Bitwarden or some other open sourced password manager hosted myself.
Give me one good reason to stay with you guys. You have thrown these valid complaints back in our face through this entire thread. The entire point of a password manager is that it's a black box when the house is burning down.
You decided to not only leave the key in the lock, but actually leave the door wide open from malware to snoop memory while the app is locked.
Because you guys so lazily decided to cache the entire 1password contents in memory, they don't even the password. They in one swoop just get everything.
Your comments about any malware being able to retrieve data while it's decrypting are valid, however, I stand by @arabbit 's comment. Why the hell do you even have a 'lock out' feature on 1password? If everything is just in plain text sitting in memory what's the point of the lock? To deceive us? because that's what it appears to be for. At the VERY least you guys need to scrub memory when we lock the app...
You guys need to actually take this audit seriously because right now, all I see are a bunch of pride bruised dev's who think they know better than everyone else. If that's the attitude of this company then I'll go back to buying American because I have no country pride when it comes to privacy.
0 -
This Wapo article is like anti-vaccination fearmongering for password managers. Literally no password manager has this property of "full memory safety" the researchers wants to somehow see; all makes some compromises so that your password manager isn't playing with fire, as developing in memory unsafe languages tend to be.
Moving from a memory-safe to a memory-unsafe language just to "clear memory" in a clever obfuscated way is like starting a bonfire in your house every time you have sensitive documents to shred. Sure, maybe it shreds documents more completely than putting them in a shred deposit box, to be shredded later. Yes, there is a chance someone can break into the shred deposit box with root privileges. But you could also fail to burn the corner of the paper with the sensitive information. Or burn your house down.
I would much prefer "if someone has root on my system, they can read 1Password's memory and find my passwords" to "oops, 1Password has a memory leak and someone can find my passwords without root", or "oops, 1Password corrupted all my passwords and now all my passwords are gone, because my computer had a memory corruption issue".
The only thing I do agree with from the article is that 1Password should shut itself down more often when it's locked, so the OS can properly clear memory more often.
0 -
Yep, it looks like ZDNet, The Washington Post, and ise have reached their goal of FUD!
0 -
@analogist that's the thing -- no root required. Any running process can read any other process memory in the same user context with no additional permissions. So we are already at your second option, except for all passwords compromised at once.
If 1password was itself running elevated, this would be a much smaller target.
0 -
@UnFleshedOne Is this comment Windows-specific? Don't you need to explicitly grant PROCESS_VM_READ for a root/admin-less memory read by another process owned by the same user? PROCESS_VM_READ is not enabled by default.
0 -
@arabbit The Secret Key is there to protect you from a scenario where an attacker steals all of 1Password.com's stored databases in the cloud. The key lives only on your own devices, so that even if the thief have a lot of password cracking power, they still can't crack the databases they've managed to steal.
And because the key lives on your own devices, it doesn't give extra protection against compromise of your own devices.
0 -
In regards to "Keep in mind that the realistic threat from this issue is limited," and "As I mentioned there are security gains in programming in a way that has the side effect of limiting our ability to clear memory instantly."
My recommendation is that you perform some threat modeling and develop some abuse cases. No one expects that memory can be cleared instantly, but you can get pretty darn close. Close enough that retrieving secrets in real time will be nearly impossible, and certainly impossible from memory dumps and virtual machine save states.
Secondly, the threats are real, they are not some contrived compromised machine that you have asserted is useless to protect.
Perhaps you should consider the Virtual Machine abuse case: "as an attacker, I want to scan the saved state of a virtual machine and extract un-encrypted credentials in order to leverage an attack against other servers and accounts."
This is an exceedingly simple abuse case to prove, which can be demonstrated, as follows:
1) Install gvim into a Windows VM (e.g., VirtualBox).
2) Write some text using gvim, but do not save a file.
3) Save the machine state.
4) Discover the text using 'grep'
5) Discover the text using 010Editor.
0 -
Scrubbing secrets makes no difference - if a malicious actor has access to your computer: you. are. compromised.
Everyone here understands that should someone use a keylogger or similar malware no password security on the affected machine could protect you, so it's frankly insulting for devs to bring this up as if this is truly the concern here. It's a waste of time; no one is angry that a bad actor with root access can read their local memory. The problem here is that this has been brushed off as a known issue inherent to all password managers (a point of which I and others are skeptical) while literally nothing has been done to minimize exposure.
1Password is all about encryption. You can't swing a dead cat around here without slapping some encryption. So it's very surprising and troubling to learn that devs are aware this data sits unencrypted not only in a place where "any local attacker with fairly minimal local powers can get [it]" but where you can unknowingly include it in a debug log, it remains there when you lock the app (defying all reasonable expectation), and they've done less than nothing to get that data out of that place ASAP (such as instructing you to or making you close the app rather than locking). I find it extremely difficult to believe there was no way to create an option to close the app after Y uses or X seconds ('1Password needs to restart to keep your vault safe' and yeah 1P you can pay me if you want to use that); even KeePass can do this, and it didn't cost me $60/yr. Especially because this is an issue supposedly inherent to all managers, it should have been trivial to include this type of option or user education without hurting perception about performance.
If we took this fiction about compromised machines to its logical conclusion, there would be no reason to have a password for 1P. If anyone accessing your computer is a bad actor, they'll have the ability to compromise your system in some high-level way no one can quite give an example of, and in that case any security in 1P would be rendered worthless. Instead, we password-protect our vaults to help keep the honest that way and to slow down the others because we understand security comprises layers and no one layer is perfect. We don't say screw it about all other ways that might mitigate losses just because one layer has failed.
I'm in complete agreement with the recommendations from the researchers, but the 1P team dropped the ball on implementing what they should have in the software. Coincidentally my sub just expired today and I had been planning to re-up before I read some flippant and frankly tone deaf dev responses in this thread.
e: @analogist
The Secret Key is there to protect you from a scenario where an attacker steals all of 1Password.com's stored databases in the cloud. The key lives only on your own devices, so that even if the thief have a lot of password cracking power, they still can't crack the databases they've managed to steal.
Thanks for the explanation. I'm still not understanding how this system is equivalent to 2FA. You still need both to sign in, but doesn't storing the password and key in the same place negate the usefulness of that? It's like writing your PIN on your debit card, except your debit card and pin are both digital.
0 -
@analogist yeah, sorry, should have mentioned that I mean Windows. Requesting PROCESS_VM_READ doesn't seem to require elevation, I'm using HxD launched normally (in a admin user context, with UAC enabled, but without elevation) to open memory of 1 password and I can find my passwords and urls easily...
0 -
@gazu Your last two paragraphs are so true. If 1password is claiming that anyone who has access to your computer is as good as compromised then I see no reason to pay 1password. A word document work or safari password keeper works just as well.
0 -
@UnFleshedOne Got it, I don't do Windows development, so I didn't know what the standard behavior was. Is your UAC level on the highest? If not, and if you don't mind, can you see if the behavior changes if you set your UAC to the highest level?
As far as I'm aware, Linux and MacOS doesn't allow R/W of virtual memory owned by another process without privilege escalation.
0 -
1Password’s developer’s attitude and non-challant attitude toward this situation is alarming. I’ve been using 1Password for many years because of the trust I placed in the product and because of their developer’s stated focus on security. However, if 1Password refuses to take this matter seriously, I will be forced to look elsewhere for a password manager whose developer has a higher sense of urgency with security issues. Many of your competition is taking a more serious stance and taking immediate action on this matter. I look to Agilebites to do the same.
0 -
Besides the arguments, I'd like to know what're the (relatively) best practices to avoid such a situation when using a password manager ? For example, my computer may get compromised (the computer is unlocked but not 1P) because the login pass of my computer is stolen or someone forced me to do so. In such a situation, I would still think 1Pass could provide some protection against just retrieving my master pass or secret from the memory, right?
Any precaution to minimize such a threat? Maybe close or force quit all 1Pass processes when finish using my computer?0 -
It seems the major error in judgement was using a programming language that would not allow them to scrub memory. Full stop.
If this is the case, why is the Secret Key touted as such an important factor in the encryption of our data? If [...] readable secrets in local memory are an inherent and thus known vulnerability, how is keeping the Secret Key and Master Password in the same relatively easy-to-access place even equivalent to 2FA, let alone better?
One does not expect that when they lock an encrypted vault, it remains decrypted until they close 1P.
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 -- 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.
Are we one browser exploit away from having malicious ad banners being able to steal password databases wholesale?
I trust you guys because I was told by your website you take security seriously. "By Design", the fact that my passwords are literally no safer than an excel document on my locked Macbook
No one expects that memory can be cleared instantly, but you can get pretty darn close.
i could not have summed up the issues at hand better than these guys here.
i won't pretend i have insider knowledge about 1Password's inner workings, but from my technical perspective, yes 1Password 7's heavily-advertised secret key & master key protection is not much more resilient to memory dump attacks than a password-protected Excel spreadsheet. in fact, one could argue 1Password 7's crippled cloud protection here can suffer from even more attack vectors than a doc on your desktop... if a simple memory dump can discover our secret key, master key, usernames, and passwords, then this isn't even remotely close to being on par with 2FA protection.
@MikeT @jpgoldberg you guys need to look at some of the advice here and here. good starting points to add some security asap, because i can assure you this design flaw is absolutely critical and, from one professional to another, frankly worrying.
0 -
What would you suggest is a way to strengthen my account against?
Thanks1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Hacker getting into 1Password0 -
I would recommend that you follow the existing thread for much detailed discussion regarding that article:
https://discussions.agilebits.com/discussion/101551/article-just-published-in-washington-post-is-saying-1password-and-others-have-security-flaws0 -
^ Addendum to my post above
@MikeT @jpgoldberg you guys need to look at some of the advice here, here and here. good starting points to add some security asap, because i can assure you this design flaw is absolutely critical and, from one professional to another, frankly worrying.
For example, my computer may get compromised (the computer is unlocked but not 1P) because the login pass of my computer is stolen or someone forced me to do so. In such a situation, I would still think 1Pass could provide some protection against just retrieving my master pass or secret from the memory, right?
Your expectation is 100% reasonable. A properly designed system (especially a password manager that forces people to use the secure cloud account model) should've at the minimum accounted for malicious scenarios where end-points may be compromised.
1Password 7 as it stands right now, in my opinion, really isn't much safer than an encrypted Excel doc on your desktop.
0 -
They can't avoid dumping all the data into memory because it's just an SQLite database file. You can't partially query that kind of database without decrypting the entire thing first. I don't know if there's a database type you can.
The sum of these arguments seem to be: by using the operating system's built-in features, which they're better able to secure than we could do implementing them ourselves, we avoid more problems than we potentially create. After a lot of reading, I mostly agree with that assessment.
The real mistake in judgement is not using more of the operating system's built-in features to enhance security, like SGX on Windows, which was going well but abandoned for some reason. I suspect the reply will be, "If an attacker has full access to everything he can get around SGX." Even if that's true, at the very least, it'll save you face when an exploit does come along that embarrasses you. If you're at least properly using SGX, you can blame it on Intel.
0 -
Beacuse 1Password for windows 7 is a joke:
https://www.securityevaluators.com/casestudies/password-manager-hacking/
1Password7 (Version: 7.2.576)
After assessing the legacy 1Password4, we moved on to 1Password7, the current release. Surprisingly, we found that it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords in our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one entry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords, the master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master password to derive the encryption key) from memory when transitioning from unlocked to locked. This renders the “lock” button ineffective; from the security standpoint, after unlocking and using 1Password7, the user must exit the software entirely in order to clear sensitive information from memory as locking should.
It appears 1Password may have rewritten their software to produce 1Password7 without implementing secure memory management and secrets scrubbing workflows present in 1Password4 and abandoning the distinction between a ‘running unlocked’ and ‘running locked’ state in terms of secrets exposure. Interestingly, this is not the case. Prior marketing material for 1Password claimed [20]to feature Intel SGX technology. This technology protects secrets inside secure memory enclaves so that other processes and even higher privileged components (such as the kernel) cannot access them. Were SGX to be implemented correctly, 1Password7 would have been the most secure password manager in our research by far. Unfortunately, SGX was only supported as a beta feature in 1Password6 and early versions of 1Password7, and was dropped for later versions. This was only evident from gathering the details about it on a 1Password support forum [21]. -- ISE, 2019
How you can advise people to move to such a insecure version?
Please lets just update v4 for windows to work with chrome- I'm sure you can do it.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided0 -
@dillera: I've merged your post with the existing discussion, and made it clear that the majority of what you posted was a direct quote from the article, with proper attribution. Please see Mike and Goldberg's comments above for the details:
https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044
https://discussions.agilebits.com/discussion/comment/493079/#Comment_493079And let us know if you have any questions about that.
0 -
While true by itself, the argument that it's game over anyway if you have local malware is not a valid excuse to not scrub memory. There's a number of attack vectors beyond what local malware can do that might still attempt to read memory from other processes, like vulnerabilities in browsers that can be exploited by malicious ads, which keep coming up all the time.
Password managers cannot just rely on the rest of the system not being compromised as their only line of defense. They have to employ every security measure possible to make attacks harder, and 1Password is failing here.
While using memory-safe languages indeed prevents entire security-related bug classes, I can't accept that explanation as a tradeoff for not scrubbing memory. I also reject the concept of trading security for performance, at least in this type of application that's entirely about security and encryption in the first place. I didn't find any information about what languages are used for the macOS and iOS versions (which would be the ones I care about), and I'm not an expert on compiled languages for those platforms, but if those languages have only immutable strings, there still has to be a way to encapsulate the handling of passwords in a C or C++ module that can implement scrubbing? Or I'd love to hear some explanation why that critical piece of the application has to be implemented in the same language as the rest and the UI.
I don't think that terminating the process dealing with passwords more often would make a big difference, because that wouldn't cause it's memory to be cleared of residual data right away, would it? Depending on system load, cleartext passwords and keys could still stay in memory for a long time, and also the next application that gets that chunk of memory assigned to it could scan it for keys and passwords left behind by 1Password. (Or does the OS prevent that nowadays?)
0 -
The biggest issue I fear is NOT the case of an intentional hack, it's the case of every software manufacturer and their overlords embedding system 'telemetry' that sends memory dumps anytime they generate an error, and at times in clear text across multiple hops (and to their tech partners for outsourced debugging, and to their partners, etc..). They heavily coerce their users to allow this and do it by default in many systems.
System failures, broken software, uncontrollable and unexpected forced updates (looking at you Microsoft, Nvidia, and Adobe), antivirus companies, mouse drivers, all do this. That's just potential leakage from legit and trusted (I use the term loosely) companies that might store this 'anonymous' data in a remote revisioning system for devs to gradually pick through. A truly nefarious actor might do far worse, and could infiltrate plugins and apps to 'error' out and attempt to log the seemingly innocent data, without triggering any virus or intrusion detection.
It sounds like if a typical user leaves 1Password 7 running overnight and an app crashes hard or an update fails, their entire password database should be considered compromised. More savvy users are likely to have things firewalled, telemetry blocked, etc.. but the typical non-technical 'every person' that uses 1Password7 could get hosed and never know it.
Maybe I'm viewing this all wrong, but on this end, it sounds like a major problem.
0 -
I did some investigation on this on macOS. It seems that the ability to dump the memory of a running process depends on how the 1Password is installed.
If I install 1Password using
brew cask install 1PasswordThis uses code from here: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/1password.rb
It will not be installed as an "Enhanced Runtime" or with "Runtime Hardening". If I start up 1Password and check its PID and do lldb -p I can happily dump the memory and get all the passwords even from a locked vault, as the password will be in clear text in memory for quite some time after locking the vault.
If, however, I install 1Password from the packaged installer from the 1Password website, it will have the runtime hardening enabled and attaching a debugger will result in
macOSTaskPolicy: (com.apple.debugserver) may not get the taskport of (1Password 7) (pid: 99515): (1Password 7) is hardened, (1Password 7) doesn't have get-task-allow,
and some other messages in the kernel log. This will happen also as root, and dumping the memory in 1Password is at the very minimum, more difficult.So there's an installation method for 1Password that is quite commonly used and horribly insecure by default - you can literally write a bash oneliner with lldb to dump all contents of 1password in an unprivileged shell.
0 -
It hasn't been mentioned much, that at least on macOS, the System Integrity Protection does a rather good job in preventing the user, or even root, from dumping the memory of another process (except in the case of brew install, it seems).
Not sure if something like that is possible on Windows, but I guess the 1Password Mini could just restart itself after being locked to make sure that the memory gets cleared faster.
But yeah, overall, I think this issue has been greatly exaggerated, especially by certain "old school" security "experts" :) That said it's good to discuss these things every now and then, and great if something can be improved based on that.
0 -
Would Agilebits like to comment on the following article according to which 1Password keeps passwords accessible in RAM after the app itself has been locked?
https://www.securityevaluators.com/casestudies/password-manager-hacking/
Thanks.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided0
![[Deleted User]](https://w8.vanillicon.com/v2/87d6bf4bcda1274e7d83320d05f0c74a.svg)
