Feature Request: 2 Factor Auth

[simcop2387]

Given a number of high profile software repositories being hit by malicious uploads/replacements of libraries lately. It'd be a good idea to think about adding two factor auth to PAUSE so that reused passwords or stolen credentials aren't usable to put malicious uploads on PAUSE.

It'd have to be per account to enable it, and likely also require new or updated tooling for authoring modules to support it fully, but there could be some work arounds for older tooling to enable them to work with it even without changes.

I've commonly seen $password . $twofactortoken (concatenate the two) used in these kinds of places to handle older clients (amazon does this in some situations with older mobile clients or even smart tvs) so that they don't have to add a new auth method in the older clients that don't already support it. The way to do this would be to take the last 6 or 8 fixed characters (if totp) off the end of the password and assume they're the 2fa token and try the password and 2fa tokens that way.

I'd also suspect that we'd want to support multiple 2fa tokens on a pause account, for both recovery of the account and because you may not have some device with the token available all the time.

Possible algorithms for this

1. TOTP - Pretty much the standard for doing this kind of thing, multiple modules already exist to handle them
2. U2F - Pretty much focused on browsers and websites from what I can tell, https://en.wikipedia.org/wiki/Universal_2nd_Factor developed by google and yubico they have however
3. HOTP - Also has many modules for doing this already, but tokens are made in sequence. Phishing or otherwise sniffing them can lead to them being stolen and still useful to an attacker. But hardware devices capable of producing them are cheaper since they don't need batteries for clocks.

Pros:

• Better security for preventing malicious uploads. Not perfect (no package signing or other things in place) but better.
• Will be more likely to prevent accidental uploads since it ends up requiring another step to upload
• Releases could get metadata saying it was uploaded with 2fa enabled, giving someone more confidence that the release was intended by the author.
• Combined with PAUSEs existing security that prevents another author from taking over a module and it's namespace, this would likely provide decent protect against most malicious drive by installs from packages too.

Cons:

• Since it couldn't be required on all accounts, it only helps security for ones that enable it
• Will be more likely to prevent purposeful uploads since it ends up requiring another step to upload
• More infrastructure to support and maintain on the PAUSE side of things.

[simcop2387]

The recent attacks:

https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes https://wiki.gentoo.org/wiki/Project:Infrastructure/Incident_Reports/2018-06-28_Github

[Grinnz]

Really the only tooling that would need to be updated is CPAN::Uploader/CPAN::Uploader::Tiny and the PAUSE site authentication itself. Unfortunately since it doesn't use oauth this probably means that rt.cpan.org and metacpan will need to update how they authenticate PAUSE users as well.

[simcop2387]

There's been more compromises since, here's another new one.

https://github.com/rest-client/rest-client/issues/713

[simcop2387]

They investigated and found 10 more affected libraries, https://github.com/rubygems/rubygems.org/issues/2097

[oalders]

The MetaCPAN auth is essentially sending an email to the PAUSE address, so setting up 2FA here wouldn't require a change on the MetaCPAN side of things. Maybe an Auth0 integration would be an easy way to do this?

[simcop2387]

It might be a good option. I'm working on a TOTP implementation simply because I expect it'll be enough to force the conversation into a serious place (It's been a low priority for everyone, including me). I don't know much about Auth0 but I expect that a number of our more curmudgeonly members will not want to give any information to a third party if they can help it. At the very least maybe this'll help start an implementation of more flexible auth in PAUSE.