Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
@MikeT responding here as requested
It was my understanding, and the report suggested, that SGX and secure enclaves is whats missing here. Secure memory management. My question is ... why cant a hardware security token be a portion of the solution here? Offload the authentication aspect, give me the option to use asymetric keys to "authenticate" (decrypt) with the 1password app.
Would it not be feasible to not decrypt all credentials, but opt to do them one at a time as they are requested?
I understand that even if a hardware token was used - the entirety of a users login credentials would still exist within memory as its currently implemented. However, we have removed one item from the table. The 'master password' is no longer in memory as its been delegated to a hardware token. That, to me, is progress.
In the event that future advances are made with the .net framework where memory scrubbing is more feasible for you to implement - then I would still want a hardware token. Why? You can take my master password from memory, keylogger, etc .... but to bypass or exploit the hardware token authentication aspect has proven to be a much harder task. If i'm mistaken here please let me know.
0 -
My suggested attack vector is following: I install a game from steam (program from reliable source), but notice strange behavior and think, that it may has a virus or at least sniffing part. I uninstall the program, rollback with backup and think that has it been after anti virus scan. Because in this time 1Password was running, but locked it exactly would have been the scenario of "has no access while unlocked" and "has access while locked".
Including with the mentioned memory dump scenario from various legitimate programs, the current way widens the attack vector notably.
0 -
I still think that memory scrubbing of any secrets as soon as possible is important.
The arguments that say otherwise (e.g. comments here and here from 1password team members) are correct only when assuming malware with access to 1p memory already present when a safe is getting unlocked.
But consider the point in time when your workstation with 1p in use gets infected:
With 1p keeping secrets unencrypted in its process memory, right after the infection the malware can extract the passwords, send it off to a server, and then wipe all traces of its own activity including itself, within seconds. That's exactly what malware targeting a password safe would want to do.
With scrubbing, the malware would have to wait for a user to actually type in the master password, which greatly increases chances of being detected before that happens (by virus scanners, or the user realizing having done something stupid shortly after clicking the install button of that flash update...)
This is especially critical for separate, but far less often used/unlocked vaults security aware people are likely to have for the really sensitive passwords.
Bottom line, IMHO:
- memory scrubbing for the master password and all derived keys is a must. If the high level SDK does not provide it, then that single path between the password entry UI and the encryption engine needs to be implemented at a lower level (that's possible, and can be done while still using high-level SDK for the complex rest of the app).
- decrypting more passwords (all, in 1p 7, as it seems?) than those the user explicitly asks for should not happen, ever. That's a similiar carelessness as having the same passwort for all of your online accounts. Of course, as long as the master password is not scrubbed properly, this second point is irrelevant :-(
0 -
I'm not going to pretend to be smart enough to throw out solutions. I do know there are levels to information I want to keep secure. The vast majority of passwords I use day in and day out I can work around a breach. I don't want one to happen, but if they do it's just a minor pain and I'm on my way. There's some info though I really don't access often at all such as bank account info, crypto keys, etc. Super sensitive info that would be very harmful if it got out.
I'd suggest that 1Password allow users to have two separate instances of 1P with different encryption keys and passwords. Vaults are fine for organizing, but reading up on this they offer nothing in terms of security. This way I can have one instance up and running for my day in and day out stuff that I use often. I can keep an instance I use far less often for my most secure information and only access it when I need and close it out when I'm done.
It looks I could do that with the family plan by setting up two users for myself, but I don't need a family plan. I'd love some sort of flexibility to limit exposure by segregating my most sensitive data from just everyday password management.
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.
A user query never searches for a password, or any other secrets for that matter, but only for the name of a certain entity, or URL, or identifiers in general, that are stored in the database. There is no reason to decrypt the actual secret(s) before the user actually wants to access them.
In general, I find it a bit worrying that some of 1P's employees said that certain features were not implemented because they would increase the complexity (?) too much. In my opinion, a security-focused product should not take shortcuts because it is too much of a hassle to implement things properly and to actually protect their users. That's like a car company saying that because of certain changes they have made to the structure of the car, it would be to difficult to fit seat belts and nobody has to worry about that because most people don't have car accidents and if they have one, it doesn't really matter.
0 -
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.
@fritzophrenic: It's a good question. The answer is that since we don't have direct control over when the memory is released, there unfortunately isn't a good answer. It will not remain in memory indefinitely, but whether locking or quitting, we are allowing the OS to manage when it's cleared. On booting into the OS though, before unlocking 1Password, the data only exists on disk, in encrypted form.
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.
It's certainly an option we could consider adding, but we don't want to present that as a solution to this complex issue. And the usefulness would be limited. If we can gain more control over memory without losing the other security benefits of not managing memory ourselves, that could be win-win. We don't want to trade the security and stability benefits we have currently just for better optics.
However, I normally use 1Password through the browser extension. Does the browser extension likewise leave decrypted passwords floating around?
Another good question. In reality, there is no browser extension, at least not in the way it may seem. It's just a way to hook into the browser. Everything you see and use there is, in fact, the 1Password app, which handles the UI and data. So it behaves the same. It's worth noting though that, by that same token, data is not stored in the browser. When you access, say, a Login, its data is sent to the browser at that time. So in that sense, while the situation doesn't change for 1Password running in the OS itself, there is inherently a smaller attack surface in the browser, by design.
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.
This is a really good point. With regard to the information that has been sent to the browser by 1Password, the memory there is managed (to some extent) by the browser itself (and then of course up the chain to the OS). It hasn't been found that data can be accessed there, likely in large part to the sandboxing of components within the browser (individual tabs/windows, background page, etc.) That's not to say that a flaw couldn't be found in the browser, but there's less data there at any given time, based on your usage.
0 -
In general, I find it a bit worrying that some of 1P's employees said that certain features were not implemented because they would increase the complexity (?) too much.
I actually don't find that worrying, just being honest, since adding complexity usually introduces more vulnerabilities than keeping something simple (given that a reasonable threat assessment has been done which I believe the 1Password-team did). However I think there is still room for improvement and there have been some good ideas I have read on this thread. I am confident that the team will consider them and implement them if it makes the overall security better.
It also makes me very happy to know that also Rust is being considered by 1Password as a way forward and I would be very happy to see the day the security relevant parts for 1Password are written in Rust.
0 -
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.
@blankspace: gazu said it more succinctly than I could in their comments just before yours:
This is such a hard problem to solve that no password manager has successfully done it.
We're not satisfied to leave things as they are, but as mentioned previously we need to be sure that we don't sacrifice the security and stability benefits we have currently just to avoid this particular issue. If we can find a way to have our memory-safe cake and eat it too, that will be great for everyone though. :)
0 -
Am I the only person reading through this entire thread feeling like majority of the 1Password team are just constantly sugar-coating and implying the statement “We're right, you're wrong”?
Whatever happened to the customer is always right?
Also it should be noted that this argument of “If your PC is compromised then nothing will help.” is just appalling on so many levels it isn't even funny.
I've tried my best to stay positive about 1Password, but after seeing the neglect it is getting in the security field, I'm genuinely debating swapping over to something that at least TRIES to be more secure instead of just shrugging it off as “Well if your pc is compromised there is nothing we can do” (When there is in fact plenty you can do to make it a pain in the ass for whoever has compromised you).
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.
@analogist: That's a heck of an analogy. :) In all seriousness though, I wouldn't be so hard on the researchers. This sort of thing, while it can get a bit out of hand, pushes all password managers, not just 1Password, to continue to work to find solutions to challenges like this. We'd very much like to be able to harden security further by having more control over memory, and if we can find a way to do that while still getting the memory safety that is so important to avoid other security issues, that will be good for everyone -- not just 1Password users, and not just us, but the whole industry. :)
0 -
@analogist tried with UAC at highest level, same thing: on win10, admin account (I expect majority of users running that), UAC at max, 1password unlocked and relocked, I can launch HxD (a hex editor that can read process memory as well) without elevation prompt (I see it running in the same context, elevation level and other security related bits in process explorer) and open 1password memory and search for my passwords as UTF16 strings.
That means a browser or anything else running on the system can as well. Browser is most worrying because that is the main way remote code can be executed en-mass if browser itself has an exploit.
0 -
@brenty re "This is such a hard problem to solve that no password manager has successfully done it." -- according to that article, keepass seemed to limit exposure to only explicitly accessed passwords. This is X times better than 1password where X is the number of passwords in your account :)
0 -
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.
@arabbit: I'm sorry to be a pain about this, but that's acknowledged by the researchers themselves in their paper:
Keylogging and Clipboard sniffing are known risks and only included for user awareness, that no matter how closely a password manager may adhere to our proposed ‘Security Guarantees’, victims of keylogging or clipboard sniffing malware/methods have no protection.
Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.I am pretty sure they weren't saying that to "brush off" or minimize anything, but rather they're pointing out that this is an area where there is room for improvement across the board.
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.
We cannot guarantee when memory will be cleared by the OS and its frameworks when not managing the memory ourselves, and there are significant security and stability drawbacks to doing so. A "quit timer" feature may be useful, but ultimately it may not be a sure solution. Hopefully we'll be able to find an option that gives us more control without giving up what we have already, because, while not perfect, there's a lot to recommend the current approach -- which I imagine is why we're not alone in this.
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 disagree. As noted by the researchers, the fact that password managers are not currently able to manage memory is not a reason not to use a password manager. It's more secure than the alternatives, and this kind of research pushes us all to find a solution to this common problem, and gives users a fair assessment of the landscape.
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?
@Donaldd: Good questions. I think the researchers did a great job of covering this in their paper (which I applaud, because it isn't always the case that end users are given actionable recommendations after they've been terrified):
End users should, as always, employ security best practices to limit exposure to adversarial activity, such as:
- 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)
A lot of that applies regardless of the context, but it's always good to have a reminder that we can and should take an active role in our security. :)
0 -
@ceyrich: Please see Mike and Goldberg's comments above:
https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044
https://discussions.agilebits.com/discussion/comment/493079/#Comment_4930790 -
Also it should be noted that this argument of “If your PC is compromised then nothing will help.” is just appalling on so many levels it isn't even funny.
@DeDefiance: That's acknowledged by the researchers themselves in their paper, which is the topic of this discussion:
Keylogging and Clipboard sniffing are known risks and only included for user awareness, that no matter how closely a password manager may adhere to our proposed ‘Security Guarantees’, victims of keylogging or clipboard sniffing malware/methods have no protection.
That's not argumentative; it's reality. We, like the rest of the industry, will continue to work to find solutions to these kinds of issues. But we have to be realistic, and also not shoot ourselves in the foot and introduce other issues in service of addressing this one. If it were simple, it would be a solved problem and everyone would be doing things differently. But it's not. :blush:
0 -
@brenty
Sure I get that, but a common example used has been browser exploits. It's happened in the past where there have been exploits for browsers that are able to dump RAM. I would not consider this a "compromised" computer in a sense, since the only place it is occurring is via the browser. However, this becomes an incredibly fatal attack on someone who stores every single password, credit card, address in their 1Password vault that just gets dumped in plaintext from the victims computer.Overall it's just hard to feel content with the current state of security of 1Password, not even just relating to this. You don't support U2F, and you store a user's vault contents in plaintext. I'm trying to give the benefit of the doubt since I do like 1Password, but it's hard when it feels like at any moment my entire vault could be dumped and it not even be my fault.
Let's use ransomware as an example. Wannacry spread incredibly fast and to my knowledge, without many peoples consent due to an exploit in Windows that allowed shell-code to be injected. This means it wasn't someone just downloading something they shouldn't.
What would happen if something like this was to happen again (Which is somewhat inevitable imo), but instead of just ransoming files, they now dump your RAM and see "Oh sweet, we now have all their passwords and credit cards. Bet they will pay 10x the ransom to get these back."
So yes, while I do understand that the issue is somewhat complex and it's not as simple as just "do this" and it's fixed and the vault is no longer in plain text, it would still be reassuring knowing this was a high priority thing and security was being taken seriously.
In my opinion, the letter written on the WP by Jefferey contained way too much "fluff" and PR and I think I speak for everyone in saying we wished he would just have said "We are working on a fix for this but it's not a simple task.", instead of justifying why it's even a problem in the first place and why it doesn't deserve a solution. (Which in my opinion is wrong.)
Again, I don't want to come across as rude, these are just opinions, but it is quite frustrating when you pay for something and feel like even though all of the userbase is asking for something (Both U2F and a "fix" for this memory issue), it feels like it's falling on deaf ears.
0 -
@jpgoldberg the case in question that you keep saying is rare seems to be exactly the case we’d have with a forensic attack on a suspended (laptop closed, 1p previously unlocked) system. I’d prefer that (insert your chosen devil’s) security forces or some private detective not get access to all of my passwords from a stolen/confiscated laptop. Your thoughts? Am I off-base?
0 -
@jpgoldberg further follow-up, I firmly support your decision to use the operating system-based password entry fields, but this is a generic problem that all operating systems need a way to support. There has to be a way of removing and clearing password entry fields. If they don’t exist, please use your excellent relationship with Apple and the other providers to hammer home the severity of this problem. It’s not 1Password specific.
If the choice of Delphi has hamstrung the firm in this matter, then that’s on AgileBits. Again, I firmly support you using safe languages, but they need an interface for this type of operation.
A forensic attack weakness is “very bad;” an accidental memory dump of all unencrypted passwords because of a program/system exception is inexcusable.
1Passwd [sic] loyalist from the start, and 35 years as a network security developer.
0 -
Another good question. In reality, there is no browser extension, at least not in the way it may seem. It's just a way to hook into the browser. Everything you see and use there is, in fact, the 1Password app, which handles the UI and data.
@brenty Regarding this, how is 1Password X handling the situation as it does not need an app. Relies it on the browsers deletion of the cache?
0 -
Sure I get that, but a common example used has been browser exploits. It's happened in the past where there have been exploits for browsers that are able to dump RAM. I would not consider this a "compromised" computer in a sense, since the only place it is occurring is via the browser. However, this becomes an incredibly fatal attack on someone who stores every single password, credit card, address in their 1Password vault that just gets dumped in plaintext from the victims computer.
Oh, that's an excellent scenario of having "locked" access but not "unlocked". Thanks! I was struggling to come up with a compelling example. Other good ones in this thread: virtual machines, locked laptops, and memory dumps from crashes sitting around on disks.
The best I could come up with, was an attacker sniffing around the network at a big company and grabbing locked vault contents, but limiting their time and presence on the network to avoid detection so not being able to widely install persistent keyloggers or other malware, nor wait around for a user to unlock a database.
I'm wondering if the pagefile and/or hibernation file could also be a vulnerability to consider. I assume 1Password takes steps to keep secrets from getting swapped out to virtual memory, but if the memory is "free" somewhere in the process memory that probably isn't as well-protected.
you store a user's vault contents in plaintext.
Uh...no, they don't. It's not "stored" in plaintext. You decrypted the password vault. It's sitting transiently in memory.
The problem is that the memory is not as transient as it ought to be, even after locking the vault.
Let's use ransomware as an example. Wannacry spread incredibly fast and to my knowledge, without many peoples consent due to an exploit in Windows that allowed shell-code to be injected. This means it wasn't someone just downloading something they shouldn't.
What would happen if something like this was to happen again (Which is somewhat inevitable imo), but instead of just ransoming files, they now dump your RAM and see "Oh sweet, we now have all their passwords and credit cards. Bet they will pay 10x the ransom to get these back."
There would not really be any way to ransom the passwords. The vault is stored on 1Password's servers, and you should have a backup copy of your secret key which you printed out at account creation.
I guess maybe they could use the master password to log into 1password.com and change your password on the server. I added my wife as an admin on my family account, so I could just have my wife reset it back for me. Or (edit: just realized they could first reset her password first, since I'm also admin, locking us both out...) there is 2FA available. In theory 2FA would prevent them just changing your password even if they were able to retrieve the master password from memory.
Now, USING the passwords for malicious purposes would certainly be possible.
So yes, while I do understand that the issue is somewhat complex and it's not as simple as just "do this" and it's fixed and the vault is no longer in plain text, it would still be reassuring knowing this was a high priority thing and security was being taken seriously.
The vault has never been in plaintext. You decrypt it into memory. You need to decrypt it into memory in order to use it. There isn't another way to use an encrypted password. The problem is that memory can be dumped from outside 1Password. There isn't anything 1Password can do about that. The only thing 1Password might be able to do, is limit the amount of time passwords are sitting in memory after you decrypt them. Right now, that time is longer than we've been led to expect with the "lock" feature. I agree that's a problem that needs fixing somehow, but it's not like 1Password is totally broken right now even with this problem.
0 -
@DeDefiance: I agree with most of your comments, and I thank you for making them. But I did want to clarify a few points:
Overall it's just hard to feel content with the current state of security of 1Password, not even just relating to this.
We're not content either. That isn't to say we're going to make a sweeping change hastily because we happen to be in the news this week, especially when that would mean giving up the positives about the current setup. But we are always working behind the scenes to find better ways of doing things. I'm glad Goldberg already mentioned the stuff going on with Rust himself, as I'm not going to be the one to spill the beans on something like that. ;) But that's just one example of the planning and experimenting that goes on behind the scenes.
You don't support U2F,
That's really not relevant here, and I addressed it in another thread if anyone else is interested. Relevant to this discussion though, U2F would not solve this problem. You still have to decrypt data in order for it to be usable, and that still requires keeping it in memory for a time. The question is how to get rid of it reliably, without taking on additional risk in the process by managing memory yourself.
and you store a user's vault contents in plaintext.
No. I don't believe that RAM is considered "storage" by almost anyone. But it is true that apps use RAM on a temporary basis for data that is needed, and 1Password similarly does that. The challenge here is getting rid of it after that reliably, without sacrificing the reliability and security of memory safety. There's definitely room for improvement.
I'm trying to give the benefit of the doubt since I do like 1Password, but it's hard when it feels like at any moment my entire vault could be dumped and it not even be my fault.
That sucks. There's just no two ways about it. I'm sorry about that. I think that the researchers gave a great overview of what end users can do to help avoid attack, but I apologize that you're having to worry about this. I think we made the right call, given the alternatives available to us at the time; but we'll continue working to find others, hopefully with even better tradeoffs that afford even greater security. Thanks for your passion for 1Password, and your honesty and constructive criticism here.
0 -
The problem is that the memory is not as transient as it ought to be, even after locking the vault.
@fritzophrenic: I really like this way you put this. Sums up the password manager research paper very nicely, and I think it's something we can all agree on. There's room for improvement in this area, across the board. And since 1Password is the only software we have control over, we'll need to see what we can do to do better there.
0 -
Very disappointed by the glib nature of 1Password's response to this problem. It's more concerning to me that 1Password is trying to gloss over these problems as though they're unavoidable, inevitable, or harmless than the problems themselves.
0 -
Very disappointed by the glib nature of 1Password's response to this problem. It's more concerning to me that 1Password is trying to gloss over these problems as though they're unavoidable, inevitable, or harmless than the problems themselves.
0 -
@bmitchelmore: I'm sorry you feel that way, but the reality is that all password managers need keep decrypted data in memory in order for it to be useable by you, and while there is room for improvement across the board with regard to getting it out of there after it is needed, that's not simple. All of this is acknowledged by the researchers, so I disagree with the assessment that we're being "glib" or "trying to gloss over" anything, and I don't believe they are either.
0 -
@jpgoldberg You asked:
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.
Not that I was part of the original discussion, but as a software architect / developer of 26 years having used from assembly through C and C++ and C# and Java and Python and... I think this specific response is extremely short sighted. I once heard Bruce Schneier make a comment that he did not understand the security benefit of masking passwords as a user is typing it. What he completely missed (and keep in mind, I believe most people will agree he is a highly respected figure in IT security), is all those IT support people needing to remote in to someone's PC to provide technical support. They should not be allowed to see the password a user is entering if the user is asked to log in to one of their sites - this is a modern form of (remote) shoulder surfing.
Point I am trying to make is that it is easy to be narrow minded and overlook the obvious, even if you are an expert. Here are my quick thoughts on the comment above:
- Why encrypt the vault at all? If my machine is not compromised, then surely nobody can access my vault stored on my PC? You decided to encrypt the vault to protect the passwords from someone who already has some access to the PC in question. Otherwise you would not have bothered with encryption.
- Why implement an auto lock feature in 1Password at all? Similar argument as above.
- So now that we have established you had put in specific effort to protect against a partially compromised host, the natural question would be where did you decide to draw the line? How compromised is "too much" to protect against?
- In my opinion, the line should be drawn exactly where a reasonable, informed person's expectations are at. Meaning most reasonable people would think that if the vault is encrypted, then nobody can copy the vault file and crack it offline - this is indeed the case. Most reasonable people would believe that if the 1Password vault is locked, they can walk away from their PC and nobody will be able to get at their secrets. They do not understand about memory management, garbage collection, reference counting or any other technical details. You provide people with a sense of security. You advertise that the vault is encrypted. You advertise that it can auto lock. But why implement auto lock if someone can read all the secrets from memory?
- So now we have established you implemented measures to make it harder for an attacker to gain access to the secrets. They cannot crack the vault - it is encrypted using strong cryptography. They cannot walk up to the PC and just click away on the password items as the vault auto locks - so you are protecting against casual attackers with limited / no technical skills. These are all good things. However, you do not protect a user against a 1Password vault that shows as locked, with an animation showing all items are hidden and secure, yet a skilled attacker can walk up to the PC and read the secrets from RAM.
Conclusion: If it is technically possible (note, I did not say easy, I said possible), I think you should be clearing secrets when the vault is locked. Even if you have to implement a feature where the app relaunches itself on auto lock if that is the only way. If not possible (and it is possible as per my last worst case suggestion), then at the very least put a big red message on the lock screen informing users that the vault is only obfuscated when locked, that the user should close out of the app if they want it completely secure. At least then you align the user's expectations with reality.
My 2c as a customer for many years.
0
