Google Authenticator and NIST SP 800-63 version 3 (draft)

[friedpicker]

Hello, I have a few federal government agencies asking me about Google Authenticator and NIST SP 800-63 (E-Authentication / Digital Identity Guidelines). The current version of the spec is SP 800-63 version 2, but version 3 has been through the public comment period and is expected to come out soon. You can find it here: https://pages.nist.gov/800-63-3/sp800-63b.html

Version 3 lets you bind authenticators that the user already possesses to the users identity. Agencies are looking for secure and available second factors of authentication to bind to the identity (following their own identity proofing). So, the question becomes, does Google Authenticator meet the requirements of the spec for AAL 2? Then following that, how do we leverage it?

As far as I can tell, Google Authenticator would meet the requirements for a OTP authenticator (there are minor details to verify), so how would we use it? As far as I can tell, Google doesn't let third parties contact the Google Authenticator verifier/server with an ID and OTP code (that could be dangerous). So, I assume a federation protocol (OAuth or SAML). In this case, the relying party cares more about the type of authenticator that was used than it does Google's claimed identity. Does the token returned from by Google tell the relying party that Google Authenticator was used to authenticate? Can the token request force Google Authenticator to be used? If not, can those be considerations for the future?

Thanks! Terry McBride

[ThomasHabets]

I'm not sure what you're asking, but will try to answer.

First of all I'm not sure why you ask about a verifier/server. Are you talking about a communications protocol on the device itself with the GA app for other apps to use, or a Google service?

If the former: Why? If the latter: GA is not part of any Google service. GA just implements RFC4226 and RFC6238. There is no server to contact.

Does GA meet AAL 2? I'm not aware of the audit status of RFC4226 and/or RFC6238, nor familiar with AAL 2 definitions, or any requirements for implementation audits on top of that.

As far as I can tell, Google Authenticator would meet the requirements for a OTP authenticator (there are minor details to verify), so how would we use it?

Use it to do what?

I don't know how OAuth or SAML comes into this.

Does the token returned from by Google tell the relying party that Google Authenticator was used to authenticate?

No, the 6 digit code simply follows RFC4226/RFC6238 and could therefore come from any valid implementation of them. There's no metadata embedded in the code, and it's deterministic from the key plus the time (TOTP) or counter (HOTP).

If not, can those be considerations for the future?

I hope what I wrote makes it clear what GA is and can be. If not, please ask for clarification.

[friedpicker]

I think you've cleared up some misconceptions. Let me check my understanding. Google Authenticator is an implementation of a time or counter based OTP based on the RFCs you mentioned. Google Authenticator can be used with any service provider. The service provider shares a key that the user loads into Google Authenticator for accessing that service. There is no need for Google to be involved.

Is that right?

[ThomasHabets]

That's right.

I'm not sure what system you are working on, but I'd recommend looking at FIDO and U2F as your second factor, since U2F can't be sniffed or phished.

[friedpicker]

I appreciate that.

One of the main interests on the part of Federal agencies is that Google Authenticator is a free app. They need to move to 2-factor authentication but don't want to buy security keys for everyone in the U.S., nor do they want to make everyone buy one. Perhaps as adoption increases, it will become an option.

On May 10, 2017 1:41 PM, "Thomas Habets" notifications@github.com wrote:

That's right.

I'm not sure what system you are working on, but I'd recommend looking at FIDO and U2F as your second factor, since U2F can't be sniffed or phished.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/google-authenticator/issues/591#issuecomment-300559191, or mute the thread https://github.com/notifications/unsubscribe-auth/AbRxUCqRfolePiDXZaiTsyQ1WKm_drvWks5r4fbhgaJpZM4NW4s1 .

[ThomasHabets]

The way Google does it is to allow multiple options. That has its drawbacks too. I'm only saying this to point out the option of having this pluggable on the server side. Once you're prepared for two it's easier to add more or move/migrate.

Sounds like you have an interesting project there. I'm not aware of any app that produces a code that proves a certain implementation with OTP.

In Sweden there government agencies and banks have mostly unified behind "Mobile ID" or "Mobile bank ID". The workflow is that you browse to your bank (or the tax office, or some other agency), you enter your identity number (think "social security number"-ish), and then it tells you to open the Mobile ID app. That app then says "Agency X wants to log you in. Type your pin (in the app) to approve login".

The Mobile ID app is provisioned by you identifying yourself by some means with your bank.

I don't know the details of how it works, but could be worth looking into this solution. It'd probably be a bigger project than adding standardized OTP though.

You might want to contact https://www.bankid.com/en/ for details, if you're aiming to implement something to solve a similar problem.