Why are items moved between vaults listed in "Recently Deleted"? Bad security model!

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.

Hi BobW / esquared:

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

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 https://1password.community/discussion/131324/1p-8s-uncontrollable-auto-fill-just-gave-away-my-private-data, 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.

I second that. For what good seconding anything seems to do around here anymore...

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.

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.

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