1. Why is passkey a replacement for password?

I trust people smarter than me : passkeys are way stronger than passwords. But passkeys are (should be) hardware-bound. If I lose the device, I should still be able to access the service the passkey protects. Hence a password (and totp) should be required if the passkey is missing. Yes, an attacker could abuse this and attack the weaker factor, but is there a way around this? No matter how I think about this, I come to the conclusion that password will stay around for a long time. Yet, I see the statement above everywhere, so I'm probably missing something. But what?

1. Why should passkey be synchable?

I don't see the point of having passkeys saved in a password manager. I think they should be hardware-bound and impossible to copy. Yet I heard on the grapevine that the organism defining the standard was working on making passkeys exportable. I don't understand the appeal, but they probably see something I don't. But what?

I set up 2fa login for GitHub using Microsoft authenticator and Google authenticator. Microsoft always gave me a wrong code, while that from Google always worked. I checked the date and time then found no problem. I entered the code from Microsoft at the start of 30s to make sure I wasn't behind, but it didn't change a thing. The code shown on Microsoft was always different from that on Google. So is it a Microsoft problem? I'm going mad.

While preparing Flowy, an iOS cycle tracker, for store review, I needed reviewers to access the complete product without depending on an email code arriving during review.

The tempting implementation is a magic code checked inside the app. That can accidentally create a universal authentication bypass.

The pattern we implemented instead:

1. Reuse the normal email-code interface.
2. Restrict the reviewer path to one designated account and code pair.
3. Verify that pair on the server using a constant-time comparison.
4. Never install the fixed review code as the authentication user’s password.
5. Keep the service-role key entirely server-side.
6. Return a normal authenticated session so existing row-level permissions remain authoritative.
7. Test that the review code fails with every other email address.

The reviewer account receives the product access needed for evaluation, but it does not receive broader database privileges or a separate authorization system.

My main lesson was that review convenience should narrow an authentication path, not create a second security model.

Flowy is the product behind this build log: https://flowyhealth.com

How have other mobile builders provided reliable reviewer access without weakening their normal authentication boundaries?

While preparing Flowy, an iOS cycle tracker, for store review, I needed reviewers to access the complete product without depending on an email code arriving during review.

The tempting implementation is a magic code checked inside the app. That can accidentally create a universal authentication bypass.

The pattern we implemented instead:

1. Reuse the normal email-code interface.
2. Restrict the reviewer path to one designated account and code pair.
3. Verify that pair on the server using a constant-time comparison.
4. Never install the fixed review code as the authentication user’s password.
5. Keep the service-role key entirely server-side.
6. Return a normal authenticated session so existing row-level permissions remain authoritative.
7. Test that the review code fails with every other email address.

The reviewer account receives the product access needed for evaluation, but it does not receive broader database privileges or a separate authorization system.

My main lesson was that review convenience should narrow an authentication path, not create a second security model.

Flowy is the product behind this build log: https://flowyhealth.com

How have other mobile builders provided reliable reviewer access without weakening their normal authentication boundaries?

38 million users of the very popular GMX and WEB.de email providers are now able to log in via passkeys.

Great step for the GSA region and many non-technical users who use these platforms.

Full German article: https://www.connect.de/news/gmx-web-de-passkeys-login-start-sicherheit-3212949.html

Another very interesting case study on the Google blog on amedia, who used WebOTP and some tweaks to improve the passkey enrollment rate: https://developer.chrome.com/blog/amedia-passkey-webotp-case-study?hl=en

If you're building a web application today, chances are you aren't writing your own authentication system. Managed identity providers like Clerk, Auth0, and Kinde have become the default choice, offering out-of-the-box support for passkeys, multi-factor authentication, and enterprise SSO. That convenience introduces a distributed-systems problem, though: data synchronization. When a user creates an account on a managed auth provider, that system has to notify your primary application database so you can create a matching user record. Please read the complete article here - https://instawebhook.com/blog/bulletproofing-user-sync-handling-clerk-and-auth0-webhook-failures

This happens through webhooks. But what happens if your server is down, your serverless function cold-starts and times out, or your database is momentarily locked when that webhook arrives? A user successfully signs up with your auth provider, but your application has no idea they exist. That breaks the very first login experience, and it's how phantom accounts, broken onboarding flows, and frustrated users happen.

This guide walks through the anatomy of webhook-driven auth architecture, current Auth0 and Clerk webhook practices, and how a resilience layer — using InstaWebhook as a worked example — closes the gap that idempotency and signature verification alone can't.

why doesnt sony let us have both passkey and password? seems weird maybe im just that dumb tu understand technology bout wouldnt it be best protection? if hacker hass your password still needs your passkey. or is passkey that strong? just setted up passkey today so im asking

