An option to require all pastes to be protected with a password

[zaytsevand]

The problem

Our company's policy requires all secrets to be split in two and then passed by two independent communication channels. Usually, this is an email for a link to a secret and a messenger app for the secret's password.

The solution

Add an option to require all pastes to be protected with a password.

Alternatives

Change the current password option from boolean [true, false] to [true, required, false], with required meaning that all pastes will require a password.

Additional context

It would also be highly helpful to support an SSO integration that would use an email field to send a link automatically, without any manual actions, even not revealing it to the person who created a paste.

[elrido]

My 5¢:

1. The server is agnostic to the password, so even if we were to add a way to force the web UI to always require a password, users can still create pastes without a password on your server, via a third party client or such.
2. Integrating SSO into privatebin itself is out of scope, because privatebin was deliberately designed not to have a concept of named users. All requests work anonymously and we only distinguish between creators, readers and deleters (which submit a valid delete token). See also the threat model which may clarify how this is done and why.
3. BUT you can totally use SSO on your webserver (apache mod LDAP, nginx, HA proxy, etc.) to ensure only authenticated users can use your privatebin instance. There is also a guide on the wiki on how to only protect part of your privatebin instance for nginx, the same principles should work with other servers.
4. It really sounds to me like this is part of a specialized workflow, not a generic privatebin use case. It might make more sense for you to use one of the third party clients (see link above) inside of a script to generate those secrets plus (random?) password, create a privatebin paste from it and email the link (and password, if a random one was generated) to the recipient. It would not be too complicated to turn this into a little PHP or CGI script, so you can fill a web-form in a browser to trigger this process when submitting the form.

All of that said, of course I would consider working with anyone that would submit a PR for such (a) feature(s).

[zaytsevand]

Thanks for the clarification! I wasn't aware that the server itself is not configurable that way.