U2F support over NFC

arnoudius · June 17, 2019, 11:24am

Would be really nice if this could be added to the Android app.

patent · August 7, 2019, 4:51am

It sounds like U2F support needs to move over to the WebAuthn API now that the w3c has approved it. It seems like this change should also solve the problem of both NFC and plug-in key support via OTG adapter for the mobile app as well, no? Fido2ApiClient seems to be aimed squarely at native apps.

Right now the user experience with entry-level, U2F-only keys like Yubico’s Security Keys (NFC or no), Solo, Google Titan, etc. is that enabling U2F on desktop - something we can probably all agree is a really good idea - prevents you from using anything mobile to access your vault. This isn’t acceptable under any circumstance but especially not when U2F support is a premium feature. The mobile login workaround you described requiring users to either (briefly and tediously) create a non-multi-factor backdoor to their account or else go replace all their tokens to get more-expensive and less-secure OTP capability really doesn’t seem satisfactory.

nickray · August 14, 2019, 8:30pm

Nicolas from SoloKeys here. Naturally we support this! FIDO2 passwordless would be a great user experience (need to have key, need to know PIN), especially on mobile where it’s not so easy to type a long / actually safe master password to unlock. Let us know if we can help, I think Bitwarden would be the first PW manager to have FIDO2 on mobile (whether as 2nd factor or passwordless) if it were implemented

OpSec · October 1, 2019, 1:18am

Nicolas,

If only BW would accept your help and do this!!

8Yb76M5 · November 26, 2019, 9:43pm

It seems to be well documented in the android documentation:

API: https://developers.google.com/identity/fido/android/native-apps#integration

Example: https://github.com/android/security-samples/tree/master/Fido

It would be awesome to have a working implementation of Bitwarden’s FIDO auth on Android devices

muteki · November 26, 2019, 9:56pm

Please implement this. U2F support is one of the main reasons why I moved from Lastpass to Bitwarden. Adding it to Android would make the experience perfect!

Mastacheata · November 27, 2019, 1:36am

Hello 8Yb76M5,

#1 What you’re pointing at is about the newer FIDO2 Standard. Android doesn’t have any native wrapper for U2F. You would need to implement both the communications part via NDEF-Type-Tags and the cryptography stuff by hand for that.

#2 The Java examples are nice, but don’t really help if Xamarin doesn’t expose the new FIDO2 API yet. The Bitwarden client is written in C# using the Xamarin Framework for platform-independency.

Apple has finally opened up their NFC interface for others lately as well and is now allowing iPhone owners to use it for FIDO2 Security Keys as well. Not sure if Xamarin has exposed the official APIs from Apple yet, though.

8Yb76M5 · November 27, 2019, 5:42am

Hello @Mastacheata,

I see, thank you for you reply.
I didn’t know that Bitwarden uses Xamarin

However, are you sure that android doesn’t have any wrapper for U2F?
https://developers.google.com/android/reference/com/google/android/gms/fido/u2f/U2fApiClient

It’s possible to sign in to the google account using U2F:
https://support.google.com/accounts/answer/6103523/

I don’t know Xamarin, but there are closed issues about Xamarin and FIDO integration in android:

Mastacheata · November 29, 2019, 2:21pm

Hmm, seems like you’re right and my information is outdated.
I was 100% sure the Android FIDO namespace was only for FIDO2, but apparently it has U2F-Support as well.

