Feature request: passphrase protection of a secret

[mshedsilegx]

I would be a welcome addition for the secret sender to be able to passphrase protect a secret. Similar to the below:

For the recipient, the secret could not be access without entering the correct passphrase:

I think that provides another layer of protection that is useful in several test cases.

[Luzifer]

Please go into more detail how this increases security over the current measures:

• The secret is encrypted with a random password using AES 256bit
• The secret is assigned a random UUID
• The secret URL basically isn't guessable and even if someone guesses it, they only can retrieve the encrypted secret they need to obtain the random password for

So what's the benefit of placing a plain text password on the already strongly encrypted secret?

[mshedsilegx]

That would add an additional protection if the OTS link has been forwarded incorrectly or compromised

[Luzifer]

• "forwarded incorrectly": Just click the link and burn it yourself, create a new one and send it the right way
• "compromised": The original recipient will notice and you need to revoke the secret…

TBH: 99.99% of the users will either omit this or send the password the same way the link was sent. Most likely in the same message. Is the complexity really worth it?

Also the example screenhots you provided: They are sending the secret and the password in plain text to the server and are calling that "secure" and "secret"… They are not a reference.

So how would this work? The secret is encrypted with a random password and sent to the server as currently. What's happening to the password?

• Is it in the encrypted content? So is the secret fetched, decrypted and then the user is asked for the secret to display the secret? The secret is already available in-mem. (Security: Zero.)
• Is it stored outside the encrypted content? If so what does it do? The decryption key is available in the URL. Does the backend need to get it in plain text to know whether the secret might be fetched? That's a breaking change: Previously stored secrets do have another format. (Or needs another migration code.)
• Will the secret be tried to fetch and the server exposes the secret exists but does not deliver it instead asks the frontend to provide the password? That's hell to implement in 3rd-party-clients. Also it exposes the secret does exist. Does the server just respond 404 as if it does not exist? Means the user must always be provided with a password field even though the secret does not have a password.

I'm not convinced this is a useful addition. It makes stuff a lot more complex, in certain ways of implementing it, it will expose information which shouldn't be there. In other ways it violates the "zero knowledge" principle in the backend by making i.e. the password known to the backend.

[mshedsilegx]

OK, let's close this