Multiple feature requests

[fblz]

Hi, I evaluated several password-sharing tools for my company and found OTS to be one of the best :)
However, I have some requirements that OTS does not currently meet, and I wanted to discuss the possibility of working together to implement solutions for these requirements in OTS.

I believe the easiest way to proceed is to outline what I see as missing and the solutions I have in mind.

1. Redis credentials should not be exposed via environment variables.

Using environment variables for configuration does not provide a secure way to manage Redis credentials.
I propose implementing a configuration file to prevent credentials from being accessible through the environment.

2. The expiry settings on the web interface should be clearer.

The default expiry setting on the web interface was confusing for 12 out of 15 people I had test OTS.
They all asked what it was and were surprised that it represents the maximum value.
I propose adding new configuration options for this.
First, I would move the options available through the web interface into the configuration.
This way, the server operator can choose which values to show to the users.
Second, I would separate the maximum and default values for expiry.
The default for the web interface could either be a separate option or the first item in the list of available options.
The maximum value would become its own option, and all values in the list would be checked to be <= maximum at startup.
This way I can set a maximum of 72h, a default of 12h and show any value between 1 second and maximum to the users.
The new default can also be used for other consumers of the API.

3. The app should not be able to change the web interface at runtime.

To further enhance security, the app should not be able to modify the web interface at runtime.
This implies that the web interface is built upfront and served from a directory where the OTS service user does not have write permission.
Since it is already recommended to add HTTPS with a reverse proxy, that proxy can handle the files.
I propose implementing a new sub-command, 'build-web', into OTS that compiles and emits the static HTML into a directory.
This way, the operator can either call this manually when the static files need updating or automate it using systemd via a privileged execPreStart.
To reduce the frequency of updating static files, I would replace the call to /isWritable with a call to /config, which could emit the relevant dynamic data for the web interface to consume.
I would include at least the list of available expiry options from the configuration, and possibly a version so the frontend could know whether it is out of date.

4. Uploading needs an authorization system to control uploads.

It is recommended that people run their own instance of OTS to enhance security.
Since OTS is used to share logins, this will likely happen over the internet.
Therefore, in its current configuration, OTS will be accessible to everyone.
This exposes the operator to at least two risks.
First, illegitimate uploads.
Any open upload could be used to share copyrighted material or even worse content.
If this happens under the operator's domain or server, they could be held liable.
Second, phishing.
A link from an official domain can easily gain the trust of unsuspecting individuals.
Allowing anyone to create such links is a disaster waiting to happen.

To keep the software reasonably simple (and because it would suffice for my use case), I propose two changes.
First, an option to define a "trusted zone," such as an intranet or company IP range, from which it is possible to create OTS shares without further authentication.
Second, an option to create a "request-link" from within the trusted zone.
This request-link would allow anyone who receives it to create exactly one OTS share by including an API token inside the link that is burned on use, just like the secrets themselves.
This approach would allow only trusted people to freely upload secrets yet enable trusted people to request passwords from anyone else on the internet.
The web interface could disable the create option for people not coming from the trusted zone and not having a request-link, by a flag from the /config API mentioned above.

While I know my way around golang, I never touched a vue project. But if you are interested in those features, I'll google my way trought it.

[Luzifer]

First of all: Please - and I think I speak for every OSS project out there - create one issue for one request. This is just barely actable anymore and cannot be properly worked on. (As you seem to come from a corporate environment, like you would create one Jira ticket for one request.)

---

Using environment variables for configuration does not provide a secure way to manage Redis credentials.
I propose implementing a configuration file to prevent credentials from being accessible through the environment.

Please elaborate. Environment variables are an issue for systems with shared access, files are too. Environment variables will fall when the system is compromized, files will too. Environment variables can be injected by a wrapping process, files cannot.

So how would the security increase by writing the redis credentials into a file on disk in opposite to taking environment variables from a security store?

---

The expiry settings on the web interface should be clearer.

#153

---

The app should not be able to change the web interface at runtime.

OTS contains compiled-in assets. They cannot change during runtime. There is barely a difference between statically compiling the frontend and baking it into the binary and statically compiling the frontend and hosting it using the nginx. The second variant can be changed easier.

Aside if you really want to go that way: make generate, edit the index.html in the frontend directory, let nginx serve it at ots.yourdomain.com and pass through the /api to the Go application: You're done. I don't see the benefit as you will loose the customization feature but you can do that.

---

Uploading needs an authorization system to control uploads.

#92

This can be done through the isWritable endpoint. It can't be called, the frontend will not display the creation form. It can be called, the frontend will display the creation form. Limit it on the proxy you put in front of the instance by applying access-control to /api/isWritable and /api/create to only be useable by employees and nobody else can create secrets.

[fblz]

First of all: Please - and I think I speak for every OSS project out there - create one issue for one request. This is just barely actable anymore and cannot be properly worked on. (As you seem to come from a corporate environment, like you would create one Jira ticket for one request.)

I intended for this to be more of a discussion then a full on feature request. It doesn't have the technical dept for a feature request imo. I see that it can be cumbersome to manage. I will split this into distinct issues.

[fblz]

To add to that. I wanted to know whether you want those features in OTS at all, before opening issues. Discussion are not enabled on the repo, so I opted for a single issue instead.