5 ms·

So when I saw people using onetimesecret.com to share sensitive credentials at work (this is a free tool hosted by a third party that IMHO there was no reason t

by yebyen 6y ago

So when I saw people using onetimesecret.com to share sensitive credentials at work (this is a free tool hosted by a third party that IMHO there was no reason to believe is trustworthy) I was a little bit taken aback, because to me this seemed only marginally better than putting the password in an email, and in many ways potentially much worse. 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 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 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.)

some_furry 6y ago
https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L173-L176 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... I really wouldn't trust that KDF.
- folli 6y ago
  Absolute layman here. Care to elaborate?
  - some_furry 6y ago
    Sorry, I don't know how to best ELI5 the problem space as well as I probably should. 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.
    - zxcmx 6y ago
      This looks fine to me? 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?
      - some_furry 6y ago
        That's the ticket though: I suspect the entropy is really bad. This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L110-L115 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L160-L172 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime.rb#L53 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L11 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.
mathie25 6y ago
We are using a hosted version of onetimesecret for internal usage. 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.
- stephenr 6y ago
  ... aren't you then sharing it with the Slack (the service, not the room) too?

by yebyen 6y ago

some_furry 6y ago

https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L173-L176 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... I really wouldn't trust that KDF.

folli 6y ago
Absolute layman here. Care to elaborate?
- some_furry 6y ago
  Sorry, I don't know how to best ELI5 the problem space as well as I probably should. 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.
  - zxcmx 6y ago
    This looks fine to me? 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?
    - some_furry 6y ago
      That's the ticket though: I suspect the entropy is really bad. This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L110-L115 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L160-L172 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime.rb#L53 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L11 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.

mathie25 6y ago

We are using a hosted version of onetimesecret for internal usage. 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.

stephenr 6y ago
... aren't you then sharing it with the Slack (the service, not the room) too?