Why are items moved between vaults listed in "Recently Deleted"? Bad security model!
Since well before 1Password 8, items that I move between vaults end up with a copy in recently deleted - this is REALLY confusing when listed with items that were really deleted. The items in the deleted folder seem redundant at best, but I've generally ignored the issue.
However, today I discovered how this is really a potential BIG security hole. For example, if I move an item to a vault I share with others, but I moved the item to to the wrong vault and moved it again to the correct vault, the "deleted" moved items remain accessible to users of the wrong vault. That requires me to take an extra step to empty the trash or permanently delete the specific items.
This same issue could occur if I expand the group membership on some vault, with the intent of moving a small subset of items out to a more secure / limited vault. Again, I have to manually issue "permanently delete" on the moved items.
Why is it that items moved need to be added to recently deleted at all? They were moved - just let them exist only in the destination vault. I don't need to be able to "recover" a copy of the item to the original vault.
1Password Version: 8.7.1
Extension Version: n/a
OS Version: macOS 12.4
Comments
-
Hi @esquared:
Great question! In short, moving an item between vaults is actually a copy+delete operation under the hood. Because the item is "deleted" after the copy, it remains in Recently Deleted. While I can't promise anything, I'll add your feedback to a feature request we have internally to make moving an item behave closer to the way you're expecting.
Jack
ref: IDEA-I-353
0 -
Thanks for the quick reply, but I have to emphasize that this is a very serious security issue. Despite how you implement it on the back end, the effect as thought about by the user is a move, and the current implementation leaves it way too easy for someone to inadvertently expose themselves or their company to a security breach.
0 -
Any news on the security ramifications of the issue I raised? I'm quite surprised nobody else has seen this as a huge security hole, and nobody at 1P/ABits has acknowledged it either.
0 -
I second that. For what good seconding anything seems to do around here anymore...
0 -
Oh wow! I do vaguely recall noticing this in the distant past, but it was in the heat of something else happening and I completely forgot about it. I fairly often have to move things when I put them in the wrong vault -- particularly in v8, with the way it guesses where a new item should go instead of just letting me specify a default -- so I'm probably leaving things all over the place. I've also moved lots of items when I introduce a new vaults to adjust access. For example, I'll move sensitive items to a new vault right before opening sharing access on the original vault.
This is definitely a huge security problem. I suppose I need to set aside a day or two ASAP to go through my several dozen vaults to see what may be errantly hanging around....
It hurts my brain just to think about all the cases of this that my corp users may have triggered. And we all know how successful a request for them to do their own reviews will be. What a mess! And what a waste of time.
I don't see how this can be considered anything but a critical security bug. No one is going to expect a "move" operation to leave an item blatantly, yet non-obviously, accessible in its original location. A fix should go out that, if at all possible, identifies and cleans up affected items, then lists them for the user so the user can change those credentials if appropriate.
Just like with the auto-submit issue, stuff like this makes me question how committed to user-friendly security the Agile team is these days. These are both cases where poor UI/UX decisions have opened the user to serious security gaps that can only be avoided through unreasonable attentiveness in daily activities and closely following this forum. It's the opposite of what 1P was created to do. And not only did you guys go with poor UI/UX decisions to begin with, but much worse, you dug in when they were pointed out instead of jumping on fixes. I still love 1P (hence why I'm here complaining so much - it comes from a place of love) for all the goodness it has, but at some point, these problems will become too much and I'll be forced to switch to something else that I don't like as much but which doesn't compromise as much on my security.
0 -
Thanks for your feedback here. The challenge here is that changing this behavior may result in data loss scenarios. Additionally, even if we were to change the way moving items worked and completely delete them after the move, the item would have still existed in that vault. Anyone who had noted the password down prior to the item being moved would still have access to that credential. Generally speaking, the best solution after moving an item from a vault would be to change the password of the item in the new vault, so that the credentials are no longer valid for anyone who may have copied it prior to the move.
Jack
0 -
@Jack.P_1P - you are totally missing my point. If I inadvertently move an item to the wrong vault for as little as one second, a copy of the item remains in the deleted items list associated with that vault. Certainly there is the possibility of someone watching and getting access for that one second, but come on - that's not the scenario I'm talking about.
Yes, in the worst-case, I need to change the password of that account. But in the case of something that is not super sensitive, I'll evaluate my risk and say, "nah, nobody could have seen it that quickly,* and just move on. But as it stands now, I can't. I have to remember that a copy of the item exists and they do have access and I can't stop that. So I am forced to change the account password, causing me more work. All because the tool can't figure out to do it "right"? That's absurd.
Moreover, you are also ignoring the issue that most people see the "move to vault" as a move, not copy/delete, and are NEVER going to think about the possibility of there existing copies of entries in a "deleted items" area. This is because you used the term _MOVE. If it's not a move, then don't call it a move. Call it what it is or change the underlying implementation.
As to your point about "data loss"? Come on - that's just words meant to placate me. If you implement it right, there's no chance for data loss. Tell me the scenario under which there would be data loss because you didn't do the "Copy / Delete" method as it exists now and I'll consider your logic and perhaps reconsider my position.
If you want to leave it as a copy / delete, then at least permanently and immediately delete the old copy so it can't be recovered form the deleted items list.
As it stands now, as far as I see it, this is a KNOWN security issue that I will continue to pester you on. For a security-industry company and product, it doesn't feel as if you are taking the possibility seriously.
0 -
@Jack.P_1P - thanks - please do post back here any design or dev opinions that you are allowed to share.
Alternatively, I'm happy to engage more closely, NDA or whatever needed, if someone wants to talk to me about this outside of this forum.
0 -
Agree with @esquared about the short-lived scenario. The example of this I gave is when I accidentally save a new item into the wrong vault, which happens all the time now because of v8's vault selection logic. So yes, if it's not something super-sensitive, I will frequently choose to live with the small risk that someone was able to grab the item before the move. But the thing is, that's my explicit choice: when that happens, I'm obviously aware that I exposed the credential for whatever period of time, and I have to consider, each and every time, where the item falls in the balance between security risk and convenience. For some items and with some vault audiences, any amount of time is too much and I'll be cursing under my breath as I go change the cred. For other items, I can live with it having been there for virtually any length of time as long as I know it's corrected going forward. And. of course, everything in between. But the key part is that I'm aware of the situation and making the decision how I see fit based on the details of the situation.
In contrast, the risk presented by the move actually being a quiet copy-and-not-really-delete is one that's totally unknown to most users. If the user made a mistake by misplacing an item, and then fixed it by "moving" the item, as part of that, they were also forced to weigh the security risks of the situation and perhaps decided to live with not changing the cred. So far, great; after all, everything in security is about choosing a compromise for the situation. The user caught their mistake, fixed it, and then did whatever cleanup they deemed necessary based on a consideration of risks. But wait! That's only what the user thinks they did, because the user was acting in ignorance of this security bug. Because of this security bug, what actually happened was that the user caught their mistake, copied the cred somewhere else, and left wide open the security risk they so carefully considered and thought they'd addressed.
In other words, 1P took a short-lived security risk that was thoughtfully considered and addressed by the user, and turned it into a different security risk that's far, far worse because the user is oblivious to it. Now, the best-case scenario is that the user is aware of this bug and addresses the new problem; as @esquared put it, 1P has forced additional actions by the user. Most of the time, however, the user will not be aware and the security risk will persist.
Now, consider the other scenario that I described, because it's much worse. I want to expand access to a vault but some items are too sensitive for the new audience. So I move those items to new vault that will stay locked down, then open up access to the old vault. Uh-oh. In this scenario, the 1P bug has created a security breach where there was none, and it's potentially a very bad one because it's exposing the credentials that I just decided were the most sensitive! I anticipated a security risk, totally eliminated it through careful process, and ended up getting screwed by 1P. And most users will never even know it, at least not until something bad happens with one of those leaked credentials and a security incident investigation is performed.
I've done exactly this process many times, oblivious to the fact I was leaking credentials. And in many of those cases, the information leaked was extremely sensitive, such that those leaks could have ended up costing my company millions of dollars and me my job if anything had happened. I'm thanking the security gods that nothing ever did.
I, too, would love to hear about these data loss scenarios. If that's true, then something's architecturally wrong with the implementation. There are patterns for how to safely code these operations that were well-understood before most of us were alive, so that simply shouldn't be a thing. Further, all indications are that 1P's engineers are quite competent. But they are engineers, not security experts, product design experts, UI experts, or UX experts, and I can easily see them going with this solution because it technically works, particularly with a bunch of demanding deadlines looming. I think the failure here is with the people in all those other roles not catching it and insisting on a better implementation, likely because of a weak product life cycle versus any one person being bad at their job.
Many folks have voiced concern about all the investor money pouring into 1P now, and all the investor demands that come with the territory. Perhaps there's something to that.....
0 -
ABits Folks - any news on this? Do you even believe this to be a potential security concern as I and other see it?
0 -
I don't have an update to share. Thus far this has not been identified as a high impact situation. I do personally think it is something that could use some additional exposure, if nothing else, and will continue to advocate for it as opportunity arises.
Ben
0 -
Thus far this has not been identified as a high impact situation.
That is a sad statement. We have clearly outlined situations in which this could lead the information leakage. In the most obvious case, someone who is the member of multiple accounts, e.g. an MSP situation, could inadvertently leave "moved" copies of credentials in the deleted folder of the wrong customer.
I will also claim that blaming the user is not an option here. The tool is simply doing something that most users will simply not expect. Heck, poll your own staff at ABits and I'll bet you a beer that half don't know this mis-feature exists in a product they work on and presumably use daily.
I urge you to think harder about the ramifications of this choice and how the reputation of the company could be adversely impacted if not addressed.
0 -
"bump" - this is still an issue, and one that I find surprising that ABits will not even acknowledge the potential negative security ramifications.
0 -
Another month, and not even an acknowledgement of the potential for leakage of sensitive information.
0 -
Wow, the current behavior is quite surprising! I'm so glad I found this thread. Thanks for reporting this issue, @esquared. You and @BobW are totally on-point. I would never have expected that a "move" operation would leave a copy in deleted items, but here we are... frustrating that I have to keep this security risk in mind.
0
