Tozu
Testing on github.com and accounts.google.com, with the flag(s) enabled I do get the option for signing in with password+yubikey, but pressing the option for yubikey does not actually show the yubikey prompt. Does it work for you?

  • Tozu replied to this.

    GoldenDuck1 indeed, at least with enpass passkeys work only with active Google play service!
    However i striped all permission from it and have no other google service active where it could steal permissions from and passkeys still work

      Relaks did not test it before as i use passkeys now (if supported). You are right it also get into an error. Somehow I managed to get the prompt once while playing around with google services but couldn't reproduce it.

      Tozu So its not natively supported in Graphene OS by default, you have to install Play Services...
      The Graphene OS developers should make a Passkey implementation so people shouldn't have to install Play Services.

      Relaks no it does not. I just enabled via your flag using 1pw and it keeps giving the "something went wrong" error.
      Tested on Vanadium, Chrome Canary, and Vivaldi

      Too late to edit last post.
      IT DOES WORK VIA 1PASSWORD

      Give me some time to run through all the steps because it is very very janky but I will come back here with a step-by-step process. I'm currently facing issues with attaching it to Google but I was able to get it to attach to passkeys.io just fine

        N3rdTek ok so I've got good news, bad news, and strange AF news.
        Let's start with the strange; correct me if I'm wrong but passkeys requires Android 14, correct? I have a few devices on hand due to being a tech enthusiast, one of which is a Galaxy S10. It only supports Android 12 because "Reasons" yet feels faster than my Pixel 7.... at times, but rarely ever worse.

        However, not only can I create & sign into passkeys.io with a passkey, after enabling the chrome flag , I can do it with my Google account also. It doesn't seem to even respect my Autofill choice of 1Passwors having disabled Google as my Autofill choice in settings. Yet still detects, authenticates, and signs me into my Google account using Google password manager.
        And to top it off? When I initially tested passkeys.io I wasn't aware I was doing from my S10 initially. When I went to test on my pixel, it asked if I wanted to sign in using my saved passkey from the S10....Stange AF right?

        Now the bad; my pixel 7 running GoS will not work for any of my Google accounts. I've tried just about everything;

        • setting 1pw as autofill
        • Setting Google as autofill
        • Trying regular ol chrome browser
        • Trying Chrome Canary
        • Trying any other browser
        • Trying a brand new never used before browser (Vivaldi)
        • Completely removing the Google account from device then trying

        Feel free to prove me wrong I spent upwards of last hour testing.

        And the good?
        It works for passkey.io, it works for GitHub, I'm getting ready to try a couple more but general consensus so far seems to concur our devices will support passkeys to almost everything but Google.
        Provided that you;

        • enable the chrome flag as mentioned earlier chrome://flags/#web-authentication-android-credential-management
        • set your password manager as autofill
        • then attempt to register your passkey/device

        This is useful to know but man, what a janky as hell future to get rid of passwords amirite?

          N3rdTek passkeys requires Android 14, correct?

          Only Google's passkey support for third-party services requires A14. Google's first-party implementation requires merely A9: https://support.google.com/accounts/answer/13548313?hl=en
          But that won't work on GOS.

          N3rdTek This is useful to know but man, what a janky as hell future to get rid of passwords amirite?

          The support for this in Chromium/Chrome is still experimental. That's why you have to enable the experimental flag(s)... Support allegedly will arrive later this year. I don't expect anyone to think that most people would spend an hour setting up a, for the time being, clunky feature. I'm guessing that's why 1Password and the like don't want to say they officially support it yet, even though it somewhat works.

          Personally I'm sticking to FIDO2 security keys for the time being. They just work.

            Relaks o
            Out the browsers I tried, for whatever reason Vivaldi felt the most stable & worked the most consistently for 1Password if that helps you or anyone else that may read this.

            Previously was using mostly vanadium and brave nightly. No real reason why nightly other than cuz I just like purple

            18 days later

            Passkey sign-in with 1Password no longer seems to work in Vanadium (although it does still work in Brave): I'm prompted to select the correct passkey, but when I press Continue it just goes in a loop, asking me to verify the passkey again.
            Google recently changed the options in the flag, so you now have to select "Enabled for Google Password Manager and 3rd party passkeys", and enable both 1Password and Google Password Manager as providers in Android's settings in order for it to detect passkeys saved in 1Password.

            I'm still annoyed at Google for not implementing CTAP2 within Play Services, which makes using Yubikey as a passkey on several sites, such as Microsoft, impossible. But that's a different matter.

            24 days later

            It seems like third-party passkey sign-in and registering is now broken in Vanadium (tested with 1Password). That is, passkeys are correctly recognized and can be selected, but websites I'm trying to sign in to throws an authentication error after the passkey is selected.

            Both sign-in and registering with passkeys work fine in Brave (tested with github.com, Brave Nightly). It also does not block the security key prompts when Yubikey is registered as MFA (tested with proton.me, slapp om Brave Nightly).

            The feature is still experimental, it seems, so I think it's too early to file a bug report for Vanadium.

            11 days later

            Note that 1Password appears to recently have restricted browser passkey support to only accept them to be used within supported browsers. Vanadium is not a supported browser by 1Password, so passkeys will refuse to fill in Vanadium.

              Relaks I've been a faithful 1password user for about 3 years now, but in all honesty I'm getting quite fed up with it because since I've been trying bit warden that thing works everywhere and I mean literally everywhere. But it doesn't have an accessibility service. So how the hell is 1password dropping the ball in so many areas such as regular autofill and now pass keys when here comes bit warden just strolling around and doing everything with ease making it look simple?

                N3rdTek But it doesn't have an accessibility service.

                From a security perspective, it's not recommended to to configure a password manager as an accessibility service. The auto-fill service exists and is the proper way to use a password manager on GrapheneOS.

                N3rdTek 1Password's desktop app is a lot better UI-wise and accesdibility-wise for me than Bitwarden, that's partially why I'm sticking to it.

                As for the passkey issue, I'd like to use physical security keys for this purpose rather than a password manager. This is why I'm excited for Google's latest Titan release. I'm just waiting for it to become available for shipping to the country I reside in, so I can test it on GOS.

                But I might be straying a bit offtopic now, so I'll stop. 😊

                3 months later

                KeePassXC 2.7.7 was recently released and thus there has been renewed interest in passkey implementation in KeePassDX and KeePass2Android. One commenter on the projects' respective Github issues claims that the Credential Manager API requires Google Play Services. Is that correct?

                  p338k

                  https://ibb.co/pnTrD6w

                  I have now tested passkeys with 1Password in a fresh profile without Play Services. 1Password seems to run fine without it, but unfortunately, when testing passkey sign-in from both Vanadium and Brave, the passkey prompt never shows. I have made sure to test with the different options (including the default) under "Android Credential Management for passkeys" in chrome://flags. Have checked that 1Password is set as the password/passkey-filling service in Settings > Passwords and accounts. Have also checked that the passkey sign-in prompt for the sites I tested work fine in my owner profile with Play Services installed (with the exception that 1Password is blocking the autofill in Vanadium, after having chosen the correct passkey for the site).

                  This is anecdotal and does not mean that Play Services is necessarily required for the Android Credential Management. I found one post in the forums where the user needed Play Services for Enpass' passkey feature, but the post is old at this point (from Oct 23). It could be that 1Password requires Play Services for this, or it could be something broken with my setup.

                  You were right to question the statement in my post. I will edit it to clarify that this point is not 100% confirmed at this time.

                  Those services seem to like a unnecessary risk. I use Kepass DX with the built-in keyboard.

                    MarsTrue

                    It is obviously not yet implemented, but I believe the web service will send the challenge/response flow will be something like:

                    Challenge: web application -> browser -> credential manager API - > KeePassDX
                    Response: KeePassDX -> credential manager API -> browser -> web application

                    KeePassDX (or other credential provider) handles the cryptography without exposing the private key.

                    This is a simplified model and may not be entirely correct, and I could be wrong somewhere.

                    I am not sure it would add much additional risk if implemented properly and should prevent exposing a password. I am not sure how the API works under the hood.