Show HN: Publish from GitHub Actions using multi-factor authentication(github.com)
github.com
Show HN: Publish from GitHub Actions using multi-factor authentication
https://github.com/step-security/wait-for-secrets
28 comments
Have you considered adding some kind of encryption of the secrets with a preshared key generated inside the action to make the SaaS zero-knowledge? Currently it appears the service can read all the secrets in plaintext.
This is tangential to your comment and not a complaint - That isn't zero-knowledge that is end-to-end encryption.
I've been noticing a lot of marketing materials describe themselves as "zero-knowledge" when it's just E2EE.
I definitely agree it would be nice to have.
I've been noticing a lot of marketing materials describe themselves as "zero-knowledge" when it's just E2EE.
I definitely agree it would be nice to have.
Added an issue to track this: https://github.com/step-security/wait-for-secrets/issues/56
The backend API is open-source, and the secrets are cleared immediately after use from the data store, but I agree this is a good idea.
The backend API is open-source, and the secrets are cleared immediately after use from the data store, but I agree this is a good idea.
Congrats Varun :) Great to see my ex-roommate's post on HN front page.
Fun fact- Varun is a super smart engineer, he even won a car in a competition:
https://www.oneindia.com/2006/06/29/microsoft-security-shoot...
I would highly encourage HNers to try out his github action.
Fun fact- Varun is a super smart engineer, he even won a car in a competition:
https://www.oneindia.com/2006/06/29/microsoft-security-shoot...
I would highly encourage HNers to try out his github action.
Thanks, Gaurav :)!
Isn’t this what OAuth and OIDC supposed to handle?
Thank you for not wrapping this up in docker image. Unless there’s a specific purpose for it, those kind of actions are annoying to use.
EDIT also, kudos to putting a version on it. An action dealing with authentication and telling you to use it with “@master” is suspect, IMO.
Thank you for not wrapping this up in docker image. Unless there’s a specific purpose for it, those kind of actions are annoying to use.
EDIT also, kudos to putting a version on it. An action dealing with authentication and telling you to use it with “@master” is suspect, IMO.
Yes, pretty much. The advantage to something like OIDC is that it requires virtually no trust except the trust already established: you trust GitHub to host your code and NPM (or whoever) to publish it; OIDC allows GitHub to share a machine identity that NPM can verify and grant publishing rights to (e.g. via a temporary API token).
The downside to that approach is that it requires the consuming side (NPM in this case) to understand and verify OIDC tokens (which are really just JWTs). But we're currently working on exactly that on PyPI, and hopefully other package ecosystems will follow our progress there.
The downside to that approach is that it requires the consuming side (NPM in this case) to understand and verify OIDC tokens (which are really just JWTs). But we're currently working on exactly that on PyPI, and hopefully other package ecosystems will follow our progress there.
OIDC that is a good alternative. This GitHub Action uses OIDC to authenticate the workflow to confirm secrets are only given to the authorized job.
The differences between OIDC and MFA for publishing credentials are:
1) More control: each release gets gated by human intervention, requiring MFA to publish.
2) Separation of duties: Just because one has "write" access to the code/ workflow does not automatically permit them to publish.
3) Less management overhead: With MFA, there is no need to set up OIDC trust policies (which need to be configured accurately). This removes the need to manage a separate set of deployment credentials/ policies.
Versions don't matter in GitHub actions; it takes "Tags" as the highest priority, which maintainers can update at will. Yes, they have to delete the tag first, but there's a UI button for that. Yes, anyone who's cloned the repo will receive a warning, but have you ever cloned an external GitHub actions repo?
Advice to use external GitHub actions, especially security actions, should pin to a sha instead.
Advice to use external GitHub actions, especially security actions, should pin to a sha instead.
That's good advice. My biggest issue were when examples show using the action as `my-action@master`.
npm doesn’t offer these things, so it’s not a useful comparison.
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.)
(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.)
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?
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.)
(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.)
Maybe there's a way to have a secret in GitHub actions that can decrypt the browser-side-encrypted code.
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.
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.
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.
TIL GitHub Actions doesn’t have an MFA gating function. Great work with this! Hopefully some Hubbers see this and let a PO know :)
Anyone have recommendations for a server-push authentication thingy similar to Microsoft Authenticator? On sign-in to an Office365 site, MSA will prompt you on your phone's app to authorize the login. I want the same thing but self-hosted & open source. Any suggestions?
Maybe https://ntfy.sh ? It's a generic pub/sub tool that can provide a clickable link on a mobile app back to a service.
It's covers the "self-hosted & open source" but it's not specifically an authentication thingy, so you would have to generate the auth factor to push and the service that verifies it, like a web hook.
It's covers the "self-hosted & open source" but it's not specifically an authentication thingy, so you would have to generate the auth factor to push and the service that verifies it, like a web hook.
[deleted]
I wish there were more work done in that area.
I seem to recall someone using ephemeral Tailscale nodes in CI to respond to a hardware token challenge locally but I can't find where that was.
I seem to recall someone using ephemeral Tailscale nodes in CI to respond to a hardware token challenge locally but I can't find where that was.
It would be cool to see an oauth extension of this: run a github action permissioned as a user.
To release the wait-for-secrets Action, I run the workflow using a PAT sent in via the browser. In that sense, it is similar to what you mentioned. I create the PAT during the release process and delete it after the release is done.
I have added an issue to track your idea: https://github.com/step-security/wait-for-secrets/issues/57. It would be interesting to run as the current user using OAuth, but it will need more thinking.
I have added an issue to track your idea: https://github.com/step-security/wait-for-secrets/issues/57. It would be interesting to run as the current user using OAuth, but it will need more thinking.
This is super sweet! I dig that you can do this from the workflow itself
Yes. The workflow blocks and prints a URL every 10 seconds. The developer can click on the link and enter secrets in the browser. The workflow then continues, and secrets can be used in future steps.
Wow.
[deleted]
I discussed with an open-source maintainer why they publish npm packages from their local machine and do not use CI/CD pipelines.
They said publishing should require human intervention and want to continue using multi-factor authentication to publish to the npm registry.
This led to building the wait-for-secrets GitHub Action. It prints a URL in the build log and waits for secrets to be entered using a browser. Once entered, the workflow continues, and secrets can be used in future steps.
The latest release of "eslint-plugin-react" to the npm registry used a one-time password (OTP) from a GitHub Actions workflow! https://github.com/jsx-eslint/eslint-plugin-react/actions/ru...