I really wouldn't trust that KDF.
SHA256(x) is a hash function that transforms some string x (of any length) into a fixed size output.
SHA256(x) is deterministic. Every x maps to one 256-bit output.
SHA256(predictable junk) is going to look random, but will actually be predictable. This becomes security theater.
I mean the process of putting secrets in a web site is fraught, but:
a) KDFs in general are deterministic, not sure about your point here.
b) As long as you have sufficient input entropy, using SHA256 to mix some stuff down to key size is fine. You don't need a heavyweight KDF unless your input entropy is really bad.
File an issue if you're really sure, I guess?
This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
At no point is anything touching /dev/urandom, which is how cryptography keys should be generated.
(Additionally, HKDF-SHA-256 should be used for splitting a master key into multiple sub-keys.)
I don't know if I want to file an issue for this on Github or not. Usually when the crypto is this bad, there's a lot of cargo-culting and I don't have the emotional bandwidth to deal with a vim-crypt style debate.
I take it all back.
We mainly used it on Slack. We made a slash command (/secret) to easily share passwords on Slack.
So the only thing you need to do is write /secret YourPassword.
After that, you need to be authenticated via Google SSO as we added a proxy. Yes, we know, the password goes through Slack.
Then I realized, it's open source, and you can host your own instance if you want to trust onetimesecret a bit less:
https://github.com/onetimesecret/onetimesecret
Then I realized (further) there is a fork that has been containerized and prepped for use on OpenShift (and ostensibly Kubernetes upstream, as well?)
I have not set up my own hosted versions of these, but the fact that it's Open Source makes me feel hopeful that it should be trustworthy. And if you want to be lazy and don't run a hosted service, there is always the public version:
https://onetimesecret.com
Finally I realized, you can protect the exploding secret with a password, which I presume encrypts and decrypts in a localized context, in the browser (so data is not stored unsafely on onetimesecret's infrastructure in a way that it could be recovered by an adversary, without the shared secret at least, which granted could still be compromised.)
If it matters to you, you will need to verify all of that for yourself, but I think that all of those details are facts, (at least if I was onetimesecret I wouldn't have published the source unless all those things were true.)