Small feature request: Password reprompt when deleting account

Budgieee

Hello there, first, I would like to say that I am very happy with this password manager. But, there can be something little bit more improved.
I have an issue, that when you go into the settings, the danger zone is clearly visible, and if someone would want to cause a lot of damage, for example when I just leave my computer unlocked, they could just delete my account and all of its data without my master password. I feel little worried because of this..

All I would like is for 1Password to require the master password when deleting the account.

Thank you for reading :)

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

jpgoldberg

That is a really good point, @Budgieee.

The short answer is that we have backups. If an account is accidentally or maliciously deleted it can be restored. (Note that we also have a mechanism for removing the data if you for total removal, but that is a multistep process.)

The longer answer is long:

It turns out that doing so in a meaningful way is tricker than it might seem. There are a couple of things that interact in odd ways that make this tricky.

1. We don't look putting in security measures that are "just for show" if they don't really add to security.
2. 1Password's authentication mechanism is very atypical.

Let me start with (2), and then work back via (1) to talk about why such a seemingly simple adjustment isn't easy or really needed.

Authenticated key exchange

In most systems when you provide a password to a service, you are sending the password to the server, which then processes (hashes) the password and compares the hash to what the server has stored. That traditional password system is deal simple, but it isn't what we do. One (of many) problems with that traditional system are that the server learns the user's secret (the password) even if the server throws it away (and only keeps the hash), it still has the opportunity to learn the user's password. We don't want to have the capacity to learn your master password.

Anyway, 1Password uses SRP, a Password Authenticated Key Exchange protocol, which solves that problem (along with others). You can read about it, and the rationale for it, in 1Password is layered up with modern authentication, but the over all point is that despite appearances, you never send your master password to our servers.

SRP doesn't just prove to the server that you know your Master Password (client authentication), it does other things as well, including deriving session key. A by-product (well, it's really all by design) of the client and the server proving their identity to each other is a session key. That session key is used as a third (well, actually the middle) layer of encryption for the communication between your client (web browser or 1Password native app) and the server. There is a tight binding between the authentication process and some of the encryption that is used to transmit messages back and forth.

So it is hard to actually go through a "new" authentication process without starting a new session. But that new session wouldn't really have the delete instructions. This isn't insurmountable, but it allows for requests from one session to be fed into another, which reduces some of the defenses built into sessions.

The simple way

The simple way we could do this would be to have your client check that you have entered the correct Master Password and then just tell the server that you have done so. But that is not a trustworthy system. A malicious client could simply tell the server that you correctly entered the Master Password even if you didn't, and the server would have no way to know. So such a mechanism would only provide the appearance of a real security check. But see point (1).

It's not impossible

It isn't impossible to get what you want in a meaningful way, but it isn't simple. And the attacker who can get at your logged in 1Password session can do much more damage (dumping local memory with encryption keys), that on balance we haven't built the mechanisms to do that kind of second authentication you want in a way that is secure and meaningful.

So we will keep it in mind. But I did want to let you know that you've actually hit upon a subtle point. In short, our way of doing authentication is much much more secure than the "traditional" way, but it means that some features available to more traditional authentication aren't easily available.

Budgieee

@jpgoldberg I don't get it then, correct me if I am wrong, but how does it then perform the second verification for when you want to get a new secret key, or enable 2FA?

jpgoldberg

I don't get it then, correct me if I am wrong, but how does it then perform the second verification for when you want to get a new secret key, or enable 2FA?

Well spotted, @Budgieee! I forgot that we do that for setting up 2FA. Yes, we could do this the same way. I will need to check whether we do those the hard way or not.

For generating a new Secret Key or Master Password change, it is done the "hard way" because it has to be. But turning 2FA on or off doesn't require any cryptography in and of itself once you have an authenticated session. It is merely an instruction to the server.

rob

To clarify a bit, @Budgieee, for the Secret Key change, the main reason we ask for the MP is that both are used to derive your Master Unlock Key. Since we don’t keep your Master Password around after you sign in, we have to ask for it again so that we can derive the new key. We check on the client to make sure that you don’t accidentally enter it wrong and end up changing your MP, but there is no authentication check on the server to make sure that your MP is correct. (Yes we can check that your MP is correct on the client without knowing what it is. Mathemagics.)

As for 2FA, you’ve correctly spotted a place where we ask for the MP on the client without doing meaningful server authentication. We don’t like to do that as Jeff mentioned, but in this case we did. We could add a similar check before deleting the account. I’m not sure if we will.

Jeff’s points still stand though:

• A savvy attacker could avoid the client interface and delete the account anyway as long as there was an active session.
• They could do much worse than delete the account.
• We have backups, so this attack would not really be effective.