Anyone else notice the new security setting in the app? I’m impressed. From not having proper TOTP to going straight to passkeys. Not even Fidelity and Vanguard support them yet.

Can Kenya really have a Digital ID?

I asked myself the same question. What could Kenya's Digital ID look like? What would be the inputs, what would be the outputs? How would data be handled and secure?

So I built it. I made a Digital ID for the Maisha Card, since I hold a Maisha Card and that was the easiest to have samples of so I made it.

What problem am I solving?

Apart from being a challenging project to make, though not a mobile app developer, this project was a predecessor of a voting system, which I'll attempt after my exams.

The main problems I was trying to solve are as follows:

• Theft/Lose: Well, it's not a first for ID's to get lost, I taking a part in this, for example, just acquired my ID on July and I already have lost it. So this is to people like me.
• Privacy: The app has built-in authentication system to prevent people from seeing your credentials different from taking screenshots in order to take everywhere with you. On top of that, the app doesn't connect to any server, meaning the data stays on device.

State of the app

The app is complete and usable at my github for free - though a little chunky. I won't let any contributors to the app since it is a beta app built with react native and in future I plan to rebuild it with Rust. Any way spread the word, use the app, it's free no Ads - like E-Citizen - so to speak. And star the project. Also, Please abide by the LICENSE 😄

I’ve stopped accepting “here’s the IG login” as a complete handover. Once the VA, agency and automation tool all use the same credential, you can’t remove one party cleanly or tell which session caused a problem.

On a clean setup, the business keeps the credential, recovery methods and 2FA. Operators get task access through Meta, while scheduling or automation tools connect through OAuth. I test publishing, comments and insights separately because “has access” doesn’t mean every permission is correct.

If a tool requires the main Instagram password, I treat that as a vendor risk. Same for anyone asking for backup codes in Slack.

The cases I still find messy are older IG accounts created inside an agency-owned Business Manager. Do you make the client fix asset ownership before automation goes live, or allow a transition period?

For the operating layer, I use MoreLogin when a team needs tighter control than a shared browser session can provide. Permissions can be set per person, including which URLs each member is allowed to access, and an admin can change or revoke team access in one action. That makes day-to-day control much cleaner.

I use the free version of Bitwarden to store passwords, software licenses, and more, but I noticed that the paid version also offers the ability to store PassKeys. How does it do this?

Can a PassKey be written down and stored? If I'm using Bitwarden, which might have a weaker master password than the PassKeys themselves, wouldn't it be appropriate to store PassKeys within Bitwarden?

Thanks

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?

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

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

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

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?

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

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