Time-limited tokens

registry
security

(Espen Hovlandsdal) #1

As @iarna outlined in this issue:

I was chatting about this with Ceej today and we may have an alternative and much easier to implement solution for you all:

Time-limited tokens. You could create an access token for the purposes of publication that does not require 2fa and is valid for the next 5 or 10 minutes. Then use that during the various publications.

Creating the token would require 2fa, but using it would not. And it would auto-delete itself after it times out.

This would be a great feature for monorepos managed through lerna and similar, since you’ll want to publish a potentially large number of packages, which might cause the 2FA to time out during the process.

I also requested a feature to enable 2FA on a package level; if this is implemented, it would be great if time-limited tokens could somehow be an exception to this rule. Basically; if I try to publish a single module using npm publish, require me to verify my npm token with 2FA, but if I want to publish many packages, allow me to create a time-limited token using 2FA and publish all the packages with that token.


2FA "sessions" to make it easier to publish multiple packages at once
(Daniel Stockman) #2

Time-limited tokens that could be generated from a lerna publish 2FA prompt would be sweet. “Pack first, publish tarball second” is still a flow I want to implement in lerna, mostly for error handling and validation/reporting reasons.


(Teddy Katz) #3

Our release process is to start a build process on a Jenkins server and optionally input some parameters, then wait about 10 minutes while the server clones the project, runs the tests, and publishes automatically.

Given the 10-minute delay between entering input and a package getting published, it would be difficult to use the existing TOTP 2FA solution for the bot account on the server, since the token entered by a human at the start of the build would no longer be valid when it was time to publish. (This could theoretically be worked around by having the human enter a TOTP token computed for a specified time in the future, but I don’t know of a convenient way to with any popular authenticator apps.) So having a time-limited access token would be very useful for this case. (The server could accept a TOTP code as a parameter from the human, immediately use the code to get a temporary access token, then continue running the tests and use the temporary access token to publish.) It would be nice if the expiration time was slightly longer than “5 or 10 minutes” to ensure that it’s possible to finish running the tests before the token expires.


(Rebecca Turner) #4

I’ve heard 30 minutes floated. it’s also possible that it will be configurable.


Allow subset of tokens to bypass 2FA requirement
(Daniel Stockman) #5

npm profile seems to be the way to figure out whether or not a user needs an OTP before attempting to publish a (potentially) long list of packed tarballs…

$ npm profile get --json | json tfa.mode
auth-and-writes

…how would that work on a per-package basis?


(Kat Marchán) #6

@evocateur idk when this’ll happen but we might be adding information to the packuments saying as much. It’ll just get time to put that in place.


(Daniel Stockman) #7

That makes sense, thanks for the speedy reply. :slight_smile:


(Daniel Stockman) #8

So I’ve implemented the “pack first, publish later” flow in the latest major release of lerna (v3.0.0, finally out of prerelease). I’ve released patches almost every day this week (haha woo…), but the 2FA branch is largely done (pending tests :sweat_smile:).


(Espen Hovlandsdal) #9

That is fantastic to hear! Thanks so much for your hard work <3


(Teddy Katz) #10

Is this feature something that’s planned to be implemented in the near future? The ESLint team is trying to determine whether it would be worth making changes to our release infrastructure to work with the current 2FA option, or if we should just wait for time-limited tokens to be implemented (which would make things simpler to integrate on our end).

It’s certainly understandable if this feature isn’t on a roadmap – I’m just trying to figure out its status so that we can make a more informed decision on how best to integrate 2FA with our infrastructure.