Closed jeroenvisser101 closed 5 years ago
We have talked about this a little bit in the past but never really had the time to think it through. Before we say yes or no I'd like to see a plan for what it would look like and how it would work.
FWIW, as a user, I would prefer Google Authenticator, because I already have it installed.
@dwradcliffe – totally, I'll work on mockups and a specification of how it would work (flowchart maybe?)
@nateberkopec – absolutely, scannable QR codes will most certainly be part of this, since Authy, Google Authenticator but also 1Password use this and it has become the industry standard (or so I believe). Thanks for the input!
Hey, even though this is super cool, I don't think I have the time that I need to invest in this. I'll leave this open for anyone to pick up.
@dwradcliffe I would love to work on this feature. You said something about wanting to see some things before implementation works get started. Can you elaborate what type of things you would like to see?
Hi! I asked for some input on this, since it was brought up on Twitter again.
I don't have any expertise in this area, but I'm happy to help put a plan together for it.
Some thoughts from @indirect:
Miscellaneous notes from discussion with @indirect and @evanphx:
gem push
is very important, because most authenticated access to rubygems.org is publishing gems.
gem push
would impact how Bundler's rake release
works
gem login
.
gem push
would be building a new workflow around using SSH public keys.
npm added 2FA recently, so I talked to @iarna about how npm approached it!
npm-otp
HTTP header.
WWW-Authentication
header containing OTP
.WWW-Authenticate
header and if it contains OTP
.
b. If it does, it either instructs the user run the command again with --otp=####
, or prompts them for the OTP interactively. (Varies depending on which command.)otpauth
URL, in the form of otpauth://?secret=<SECRET>
, to the client.otpauth
URL to a library that handles that.Note: otpauth
urls can have more stuff in them, and it's worth seeing if any of that would be useful.
It was originally developed as a standalone client, then moved into npm later on.
Here's the general flow for how their library is used:
profile.set({tfa: {password, mode}})
profile.set({tfa: [otp]})
gem owner
command.I have used npm's fully command-line 2fa flow, and it was pretty good. I would be okay with ending up somewhere similar. I also like the idea of 2fa only for login or 2fa for login/push/owner actions.
Hello everyone, I'm planning to apply this as a Google Summer of Code project. For the workflow, I have an idea that the authentication should have three levels:
gem push
or gem owner --add
, gem owner --remove
Will this be too complicated? And npm's two-level also works fine.
Also, as @duckinator pointed out, change token mechanism to JWT is nice. Maybe I can start from here. But what will be the result of incompatibility with old client that does not support JWT?
Anyway, I'll look for a good solution for OTP generating and create a mock site for feature test.
@ecnelises did this end up going anywhere? :)
devise-two-factor is used in GitLab, I’m not sure if that’s still the best solution but it seemed like it was when it was added ~two years ago. Also I’m not sure if RubyGems.org even uses devise in the first place.
https://github.com/tinfoil/devise-two-factor
Houdini might also be an option, but it’s not a super active project either: https://github.com/Houdini/two_factor_authentication
@connorshea Thanks for your notification.
But RubyGems.org doesn't have dependency with Devise. Instead, it uses Clearance, a simple library for rails application use authentication by email and password. (Occasion for RubyGems.org is not complex. It's much simpler than GitLab, using devise may be a burden)
I also checked the both library for 2FA, both depends on Devise and ROTP which is the real logic for OTP generation. To keep things simple, I think just use it is a good idea.
Have you been able to make any progress on this, @ecnelises? After today's NPM fiasco, this (missing) feature immediately jumped to mind.
I've not contributed to this project before, but would be happy to help get this shipped.
Also, FWIW, I'd vote for Google Authenticator or Authy.
If the 2FA feature uses the standard TOTP algorithm it should support both Google Authenticator and Authy out of the box as far as I understand.
@ethagnawl also, see #1725, #1729, and #1753. Looks like this is well on its way :)
@ethagnawl Some of them are finished and deployed. If you are interested in it, just add a cookie using JavaScript console document.cookie='mfa_feature=true;path=/'
when visiting rubygems.org. You can now turn it on for login, but please be sure to keep the recovery codes well :) We now hide it by cookie because it has not been totally completed.
@connorshea Thank you :)
@connorshea @ecnelises Excellent! Thanks for the prompt replies and your efforts on this issue!
If the 2FA feature uses the standard TOTP algorithm it should support both Google Authenticator and Authy out of the box as far as I understand.
@connorshea it'll support most any authenticator. Google Auth, Authy, 1Password, LastPass, pretty much any other generator that implements it.
Sorry to jump in here, but I'm trying to use OTP and rake release
now just hangs. What do I need to do? Can we improve the documentation to explain some of the basics? Is this a bug?
Thank you pointing out @ioquatix. We are going to track this issue here https://github.com/bundler/bundler/issues/6854
Since this is (at least partially) implemented, I'm going to close the RFC.
Incase anyone googles their way to @ethagnawl 's comment, you don't have to mess with cookies anymore.
The Rubygems UI provides a "Multifactor Authentication" section on https://rubygems.org/profile/edit
Is this something you guys would like to get a PR for? I'd be willing to invest some time and see if I can get it to work with clearance?