Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
This vulnerability is not something like a keylogger. Many people are mentioning the scenario like the system is fully compromised. It is not. A keylogger needs a driver to intercept key inputs, and thus require the admin privileges to run. This behaviour is not common, and can be easily identified by antivirus or HIPS. In this scenario, any program without admin privilege can grab the data immediately. The behaviour is no different than a diagnostic app that tries to grab memory dump in user space. An attacker does NOT need to have full control of this machine to get all your credentials. In fact, the attacker does not even need to know the specific targets to perform the attack. He just needs to distribute the program as a seemingly normal app.
0 -
I'm curious to know if the memory dump issue in Windows can be at least slightly mitigated by disabling windows core memory dumps in system settings.
i.e. setting "Write debugging information" to "none" ?
I'd like to echo my disappointment about these issues coming to light too. Whilst I realise it may be challenging for the AgileBits folks not to go backwards... that really should never be the case. 1Password 7 for Windows should be in all ways, better than 1Password 4. Thus far I've seen several regressions. Regressions in security should definitely not be a thing for such a security-focused application.
The same rings true for LML. That should always always be the case, and should never have been an issue, full stop.
0 -
I'll also just say that whilst I'm extremely disappointed in some of these issues. I'm very thankful that @jpgoldberg (among others) has been open and honest about the issues here in the forums. That speaks a lot for his character. That is something that I am absolutely not criticizing here and I significantly appreciate the transparency. I've been in similar positions in the past so can appreciate the pressure and difficulty in conveying such things in a public manner. The reality is, we're all human, we all make mistakes, and no one or thing is perfect. However I've always found it better to admit and accept the issue or error and move on to resolving or fixing it.
What's done is done. We should now look forward. What I'd like to see from AgileBits is (in very short order) their official summary of where things are at, and their commitment as to what, when and how they're going to resolve or improve these issues. I do realise this is a very complex field and that some of these issues are not easily solvable overnight, nor are there necessarily any perfect solutions.
That said, there are obvious avenues for improvement here, even if it is incremental and takes some time. That's fine. But, it's clear that improvement is needed here. So in the least I think we deserve to know and understand the path forward here and what actions are going to be taken.
0 -
Sad to say, after many years using 1Password, I'm not comfortable using it anymore, mostly because of the response to this issue. Frankly, I was never happy with the change away from ver 4 to the current iteration.
0 -
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.Just to clarify: Google is worried their cloud servers (which are shared resources per definition) might get compromised by side channel attacks (like Spectre). These types of attacks are hard to fix.
However 1Password running on a personal, isolated Windows machine - this is a completely different scenario. The current research by ISE has shown you don’t need to attack via a side channel - the malware just needs to search through the entire volatile memory (as its on the same OS instance) and grab the master key and all passwords. No need to gain elevated Windows privileges (e.g. with an exploit) - it’s not needed for this type of attack. Many applications have been altered to contain such malware code in the past - but simply reading memory would likely not even trigger any Antivirus alert and thus stay undetected. Password managers are a good trove for anybody seeking access to important core systems.
0 -
No more delays. No more shoving blame to "if your computer is compromised". 1Password 7 needs fixes ASAP, and needs them fast, not after months or years. Now that the cat is out of the bag, we can bet all the black hats will be eyeing this data treasure trove too - and they aren't stalling.
What would you have them do? Code their app or the password-handling parts anew in C in a rush? Dropping to a low level language would allow them to scrub memory, but would then expose the software to all kinds of attack vectors and make coding said app much slower and more difficult.
In the thread we already have established:
1) Using high-level languages such as C# will make it very difficult to scrub memory
2) Even restarting or killing the app will not scrub the passwords from memory
3) Coding in low level languages would allow scrubbing of memory but come with a multitude of other issuesUsing something like Rust or C# unsafe functions might be an option, but will take some time to implement - and even then there's the difficulty of using OS provided password input fields which might be incompatible with memory scrubbing.
And of course some layer of obfuscation could be added, to at least require 1Password-specific effort to find said parts of memory, if they cannot be entirely scrubbed?
This problem seems to be pretty hard. And if there were an easy answer, others would be surely doing that too - but it does seem that most of if not all password managers are more or less vulnerable this way..
0 -
They have been called out by Travis Ormandy for insecure pairing between the app and the browser and fixed that. While it was way easier to that than this, it is likely that they will fix that too.
0 -
@Damnatus: They have been called out by Travis Ormandy for insecure pairing between the app and the browser and fixed that. While it was way easier to that than this, it is likely that they will fix that too.
i remember that episode too, actually.
Well, like jpgoldbrg's response suggests, 1Password has had plenty of chances to at least partially mitigate the issue "for years", but they've delayed it this whole time. they're still delaying it. so beg your pardon if we have our reservations. what we need is a committed, actionable timeline for what concrete steps they'll take to fix the issue (vulnerability to be dumped from memory in plaintext even on 100% virus-free machines), and when they will deliver the fix. now that the cat's out of the bag (and on Wapo too, no less), you can bet this ticking time-bomb is ticking no slower than before.
this is a product security-crippling error. likely going to fix it is simply not good enough.
0 -
I find it fascinating that these issues were addressed by Goldberg in a 2012 post here on agilebits titled "Don't trust a password management system you design yourself". Bullet points 3, 5, 6, 7, and 9 all seem pretty relevent. It's difficult to see this as a blunder versus being a deliberate design choice to sacrifice security for a quick subscription model.
I'd love to think this was a big blunder, but the heavy handed push of users to a subscription while knowing these issues were being created, and the fact that it took a 3rd party to reveal the problem, leaves a very bad taste. The trusting side wants to think they made a simple mistake, yet the article shows they knew better. The paranoid side worries if it was deliberate. In the wake of other security controversies, there has been a lot of pressure for companies to provide backdoors. Simply cannot wrap my head around a security product leaving the entire database in memory. I work in research and data security in defense and was briefed that 1Password specifically is not to be used.
0 -
@Charlie_s
Just this week, after the issue was revealed, although it might have been part of a longer standing policy. Password managers are typicaly not allowed without special permission. Another manager was singled out as approved, but that may be in part to it being open source and the code being auditable.0 -
@A5rypTiK: I find it fascinating that these issues were addressed by Goldberg in a 2012 post here on agilebits titled "Don't trust a password management system you design yourself". Bullet points 3, 5, 6, 7, and 9 all seem pretty relevent.
am I accurate in my guess that you're speaking of KeePass? (open source, auditable nature)
Also, what you said here seems almost hilariously ironic now, since 1Password 7 has failed these points to me imho:
0 -
Hi,
The people behind KeePassXC (a community fork of KeePassX) have posted a blog post addressing this vulnerability and I think it is worth reading:
https://keepassxc.org/blog/2019-02-21-memory-security/
Although I couldn't say if they have a (better) solution or not, the blog post itself is easy to understand (for example, the different protection methods implemented on different OSs, the limitations...).
In that post, KeePassXC mentioned the "modern Windows memory security techniques available to all processes" and most importantly, "None of the other password managers featured in the ISE report have implemented this security. If they had, the ISE attacks would have failed outright!".
Any thought? Maybe 1Password could also implement those techniques to lower the risks a bit?I hope 1Password could have a blog post to address these issues rather than this lengthy discussion as not all users prefer to join a forum discussion and read all of the posts :)
0 -
@Donaldd great article. it covers some of the practices we were all insisting (for 3 days now) 1Password should have implemented, instead of fancy things like Family Share (which is a nice to have, but hardly a must). i dont even know why this is ever an argument to begin with if 1Password's top priority is our security & privacy.
@MikeT @jpgoldberg Could we get a response please? Thanks.
0 -
I find it fascinating that these issues were addressed by Goldberg in a 2012 post here on agilebits titled "Don't trust a password management system you design yourself". Bullet points 3, 5, 6, 7, and 9 all seem pretty relevent.
@jpgoldberg I like that seven year old article. When will you guys implement the mentioned bullet points?
0 -
Hi,
The people behind KeePassXC (a community fork of KeePassX) have posted a blog post addressing this vulnerability and I think it is worth reading:
https://keepassxc.org/blog/2019-02-21-memory-security/I just tried using the tool to grab the memory of 1password while it's locked, and I can confirm that I see my master password in it... (It is still shocking to see it in real even after knowing this for a fact). The tool is run without any admin rights, as a portable app.
I immediately closed the app, and will never run it again, until this issue is resolved.
I was not able to locate the same thing with 1password X. Chrome's design at least make it very hard to find it in memory.
0 -
I can understand if it's Sunday in Canada right now, but man, 1Password's silence despite our repeated prompts is almost palpable.
0 -
since I also have strong, Fortune 500 technical background
You claim to be the expert in this thread, and called for change where you seem to be pretty certain you know better than what many password managers, including 1Password, already does. We are all very concerned about our data safety. So since you claim a lot of technical and security expertise, can you explain to me a few things you've said.
Are you a security engineer or a programmer for finance?
a simple memory dump (even innocent ones triggered by legit software / driver crashes to create a telemetry log for debugging) is all it takes to have a security breach
Can you show me an example of legit software / driver crashes that would read and dump 1Password memory, or dump the whole system memory when it crashes? Every time I've had crashes I've only ever seen small memory dumps of just program that crashed, not from everything. If that happened wouldn't every crash give me 8GB memory dumps if I have 8GB memory? Screenshots would be awesome if you have examples of drivers or whatever that crash like that.
(something you've mentioned before I forget where, where you said 2FA protection would be better)
Can you explain more about how 2FA might work to protect memory? 2FA makes sense to me if it's on a remote server that I can't get to, but if it's already decrypted to plaintext on my own computer memory, wouldn't 2FA would just be another "UI / visual obfuscation" like you're saying?
@Donaldd great article. it covers some of the practices we were all insisting
The article doesn't really say, it just shows a screen, do you know what memory techniques it's using? Is it the same ones you use in finance? Wouldn't most people running as administrator, like a lot of people are saying in this thread, cause the same problem anyways? I don't know if that article example is running administrator or not, it really doesn't give much detail.
(you've said before that in finance where you work, memory scrubbing is 100% the bare minimum and it's unacceptable anyone would not use this)
As the expert in finance software can you tell me more about what techniques are used for this memory scrubbing, exactly? How does it work and how does it make sure the memory is scrubbed? How fast does it work? A lot of people in this thread are saying that you can try to tell programs to scrub, but it's still not really up to the program but the OS. How does software in finance make sure it really works instead of just thinking that it works?
Over all it just sounds like you're very certain you know better ways of doing things, so I'm trying to understand how so many password managers in this paper could have gotten it so wrong.
0 -
Is it worthwhile to disable Windows memory dumps to mitigate one of the concerns raised in this thread?
https://www.thewindowsclub.com/automatic-memory-dump-settings-windows-8
0 -
@XIII: Is it worthwhile to disable Windows memory dumps to mitigate one of the concerns raised in this thread?
Possibly helpful, yes.
So, @analogist I appreciate open discussion, but I'd also recommend that you spend more time looking at additional content (even outside of this forum - even beyond what 1Password's staff says). most of the questions you're asking are also somewhat covered in the past 10 pages in this forum.
To answer some of your questions in brief:
Are you a security engineer or a programmer for finance?
My background is actually from the Silicon Valley before being headhunted by the finance sector more recently. I've worked with code for 15+ years, and have recently been interviewing teams from MS, Google etc for the development of a multi-million USD product with ML capabilities. Currently serving as a tech lead in a department of 1400+ strong, working with career specialists spanning cloud deployments, infosec, UX, etc. Haven't had to touch code personally for some time now though, since I've moved onto managing people who do.
Can you show me an example of legit software / driver crashes that would read and dump 1Password memory, or dump the whole system memory when it crashes? [...] If that happened wouldn't every crash give me 8GB memory dumps if I have 8GB memory?
You raise an interesting question (I get what you're trying to ask), but that's not really how it works. For example, your machine can have 16GB ram; a video game or 3D CAD software may utilize the full 16GB in process, but the log file that results from a crash could still just be perhaps a text file ranging from a few KB onwards. The factors that affect how large a log file becomes are simply too much to note. What matters most, however, is the data it contains, and that a lot of crashes on Windows are configured to dump memory in-full. If you want an example in greater detail, I'd recommend that you look at this post here or the original research paper here, which recorded a hardware driver crash. I don't wanna sound mean, but I'm literally not paid to spend time on this.
Can you explain more about how 2FA might work to protect memory?
Actually that's not what I asked. The context of my original question (security key vs proper 2FA), is that if a simple memory dump (from say a hardware driver crash) is already able to reveal my 1Password 7's account email, master key / password, and secret key - all of which are in plaintext alongside my other login entries in the db - how is that going to stop a greedy recipient of my debug logs from accessing my 1Password 7 cloud account from another country around the world? Proper 2FA would stop such breaches in their tracks, but secret keys won't.
I brought this point up because 2FA is also something the 1Password team refused to implement for a long time, despite public pressure and the fact that they do help stop a number of new attack vectors (which master + secret keys simply cannot). I have a feeling secure memory management will be a major struggle for us like 2FA all over again.
but if it's already decrypted to plaintext on my own computer memory, wouldn't 2FA would just be another "UI / visual obfuscation" like you're saying?
Yup, but the reality is even simpler than that. Right now, 1Password will leak all of our password content in plaintext, so you won't even get any UI / visual obfuscation (even with 2FA turned on). That's how bad the situation is.
do you know what memory techniques it's using? Is it the same ones you use in finance?
If you read the article again, you'll find it talks about some of the lengths they go to take advantage of security features that are unique to each platform (macOS, Windows, etc).
While their post doesn't talk about all the specific techniques by name (which would be a long list not suitable for the situation), they DO note a few techniques like:
- requiring elevated administrator credentials to access KeyPassXC's memory, which 1Password team can do but apparently hasn't.
- disabling process core dumps for KeyPassXC, which can be done in several ways and 1Password team can also do but ???
If KeyPassXC has done more to protect its users from this type of attack vector / memory dump vulnerability than 1Password delivers right now, I count that as a win. And yes, these are in line with some of the techniques that we use at the bank too.
I think the issue here with 1Password is that it keeps delaying proper memory management with a ton of excuses, but if they had properly planned it to begin with, incremental improvements are valuable and we shouldn't ever hear stuff like "the cure may be worse than the disease". To me, that just sounded like a load of BS.
As the expert in finance software
Oh you are too kind, I'm blushing.
can you tell me more about what techniques are used for this memory scrubbing, exactly? How does it work and how does it make sure the memory is scrubbed? How fast does it work? A lot of people in this thread are saying that you can try to tell programs to scrub, but it's still not really up to the program but the OS. How does software in finance make sure it really works instead of just thinking that it works?
There are a lot of techniques involved that justify people like @DMeans & @A5rypTiK getting paid a ton of money every year to do what they do, some of which you can find here. At the end of the day, you may not be able to force a consumer end-point device to clear memory on command, but you can get pretty darn close to the point that a systemic compromise is simply not realistically possible.
As for how we know our techniques work for sure, financial institutions such as mine are required by law to have their digital products pass a ridiculous number of committees & external auditors (and we're not talking small shops; think big ones with as much talent as our teams do - EY, KPMG etc) - each product design choice is scrutinized, and we are held accountable to explain why we prioritized one milestone / product requirement over another (with reference to our product priorities like security, redundancy, uptime, etc). If a mistake happens in our customer's experience that results in financial loss / harm of some sort (and our mistake were partly to blame - even if it was mostly the customer's fault like having a compromised device), we'd be subject to huge fines & penalties (both internal & external).
These are not the same pressure that 1Password is subjected to right now, and I think it's partially to blame. Imagine how different their response today may be if the password manager industry is regulated as hard as mine, with millions of $$ in potential penalties.
If you want me to put in more time than this, I'm afraid I'm gona have to start billing someone :)
0 -
https://www.reddit.com/r/Bitwarden/comments/au87od/bitwarden_memory_test/
This clearly demonstrates clearing memory upon lock can be done. They also use C# / .net.
0 -
If anyone is curious this whole memory dump thing has me playing around with what password manager reveal secrets in memory. It's pretty easy to test yourself.
You open the password manager and unlock it. Go to task manager and right click the process and press the "create a dump file" button. It shows you where it saves the file, just change the extension to .txt to open it in Notepad and search for passwords. Make sure to delete this file after you're done with it. Sometimes the passwords have extra spaces in them like if your password was "bacon" you should also search for "b a c o n". You also need to be an administrator of the system which most people are if you own the PC. Also, try this at your own risk, I'm just some noob on the internet.
LastPass - I only tested the Chrome extension but it decrypts the entire vault into memory. I could not find a lock button but they do have a logout button but logging out does not clear passwords from memory. Restarting the browser does.
Bitwarden - I've tried the Chrome extension and Windows app and both decrypt the entire vault into memory. The master password is also visible in memory too. But when I hit the lock button on either the memory is cleared as far as I can tell.
KeePassXC or KeePass - Both of them decrypt the entire vault into memory. I could not locate the master password in memory.
Sticky Passwords - Doesn't decrypt the entire vault, only decrypts passwords as you need them. I did find the master password in the memory dump.
Enpass - Doesn't decrypt the entire vault, only decrypts passwords as you need them. I did find the master password in the memory dump.
Dashlane - Doesn't decrypt the entire vault, only decrypts passwords as you need them. I could NOT find the master password in the memory dump.
RememBear - Doesn't decrypt the entire vault, only decrypts passwords as you need them. I could NOT find the master password in the memory dump.
This was all the password manager I had to test. I've given the instructions above so you can test yourself. I find it odd that Dashlane does so well, good for them, but I hate their password manager and they cost way too much. And RememBear reminds me a lot of 1Password, they even do a secret key, but the software is often clunky at times (or when I tested it out at that time) but it does cost as much as 1Password. They're also owned by TunnelBear which some might not like because of the "controversy"..
One interesting bit, most of them, even the ones who did not decrypt the passwords until you needed them, still revealed other data in your vault. Things like notes which may contain your secret questions or back up codes for 2FA.
I do put blame on the password manager companies but I also want to put blame on Windows. Linux and MacOS seem to handle this shortcoming a lot better. I also want to point out that these dump files are huge just for one app (often 300MB in size). An entire memory dump would be massive, gigabytes in size depending on your memory. This is got me questioning if these things ever get sent anywhere besides a virus sending them? Also, the data in these files are very scattered and often hard to read. You could make an app to clean up the data but each app has its own way of handling the values and it can be hard to determine what is what. For example, a random password that is created can be hard to tell apart from the other gibberish in the file. I can tell because I know what to search for but someone who doesn't know might have a harder time.
And for a solution to 1Password, I've found that I can't read any memory if you exit the app at the system tray.
0 -
I found this today on Bruce Schneier's blog:
https://www.schneier.com/blog/archives/2019/02/on_the_security_1.html#comments
It claims that 1Password7 leaves the master password and its associated secret key on the disk, when the program is in either in a locked or unlocked state.
Please explain.
I am using 1Password7 v7.2.4 on macOS 10.14.3. I also use Windows 7 and IOS 12.1.4.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided0 -
Bitwarden - I've tried the Chrome extension and Windows app and both decrypt the entire vault into memory. The master password is also visible in memory too. But when I hit the lock button on either the memory is cleared as far as I can tell.
I'm just curious, did you run the test with the Windows Store version of Bitwarden? If not, can you run it again with the Windows Store version? My understanding is that Windows Store apps are sandboxed similar to how MacOS App Store apps are. I'd be curious to see if the memory used by Bitwarden is able to be seen with your methods if you run the test with the Windows Store version of the app.
Thanks
0 -
@mrpuck: I've merged your post with the existing discussion on this topic. Essentially, in order for 1Password (or any other software) to work with and make data accessible to you, it needs to be decrypted in memory. It's not as simple as that of course, and it's a challenge for all password managers, since they have a different function to most software. I'd encourage you to start by reading the research paper that Bruce refers to in his post:
https://www.schneier.com/blog/archives/2019/02/on_the_security_1.html
And the top of this thread has been updated to include links to more information from the perspective of 1Password:
0 -
The Bitwarden app was the Windows Store version.
0 -
For what it's worth, I don't have any special insight into how they're doing things, but while it may have been true in the past when the Windows Store only allowed UWP apps, Win32 desktop apps, the same as you download and run from somewhere other than the store, are allowed there. 1Password 7 would likely be there now too, if not for the fact that (as it stands) it would not be able to communicate with browsers besides Edge in that case.
0 -
@brenty, this has been an exhausting thread, but please bear with me, I'd like to make a request from the user point of view. I'd like to know what my exposures are, and if there are any reasonable mitigations I can take. Perhaps agilebits is already working on a blog post on this topic, in which case just tell me it's forthcoming.
As I understand (or misunderstand) it from all the above, there are two main exposures for Windows users. I don't understand to what extent Mac users are exposed to these threats.
If I have unlocked 1Password, it is possible for a crash to dump my master password, secret key, and vault contents in plain text. Moreover this remains true after I lock 1Password. Telemetry can automatically ship some or all of this to the app/OS developers. None of this requires malware on my machine. I don't understand which combinations (app crash vs OS crash; app telemetry vs OS telemetry) can do this. I understand that I can configure the OS not to take any memory dump, but I don't understand which 4 combinations of app/OS and crash/telemetry this mitigates.
If I am an unprivileged user (no admin access), any process running in my session can read the process memory of 1Password and see the plain text of my master password, secret key, and vaults. Moreover this remains true after I lock 1Password. To do so is considered malware, but it does not require admin, it is a simple failure of process isolation in Windows. General "security hygiene" reduces the chance of this happening, but if I get malware (even without admin) all my secrets are instantly gone, it is not necessary for the malware to persist and collect the secrets over time as I use each one. I can partially mitigate this threat by having two (or more) 1Password accounts / family members to separate my secrets into precious and not precious vaults, and so the precious secrets are simply unavailable to me and malware in my normal computing sessions.
Have I got those threats right? Please correct my understanding if I got them wrong. Are those mitigations reasonable and effective? Are there more threats and mitigations that you'd like to tell your users?
0 -
FYI, I've moved derek328's commentary peripheral to this discussion on the ISE paper to a separate thread, where possible, in order to keep this one on topic.
@derek328: I realize that it takes time to write each post, and I appreciate the passion and effort in this regard, but when you've already made your point please refrain from doing so over and over, to give others room to participate -- and save yourself the time and energy. As you've noted, all of your original comments are still available for anyone to read. :)
0
