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

Added to the list of reasons not to switch to 1Password at large org.

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.

Another month, and not even an acknowledgement of the potential for leakage of sensitive information.

"bump" - this is still an issue, and one that I find surprising that ABits will not even acknowledge the potential negative security ramifications.

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.

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

ABits Folks - any news on this? Do you even believe this to be a potential security concern as I and other see it?

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.....

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.

Hi esquared:

Thanks for your feedback. While I can't promise anything specifically, I've shared your thoughts with the team.

Jack

ref: dev/core/core#10237