2 ms·

Correct me if I'm wrong, but: doesn't this involve sharing your credentials with a third-party service? I have no reason to doubt Step Security's motives here,

Correct me if I'm wrong, but: doesn't this involve sharing your credentials with a third-party service? I have no reason to doubt Step Security's motives here, but one of the examples involves plumbing a TOTP code through their webservice, which isn't ideal. (Manual intervention seems like a very reasonable thing to want! But perhaps it makes sense to leave the package index's secrets out of the round-trip, and limit the secret to something known by only the publisher and the "gatekeeping" service.)

crazysim 4y ago
Maybe there's a way to have a secret in GitHub actions that can decrypt the browser-side-encrypted code.
- woodruffw 4y ago
  They could probably do something like that, but you'd still be putting your credential into an input form on a third-party service and counting on that service to encrypt it. The more concerning part to me is that, even with the best of intentions, this flow is completely indistinguishable from the TOTP phishing flow that we try to train users to avoid.
  - varunsharma07 4y ago
    w.r.t phishing: a maintainer intends to publish a release, will go to their GitHub Actions build log, and will click the link in the build log. So it is not a typical phishing scenario where one gets an email without context and clicks the link. Please let me know if I am missing something. There are also ideas about using a phone app and/or a CLI related to end-to-end encryption https://github.com/step-security/wait-for-secrets/issues/56 https://github.com/step-security/wait-for-secrets/issues/56.
hk1337 4y ago
Seems like there could be better options than requiring MFA for publishing. Like, maybe publish it to a pending state so CI can automate it then require a human to login and approve it?
- woodruffw 4y ago
  Yeah, I think a pending state is probably more ideal here. But I could see that being a little bit of a lift. (I'm still not 100% clear on the security advantages of requiring MFA for API tokens that are limited in scope -- assuming that NPM's tokens don't serve as full user credentials, I don't think they should enforce MFA on them.)

crazysim 4y ago

Maybe there's a way to have a secret in GitHub actions that can decrypt the browser-side-encrypted code.

woodruffw 4y ago
They could probably do something like that, but you'd still be putting your credential into an input form on a third-party service and counting on that service to encrypt it. The more concerning part to me is that, even with the best of intentions, this flow is completely indistinguishable from the TOTP phishing flow that we try to train users to avoid.
- varunsharma07 4y ago
  w.r.t phishing: a maintainer intends to publish a release, will go to their GitHub Actions build log, and will click the link in the build log. So it is not a typical phishing scenario where one gets an email without context and clicks the link. Please let me know if I am missing something. There are also ideas about using a phone app and/or a CLI related to end-to-end encryption https://github.com/step-security/wait-for-secrets/issues/56 https://github.com/step-security/wait-for-secrets/issues/56.

hk1337 4y ago

Seems like there could be better options than requiring MFA for publishing. Like, maybe publish it to a pending state so CI can automate it then require a human to login and approve it?

woodruffw 4y ago
Yeah, I think a pending state is probably more ideal here. But I could see that being a little bit of a lift. (I'm still not 100% clear on the security advantages of requiring MFA for API tokens that are limited in scope -- assuming that NPM's tokens don't serve as full user credentials, I don't think they should enforce MFA on them.)