And Xamarin finally picked up the pace and submitted a wrapper around the android library as well. Fido2 support is still pretty new, but U2F seems to be implemented in the old 60.x version as well. (60.x is the version of the other Android/GooglePlayService Libraries already used by the Bitwarden-Mobile app.

I’m currently looking into the code and will try to implement the U2F part.

8Yb76M5 · November 29, 2019, 2:35pm

I think I fell in love. Thank you for your work

Mastacheata · November 29, 2019, 11:00pm

Hold your horses:
What I learned in 1 workday of playing around with bitwarden mobile:

There are no comments at all inside the code.
There are some stubs for U2F, but the server doesn’t yet have FIDO2
The Xamarin FIDO bindings package that is compatible with the other packages used in the mobile app is actually the Fitness-Bindings package. They noticed that error in late 2018, but never shipped a fixed package.
You can’t get Bitwarden mobile to build in VS2017
To Microsoft you are not a business unless you have at least 250 employees

8Yb76M5 · November 30, 2019, 10:41am

I see. Maybe it could be easier for someone familiar with the codebase.
Did you find any xamarin documentation about the fido integration?

I remember reading a post on Reddit where Kyle explained the reason of the missing U2F auth on android was the lack of support by xamarin.
Maybe now that it is possible to get it working, at least in theory, he’s interested in implementing it.

@kspearrin ?

Mastacheata · December 1, 2019, 2:28pm

I got around the problems with the library, but then got stuck at the U2F Sign Request.
I’m not 100% sure if I pass the correct information to the Sign Request. Do I need to pass the appId returned from the Bitwarden API or do I need to parse the JSON file mentioned there and/or pass my Android App-ID?

8Yb76M5 · December 1, 2019, 5:08pm

Never done anything similar unfortunately…

I found this reference implementation (in Java, but the API calls should be somewhat similar).

github.com

google/u2f-ref-code/blob/bf286fb4a25c842a77a9e2235a8a90ea2799083d/u2f-ref-code/java/src/com/google/u2f/client/impl/U2FClientReferenceImpl.java#L110


    appIdVerifier.validateOrigin(appId, origin);


    JsonObject channelIdJson = channelIdProvider.getJsonChannelId();


    String clientData = ClientDataCodec.encodeClientData(ClientDataCodec.REQUEST_TYPE_AUTHENTICATE,
        serverChallengeBase64, origin, channelIdJson);


    byte[] clientDataSha256 = crypto.computeSha256(clientData);
    byte[] appIdSha256 = crypto.computeSha256(appId);
    byte[] keyHandle = Base64.decodeBase64(keyHandleBase64);
    AuthenticateResponse authenticateResponse = key.authenticate(new AuthenticateRequest(
        UserPresenceVerifier.USER_PRESENT_FLAG, clientDataSha256, appIdSha256, keyHandle));


    byte[] rawAuthenticateResponse = RawMessageCodec.encodeAuthenticateResponse(authenticateResponse);
    String rawAuthenticateResponse64 = Base64.encodeBase64URLSafeString(rawAuthenticateResponse);
    String clientDataBase64 = Base64.encodeBase64URLSafeString(clientData.getBytes());


    server.processSignResponse(
        new SignResponse(keyHandleBase64, rawAuthenticateResponse64, clientDataBase64, sessionId));
  }
}

michecinski · April 21, 2020, 11:03am

Any updates on that?

8Yb76M5 · May 23, 2020, 3:52pm

I saw there is a tentative of implementation in a pull request

If someone knows how to solve the problems described there, it would be awesome

Mastacheata · May 23, 2020, 4:08pm

I can’t get it to work and there’s basically no debug information.
All I get from the API is: Nope, this doesn’t work. No reason given and there could be so many things going wrong, like did I construct the wrong signature and it doesn’t match or did I just format the appID wrong and you can’t find the key matching or is it just broken entirely.

I feel like noone uses the “application” API, let alone the one in Mono/Xamarin/.NET Core because this is a intentionally a web authentication scheme and handled very transparently in browser and WebView implementations.

I just have no idea at all how one could use the browser to authenticate this native application.

Ben86 · May 24, 2020, 6:13pm

If anyone thinks that not supporting U2F is a deal-breaker, Yubikey-HOTP does work just as smooth. I just upgraded to premium and after I configured it on the website, I only had to hold my Model 5 NFC to the phone and it acknowledge the 2FA.

Yubikey-HOTP is much stronger than normal OTP by encrypting the counter with 128bit AES. But like all OTPs, they can be phished, unlike U2F.

But from a UX stand point, Yubikey-HOTP is just as smooth.

Mastacheata · May 24, 2020, 6:41pm

You mix up HOTP and the YubiCo proprietary solution.
HOTP isn’t supported by Bitwarden (and basically noone uses it), but can be used with cheap(er) tokens from Feitian, Google, HyperFido, Kensington etc.
The Yubico proprietary solution needs to talk with the Yubico servers and requires you to use a token made by YubiCo (usually costs ~20-30 EUR on top of the equivalent featureset from a different manufacturer)

The YubiCo HOTP is fixed at 128 bits, most implementations of OATH-HOTP/RFC4226 can be configured to use HMAC-SHA256 or HMAC-SHA512 instead yielding a higher entropy and thus lower risk of finding a collision. (Though, collisions in SHA128 have only been found for chosen-plaintext, there’s no real risk of anyone generating a colliding hash for a third-party input at all, let alone in realtime)

The reason I personally advocate for U2F/FIDO2 is because it’s been acknowledged as the upcoming web authentication/mutifactor standard and is independent from a single manufacturer. (i.e. you don’t need to buy the 75 EUR Yubico 5, but can instead get a Feitian or Solokeys one for 25 EUR)

Ben86 · May 24, 2020, 9:36pm

I explicitly said Yubikey-HOTP because it is a custom implementation of HOTP by Yubico. And I am not arguing the merits of one 2FA vs the other. I’m just saying that the Yubikey-HOTP works over NFC and is stronger than a 6 digit OTP. It makes for a UX identical to U2F over NFC. When it prompts, place near back of phone, done.

The reason I was hesitant to go premium is because I didn’t want to be stuck entering in TOTP codes. The UX of just tapping is vastly superior to entering in codes.

And the Yubico implementation of HOTP is more practical because the security key has limited storage. The last thing you want to do is share the same secret with hundreds of web sites. So instead Yubico holds onto the secret and validates the code on behalf of the service. Of course this is non-ideal, but it’s a compromise one could make for a smoother UX.