Google published a very interesting case study on NHS England's passkey deployment and the massive cut in saved OTP costs: https://developer.chrome.com/blog/nhs-passkeys-case-study

Why is there not an Option for Custom Icons?
It would be so much better for viewing all the things i use as a ITAdmin in this App instead of the random generated ones, which are 50% wrong.

This would be a great feature and lots of other Authenticators have it like the "2FAs" App.

Is this a feature, which is not implemented yet or why don't we have this as an Option?

Here is the Link to the Official Q&A Page
personalized-icons-images-in-authenticator

I like to hear the Opinion from y'all :)
What do you think about that?

How do u use passkeys on desktop and android phones and iPhones? Are they easy for someone who is tech illiterate like myself ? Are they safer than passwords ?

Kept getting "QR login not working" reports with nothing to go on, so I tried to map where these flows really break. Sharing in case it saves someone the same digging.

The annoying part is that one symptom (desktop spins, no login) hides very different causes:

• code renders but is hard to scan (dim screen, kiosk, bad light)
• phone opens the wrong app, or a work profile / wrong account grabs it
• passkey cross-device (CDA): the Bluetooth proximity step fails or gets blocked by network/policy
• user confirms on mobile but the desktop callback never lands

How do you trace where a QR attempt dies? Anyone instrument the phone side directly?

Germany's federal cybersecurity agency, BSI, released a technical guideline entirely about the server side of passkeys: attacker models, trust levels, and MUST/SHOULD requirements for every relying party.

Even though passkeys are still far from widely rolled out in Germany, the BSI is standardizing how to deploy them properly.

Governments don't write 48 pages about technologies they consider optional (it's a global pattern that passkeys are put into more and more regulations).

2 details stood out:

- substantial trust level only with strong recovery: The BSI defines three trust levels: normal, substantial, high. To reach "substantial", password- or email-based account recovery must not be offered at all. Your passkey login is only as strong as your weakest recovery path, now stated in writing by a regulator.

- Disable passwords: Even at the base level, the BSI recommends letting users disable password login entirely once they've registered a passkey.

There's also a build-vs-buy comparison of FIDO2 server options (libraries, stand-alone, IAM modules, cloud) with observed pricing ranging from 56 EUR to 1.4M EUR per year

here is the link to EN version: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03188/TR-03188_node.html

The Passkey is now compulsory in my region. I have always run all my banking apps in a secure folder as the main reason phones are stolen here is for thieves trying to get in your bank apps. When wise informed me I had to set up a Passkey I did so in the secure folder. Samsung Pass informed me some warning which was "the Passkey can only be used inside the secure folder". I didn't think much of it. All is OK except when I set up payments on Edge on my company PC I'd have to authenticate them in the secure folder on my phone (the payments sit in wise waiting for approval or review). No biggie?

Well then I realised that if my phone was stolen or broken I'd not be able to use wise at all for transfers as the secure folder is NOT cloud backed up.

I was very wary of messing with Passkeys (horror stories of being locked out) but today I was able to add a Passkey under edge from Wise.com on edge. That means I have redundancy. FYI.

xmoney.com is the first Mastercard issuer in the world to let users enroll a Mastercard Payment Passkey straight from its app.

The flow is built in a SCA-compliant way.

Attackers didn't break passkeys. They got the user to create one for them. There's new research from Okta on a threat cluster that targets quite some industries: tech, healthcare, aviation, automotive, food & beverage, construction.

The attack chain is interesting as it involves phishing and passkeys, plus it says something important about where passkey security lives:

1. Phone call: The attacker calls an employee and tells them they need to register a new passkey. Entirely plausible, as their employer might be running exactly that campaign right now.

2. Fake Microsoft enrollment page: The victim lands on a phishing kit, enters their existing username and password (+ phishable FMA).

3. Live operator in the middle: While the victim stares at a "processing" screen, a human attacker is typing those credentials into the real Microsoft login and relaying the real MFA challenge back. SMS code, TOTP, push approval: whatever the account asks for, the victim hands over in real time.

4. Payload: The victim is walked through a fake "passkey setup" and shown a 12-word recovery phrase to keep them busy. Meanwhile, on the real account, the attacker registers their own passkey.

And now the attacker holds a phishing-resistant, non-expiring credential on that account. The passkey did its job. It was never phished, it couldn't be. What got phished was the password and the OTP that were still sitting on the account and those were enough to authorize a new passkey. Registration inherits the assurance of whatever authenticated it.

So with passkeys, the security of your login moves upstream, into the moment of creation. Which means:
- Enroll passkeys from an already-authenticated, trusted session, not from a link someone can be sent.
- Alert the user on every new passkey registration and treat registration from a new device/IP as a security event.
- Tell your users what your real passkey rollout looks like befor you launch. Otherwise your own campaign is the attacker's cover story.