search

keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
900 stars 37 forks source link

Feature request: Google authenticator support for (website) login #798

Open netchild opened 10 years ago

netchild commented 10 years ago

Website Login via google authenticator (PW still valid as fallback) -> goal: login on the road via google authenticator, but have the PW as a fallback when the authenticator is stolen / battery empty / not at hand or to login via commandline (optional: disable PW login and rely only on the authenticator)

zQueal commented 10 years ago

This has been discussed before, and Authy has been chosen over other 2 factor authentication applications -- not sure if the authy backend will work with Google Authenticator, however, we're not sure when we'll see this implemented.

thonixx commented 10 years ago

If you have the Google Authenticator QR code, you will be able to add it to Authy too. It is cross-compatible. Maybe this would make things easier?

chucksense commented 9 years ago

I, for one, would prefer Google Authenticator. Trying to move away from having multiple 2-factor tools on my device and more services support Google over Authy.

ghost commented 9 years ago

I decided once against Authy because I read it stores the key for the code generation online so that you can restore them in case of a stolen smartphone. (I have to confess, I didn't search if this can be deactivated). Regarding the implementation: Both Google Authenticator and Authy use the same standard (as does Battle.net Authenticator on a random note), but Google limited its implemetation to a 6 digit code while the standard (and Authy) support the whole range of 4-8 digits.

Since the code is only used additional to a password, and not instead one (see also the implementation details here 6 digits is secure enough. Therefore 6 digits should be the best choice. This way the user (him|her)self can choose which app to trust the most.

grawity commented 9 years ago

It is confusing when people talk about Google vs Authy vs... while the end result is going to be the same – you can import the OTP secret into any app as long as Keybase uses the default parameters (6 digits, 30 seconds). In fact, if one is going to suggest a specific app, I recommend FreeOTP by Red Hat.

(It is very unfortunate that the huge majority of those apps have those values hardcoded and do not allow e.g. 8 digits for Battle.Net secrets. (FreeOTP is a nice exception – not to mention being an open-source project.) But, that's not a problem in practice; proper rate limiting makes even 6-digit OTPs impossible to guess.)

@netchild, I suggest renaming this to "Feature request: OATH-TOTP support".

@zQueal, which mode of using Authy was chosen? Was it the standalone mode using imported Qr code (like all other authenticator apps), or did Keybase decide to use the Authy API instead? (On the one hand, relying on Authy API isn't really worse than relying on Yubico API. But on the other hand, it differs from a yubikey in that Authy's app lets you recover your API-based tokens using nothing more but your phone number...)

zQueal commented 9 years ago

which mode of using Authy was chosen?

Looking back, I shouldn't have really said it this way. I tried to search, but I was unable to find it, however, I remember either @maxtaco or @malgorithms saying that Authy looked to be the direction that they were heading for OTP.

tycho commented 8 years ago

Gravedigging this issue a bit, but I would really like to see this implemented.

And to add my two cents: I don't trust Authy because using it means that my TOTP private key is in the hands of a third party. I reluctantly use Authy only in places where not doing so isn't an option. I don't doubt Authy does a great job, but I would prefer that the private key only be in my hands and in the backend that is verifying the TOTP value.