Sounds good, but it makes me uneasy when these 3 companies agree on something. As far as I'm concerned, they are all working for the govt
Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
501–510 of 525 posts
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#502Earlier quoted context omitted.
I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG. Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
FIDO2 with resident SSH ed25519 keys works great, just make sure the OpenSSH client and server versions on all the machines you’ll be using the key on support it. I wish there was a way to sign Git commits somehow using them instead of PGP.
There is as of Git 2.34 [0][1].
[0] https://github.blog/2021-11-15-highlights-from-git-2-34/#tid... [1] https://git-scm.com/docs/git-config#Documentation/git-config...
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#503Earlier quoted context omitted.
With regard to supply-chain attacks, since the TPMs are manufactured in China, they can just make a perfectly "genuine" TPM with a valid, signed key which has their backdoor. The attestation process protects DRM users (media companies) from device owners. It doesn't protect device owners from TPM manufacturers.
The TPMs are in-chip now, so they’re made in the TSMC Taiwan fab along with the rest of the die.
As I said—manufactured in China. Both the government of mainland China and the government of the Republic of China (Taiwan) consider mainland China and Taiwan to be parts of the same country. They only differ with regard to who is in charge.
The issue could be addressed without removing the ability to attest as to the TPM's origin by including a protocol for the owner to dump the device's private encryption keys (e.g. by shorting one of the external pins to ground). The fixed attestation key set by the manufacturer would need to be restricted so that it can only be used to sign attestation messages, with all other keys being generated on the device so that they can be reset when the device changes owners.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#504Earlier quoted context omitted.
> What's easier to do? stealing someone's fingerprint or cracking\guessing their password. > Definitely the latter. You sure about that? A properly generated (i.e. random) password won't be cracked or guessed in any reasonable amount of time, whereas a model of your fingerprint(s) can be lifted from any object you've touched and used to create a silicone mold capable of fooling many fingerprint readers. And you only…
Really? can you back this up? I can. I work in the cyber industry for a decade now. I've seen the data, I've seen attempt to bypass both. Biometrics are by far better for the vast vast majority of people. Do you even listen to what you're describing here? trailing someone, trying to extract fingerprints? this isn't a Jame Bond movie. Cyber attacks are common because they are completely digital\anonymous by nature. Se…
> this isn't a Jame Bond movie.
It doesn't take James Bond to lift some fingerprints off a surface. Anyone with physical proximity and a little practice can manage that much. People have managed to fool fingerprint readers with Gummi Bears before, much less specially-designed equipment. It's a practical attack, unlike attempting to brute-force a truly random 10-character password from a 78-character alphabet (uppercase, lowercase, digits, and half of the 32 symbols on a PC-104 keyboard).
> Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
Which is perfectly fine. You aren't going to break their password manager either. The weak point is the users who aren't using password managers, because they try to get by with less-than-random passwords which are susceptible to cracking. Or biometrics, which aren't secret at all.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#505Earlier quoted context omitted.
FIDO2 with resident SSH ed25519 keys works great, just make sure the OpenSSH client and server versions on all the machines you’ll be using the key on support it. I wish there was a way to sign Git commits somehow using them instead of PGP.
There is as of Git 2.34 [0][1]. [0] https://github.blog/2021-11-15-highlights-from-git-2-34/#tid... [1] https://git-scm.com/docs/git-config#Documentation/git-config...
Oh nice! No more futzing around with GPG. You just made my day.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#506Earlier quoted context omitted.
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
I use the "multiple security keys" approach, and the biggest problem is keeping track of which keys are registered with which services and making sure the list is up to date. A few examples of situations where this is a problem: 1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, f…
The way it’s meant to be done:
1. You register both the primary and the backup key with every identity provider (ie GitHub)
2. You only carry the primary key with you at all times. You keep the backup key in a physically safe space (ie next to your birth certificate).
3. In case the primary key gets lost, you make the backup key your new primary key. You can log in with it everywhere because you already registered it in step 1.
4. You order a new key which will become your new backup key.
5. Go to step 1.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#507Earlier quoted context omitted.
> that key cannot be reversed to get the original features "As a result, the early common belief among the biometrics community of templates irreversibility has been proven wrong. It is now an accepted fact that it is possible to reconstruct from an unprotected template a synthetic sample that matches the bona fide one." -- Reversing the irreversible: A survey on inverse biometrics https://www.sciencedirect.com/scien…
"from an unprotected template" do you even read? stop trying to find some random internet page to justify yourself, have you ever seen a biometric implementation? I have.
I don't know what counts as a non-random internet page, but here[0] is an article published by the "European Data Protection Supervisor" titled "14 Misunderstandings With Regard To Biometric Identification And Authentication", with number 12 being "Biometric information converted to a hash is not recoverable". It states:
> there are studies showing that the hash could be reversible, that is, it could be possible to obtain the original biometric pattern, especially if the secret of the key used to generate the hash is violated
So yes, there are secret keys involved (which the user has no control over), and no, I've never read through the code of a biometric implementation, but ultimately the space of possible values that someone's face or finger could reliably display is much smaller than even MD5, so it can be brute-forced.
If you have some non-random internet page to justify yourself, and show how much entropy is contained in a biometric hash, and how resistant to cracking that hash is, and how well secured those secret keys are, then I'd be happy to learn more.
[0] https://edps.europa.eu/sites/edp/files/publication/joint_pap...
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#508Earlier quoted context omitted.
Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so f…
Thanks for the shout-out! I wrote that U2F implementation in software because I wanted phishing protection without needing to carry a hardware key. Well, and to learn Rust :) It's certainly a security trade-off to just store secrets in your keychain like I choose to, it is not meant to be a replacement for a hardware key and in fact I have a Yubikey I use when the situation calls for it. I'd love to use TPM and biome…
> relaying auth requests to your phone for approval and storing secrets in the Secure Enclave
Like the acquired/abandoned https://github.com/kryptco/kr [key stored in a [...] mobile app] with iOS and Android apps all under an "All Rights Reserved"-source license?
Also, newer Macs have a Secure Enclave (supports 256-bit secp256r1 ECC keys):
https://github.com/maxgoedjen/secretive [storing and managing SSH keys in the Secure Enclave [...] or a Smart Card (such as a YubiKey)]
https://github.com/sekey/sekey [Use Touch ID / Secure Enclave for SSH Authentication!]
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#509Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.
"Backing up" only, no restore (circa 2016):
Decrypt/Extract NitroKey HSM RSA Private Keys
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#510This is huge! It sounds like they're finally going implement cross-device synced credentials; a move I've been advocating now for the last two and a half years[1]. Widespread support for this feature is, in my opinion, the last thing needed to make WebAuthn viable as a complete replacement for passwords on the web. The white paper is here: https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... Seems like the…
I get that but I think OIDC could be extended to cover that too whereas the Authenticator or iDP is the local face scanner kr other biometric and then the rest ie exchange of token etc stays the same. That way there won’t be two completely separate path and that will defeat the purpose of SSO ie OIDC websites will authenticate with google or Facebook but FIDO enabled websites will work with face recognition. And it l…
1. You can use OpenID Connect as a protocol to integrate (via federation) with a site that provides authenticator management. This is AFAIK how most deployments work today - even if that OpenID Provider winds up being something you run or you pay to be run for you (AKA a CIAM solution).
2. There is an upcoming specification, Self-Issued OpenID Providers v2, which provides a redirection flow to an agent such as a native app or PWA app. This does look a bit different from traditional OpenID Connect though, as each End-user is effectively its own issuer with its own public key pair.
Since the browser and platform will have integrated support for FIDO/WebAuthn tech, they may still provide a better experience for equivalent scenarios.