2
FIDO2
Idea shared by Howell Dell - 7/5/2025 at 7:55 PM
Proposed
All SmarterTools products need to support TOTP plus we need to add Passkeys support soonest. As you must know Microsoft has started the count down to NO MORE PASSWORDS starting on or about August 1, 2025. Their replacement for passwords and TOTP is Passkey. This is for Microsoft 365, Outlook.com, Hotmail.com and Live.com. If you are a partner or end user this is coming to you soon! Get READY NOW!

I have been beta FIDO2 Tokens for more than a month and I am help clients switch!

Google launched Passkeys on World Password Day in 2022 and since that time 400 million Google Accounts have been secure using this technology. Google created their Titan Security Key as a test bed platform and required all employees to use some after at or after 2018.

.Net Core example of this is https://github.com/passwordless-lib/fido2-net-lib. Not sure how good this is or the quality of the code -- but this lowers the barrier to entry. You also FIOD2 on a PICO Microcontroller at https://github.com/polhenarejos/pico-fido.

5 Replies

Reply to Thread
5
Microsoft should shut the frick up and let us do what WE want....

Passphrases are the only thing you can have in your head thats personal... and not something somew other techgiant is supplying.

All of Europe is getting out of the Microsoft Software shitbucket....
0
Sorry I hit a nerve. I am just reporting the state of the world everyone lives in. 

Regardless, IMHO Passkeys are a good security measure to implement to help protect the end users.

How many folks think Passkey is a good idea -- plus 1!
0
Any takers for FIDO2 for PassKeys? Anyone trying PassKeys? I think its good and by using a physical token it moves the "Key" from a device to a simply device plus I can make backups.

Laptops, Desktops, Tablets and Smart Phones get replaces and I don't see we have a consistent method to migrate Keys on these devices.
0
At the risk of turning a technical forum into an outlet for commentary, this increased reliance upon specific devices is frustrating and makes portability more difficult.  It also makes certain reliability assumptions that are just not realistic.  Passkeys could be implemented using passwords which never leave the local system just the same as it can be implemented via biometrics.  I do not believe for a second the selling point that my biometric source data will never leave my device.  All it takes, in the best case, is a tiny developer "oopsie" to trigger a compromise of my biometrics, a regulatory investigation, and a monetary slap on the wrist for the company responsible while I am left to clean up the mess it made of my life.  In the worst case it is done deliberately with the understanding that "we can just pay the fine."

While developing an authentication system for my own purposes, I did something simple which does not require passing the password to the other side: using a client-side hash function on the user's entered password and sending that over.  It is simple and not absolutely fool-proof, but at least a way to not expose your password beyond the local device.  I had begun toying with ways to negotiate a dynamic salt between app and client as a way to help defeat hash attacks, but was distracted by other things and it has been left languishing.

My point being is passwords are, IMNSHO, by far the easiest thing to for the end user, even considering the obstacles users create for themselves in both usability and security.  It does not require being tied to a device, and having to deal with issues associated with securing or losing that device.  Passing passwords between client and server should have died in the 2000s as client-side scripting became more prevalent.

Not trying to shoot the messenger here, just expressing frustration at the continued advancement of technology by engineers and marketers without any apparent concern for how it affects end users.  Irrespective of what Forbes says, we should never have eliminated the Tom Smykowskis of the world, but utilized them more intelligently to act as customer advocates rather than simple liaisons.
1
You can store your passkeys in your password manager, like Bitwarden. That password manager will run everywhere; from Linux to your browser to your phone. It only relies on you having a single account with Bitwarden (or your self-hosted instance). You can export passkeys and import them back into a Bitwarden account, but they can't be moved elsewhere yet.

Recently, Apple made it possible for passkeys to be transferred to another password manager service, like 1Password: https://arstechnica.com/security/2025/06/apple-previews-new-import-export-feature-to-make-passkeys-more-interoperable/

Apple only did this last month, and they are one of the few companies to do so. Bitwarden still hasn't done it.

I'm not a big fan of passkeys because a lot of implementations are done in a way that enforces vendor lock-in, even though the import/export standard has existed for years. I also think they make auth more complicated longer term.

It's not reassuring that you can't back up passkeys; only migrate them to other services. KeepassXC has support for importing and exporting passkeys, and I suppose that would be the ideal place to back them up, since you can store a Keepass DB file on a USB drive somewhere. 

However, last year there were threats to block Keepass as a passkey provider on services that support passkeys because they didn't implement passkeys the way they would like them to be implemented: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200

Notable comment:

You absolutely should be preventing users from being able to copy a private key!
What a wild time for security. I think reading part of this Github issue thread as research for writing this comment has actually turned me off passkeys when I was sort of ambivalent/positive about them 20 minutes ago.

Reply to Thread

Enter the verification text