Passwords vs. Passkeys - FIDO Bites Back! 

Exactly right! I meant to include that in the video

Not all sites allow multiple keys though. Would be good if the keys have some kind of backup tool to a paired key (although it increases risk for extraction)

Yubikeys with a good backup plan in case you should be so unlucky to lose one is the way to go. I love all my Yubi's with a dear heart after an incident 6 years ago where I was targeted by some skillfull individuals. Not saying it's unhackable, but all the precautions I have implemented in my digital life will sure make it very hard for someone to hack'attack me at that scale that I was attacked. Keep up the great and important videoes @jeffcrume and @IBMTecknology 👍

Glad you liked it!

infrastructure on the shoulder of giants. Nice work folks.

Thanks for the kind words! I can take no credit for standard but, as you said, a lot of “giants” contributed to this and thought through all the hard stuff for us

You’re describing multi-factor authentication and passkeys leverage it as well. Check out the previous video to see how it works

@@jeffcrume Thanks for your answer! You are right, I tried a few pages and 2FA is still in place in addition to Passkeys. Still, the idea behind passwords is to keep the secret in your brain and passkeys eliminate this. Of course, this factor is present (if configured) when a user has to unlock the vault holding passkeys (phone or password manager) with the pin or password. My best experience is one service where I have to enter a password in the app for second factor auth. Then I have all three factors in place: Passkeys is something I HAVE, for 2FA I unlock my phone with biometric auth (something YOU ARE) and then I type my password which I do not store in a password manager (something I KNOW). A bit annoying but security should not be simple. And thanks for the video - it's just great! Subscribed :)

I think you can use cloud-based password manager for non-important accounts + FIDO2 security key for important accounts + most important account such as bank website which not relies on password manager. Also you can lock your device through applicable app, then biometrics won't work.

They don’t really have to be covered in the standard since existing solutions already exist. For instance, 1Password and iCloud Keychain are just two examples of tools that already have this covered. I’m sure there are many more

I love it!

LOL😅

Great question - sorry if this sounds like a commercial but I’ll use this to illustrate the point - IBM Security Verify Access is a tool that web sites can use to add FIDO/passkey support to their systems without having to recode everything. Without a tool like this, the web site will need to add support for FIDO on its own, and that can involve more cost.That said, the savings resulting from fewer security incidents and fewer help desk calls (no lost passwords) could easily offset the cost. The organization just has to be willing to make the initial investment and many are. IBM, Google, Amazon, Twitter/X, Meta, Microsoft, Apple, etc. all support it today

Does the FIDO 2 USB tokens don't authenticate based on any biometric? I have not used one, so asking. Here FIDO private key is locked by biometric authentication of the device

@@dinesharunachalamyou really don’t need to use passwords as a backup because you can have multiple private keys for each device on each account and those can be sync’d through a password manager, iCloud Keychain, etc.. This provides a recovery mechanism. As for USB tokens, they can vary but typically they could leverage a fingerprint to unlock them. Or, in most cases, you can just use your phone, tablet or laptop as the FIDO device since they probably have biometric support and secure storage of the keys

Fido2 hardware key which doesn't have biometric usually ask you a pin code to unlock the device (with auto erase after 3 attempt)

Thanks!

I take your point but I would say that passwords are inherently less secure that passkeys because they have no time limit and can be discovered by hacking the web site. Passkeys are time bound and there’s no secret stored in the web server so those are at least two aspects of risk reduction

You're still thinking about passwords statically. Think more dynamically along the lines of rolling encryption standards, but better. Every time the user logs in, the fully encrypted password that is stored there should be different. The server should never even know what the password is if everything is done right. In no way shape or form should a server remain static in regards to username and password entries. This was always the mistake and frankly it's shocking that it persists. Static stored logins will never be secure.

I know what you mean. I used to use a PW manager which could sync across a LAN to only my devices (no cloud needed), which I preferred, but everything has moved to the cloud now, it seems. That said, a good cloud provider lowers the risk and you encrypt the pws (or better yet, passkeys) in the pw manager client BEFORE it goes to the cloud. That way you can retrieve the info from anywhere and it isn’t exposed

It depends on how the web site is setup and your tolerance for risk, but, in general, I would say that if your devices are FIDO compliant and you don’t use trivial passcodes on them, then, yes, passkeys should be sufficient because they would already include MFA (i.e., the device with the private key - something you have - and a biometric to unlock it - something you are)

You could do it that way but the implementations I’ve seen seem not to. It could also be an approach of both/and rather than either/or, it seems to me

I recommend watching this video - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SWocv4BhCNg.html (FIDO Alliance - Passkeys in Action). It shows cases for both re-using passkeys and creating new ones afresh.

It’s a risk, for sure, but IMHO it’s far less of a risk than the one posed by passwords, which are a badly broken and outdated approach

If you don't trust something like iCloud then yes. If you don't trust a password manager then don't sync, and use your Yubikey everywhere.

yes, passkeys are just for authentication, not confidentiality. TLS/SSL can help ensure that the site you are interacting with is authentic and not a MITM

Thanks. Now I have another scenario. One unknowingly goes to an invalid website to login using passkeys. The website provides a junk challenge to the user. The user decrypts and re-encrypts the challenge using its own private passkey and passes back the response to the challenge. The website accepts the challenge without decrypting and provides the user with a screen the user uses to provide valuable info back to the website. Thus a theft occurred. How does FIDO stop this? @@jeffcrume

All far more likely to impact passwords than passkeys

Not yet, but that’s in the works

That’s essentially what is happening in the generation of the public/private key pair. You don’t have to remember these

Yubikeys support passkeys, BTW

Not sure what you mean. iCloud Keychain syncs these across MacBook, iPad and iPhone today

TPM deals with the hardware where the operations occur. FIDO is the protocol that could leverage that hardware for authentication

@@jeffcrume TPM 1.2 or 2.0 protocol?

Same for your password but your password would be far easier to guess in most cases and since it also resides on the server, it could be hacked from that side as well

Besides, you have a different key for each site so the impact would be limited

Is there any service available to say, my password wallet root password got exposed, so does anyone have my email@address stop accepting login from anywhere and provide me a password challenge to my email account

The key (pun) to all this is to note that passkeys do not provide absolute security. Nothing does. But they provide much better security than the existing paradigm. Also, it's going to be a gradual process. In the transition you'll use both "legacy" passwords with or without 2FA and passkeys. In fact, I inadvertently tested that the other day when I set up my first passkey in the browser and password manager. But it couldn't find it on my phone, so I had to use password + 2FA. Though the passkey did work on my iPad. I discovered later that this was because Google was the default passkey provider for Android. I've since changed that to my password manager, but haven't retested. I've spent a fair bit of time reading and watching stuff in the past couple of weeks or so and I've only now just tried a passkey on a relatively minor site, in that it's public for reading anyway. The best thing to do is to keep watching and reading and then proceed gingerly. I only started exploring this stuff when a few of my websites started popping up "would you like to use a passkey?" I answered No but then later started Googling about them. There are also a few interactive test sites you can try them out on. I did that too.

That’s not at all what I said. I said that the public key is public. Your private key is private. Only you know it. Therefore, only you can answer the challenge which is encrypted with your public key.

I’m doing it every day and the site you log into has no idea whether the keys were synced across devices or not. Granted, it would be best if you don’t put any of this in the cloud and you don’t have to if you want separate keys for each device but most people will opt for the sync and even if they do it’s far lower risk than what most do today in choosing their own passwords and setting them all to the same thing

I can’t. Search this channel for “how we make them” and you’ll learn the secret

I was wondering the same thing. I don't believe he is writing backwards. I think the recording system he's using is specifically built for see-through "whiteboard" teleconferencing presentations... it's inverting the video in realtime or doing it in post. The other option is he's using some type of high-tech, 2-layer/2-way, whiteboard that's doing the inversion.

its called lightboard. creator's website - lightboard[.]info

Sometimes a cigar is just a cigar, Dr. Freud...

I think blockchain can do all those things. I believe iBM would have a solution for that. These folks know their stuff.

After listening to him for a While I would give him the benefit of the doubt. He probably has some reasoning behind his answer, there always is.

I'm shocked to hear that someone has another opinion than me

Both FIDO2 USB tokens and passkeys offer robust security, leveraging public key cryptography. The choice between them often depends on the user's specific needs, preferences, and the types of threats they are most concerned about. USB tokens offer strong security with the inconvenience of a physical device, while passkeys provide a more integrated and user-friendly experience with security that is largely dependent on the security of the user's device. Passkeys are not the same as putting your private key in the cloud. They are a more secure and user-friendly form of authentication that replaces traditional passwords. Passkeys use public key cryptography. They generate a pair of keys: a private key that stays on your device and a public key that is shared with the service you're accessing. The private key in a passkey system never leaves your device, which makes it more secure. It is not stored in the cloud. This contrasts with storing a private key in the cloud, which would be less secure because it could potentially be accessed by others When you authenticate with a passkey, the service you're logging into challenges your device. Your device responds by using the private key to sign the challenge, proving that you possess the corresponding private key without actually transmitting it. FIDO2 Tokens**: Require the user to carry the token and plug it into a device. This can be less convenient, especially for mobile users or those using multiple devices. - **Passkeys**: Generally offer a more seamless user experience, especially with features like cloud synchronization across devices. FIDO2 Tokens**: Might not be supported by all services and can require users to purchase the token. Passkeys**: Increasingly supported and often built into operating systems and browsers, making them more accessible. FIDO2 Tokens**: If you lose the token without a backup, you could be locked out of your accounts. Passkeys**: Typically have recovery methods associated with the user's account, like cloud synchronization or recovery codes Passkeys are designed to be more user-friendly than traditional password systems. They often work with biometric authentication (like a fingerprint or facial recognition) on your device, adding an extra layer of security without the need for complex passwords.

What you described is, indeed, better and is the way a lot of implementations of FIDO work. That said, iCloud Keychain, 1Password and plenty of other password managers have leveraged encrypted cloud storage/sync for many years

A PIN is not a passkey. It may let you use a PIN to unlock a passkey or a PIN instead of a password but in either case, the strength of the security would be only as strong as its weakest link and that would be the PIN

@@jeffcrumethanks. I should not have said used as a passkey.. . But rather created or generated using the MS pin as one ingredient. The MS pin is not the traditional random pin you are thinking of. It is based on credentials and machine ID. This is why I want to know how to back this stuff up ... Where this security info is stored? Ultimately, I know you can store passkeys in bitwarden.

As I said in the video, these can be sync securely in the cloud so that you aren’t dependent upon a single device

That’s the value in the standard. You don’t have to trust the service provider. You trust the protocol

Passkeys are unique for each site (just like passwords) and time limited (unlike passwords), making them even more secure

You can't "spoof" a passkey. Passkeys are UNIQUELY generated (ie. unique per website) "key PAIRS" creating FROM a DEVICE BOUND "Master Key". The Master Key and the Private key half of the Public/Private key PAIRs it generates is LOCALLY stored. In fact the Master Key is hardware bound inside a hardware security module (HSM) , a physical security chip inside your device, which cannot be divulged. Only the Public key half of the Public/Private Key PAIR is ever shared. Jeff isn't explaining the intricacies b/c frankly nobody on YT would understand the full crypto/authentication flow. The spec has been around for well over a decade and has been slowing evolving/expanding ever since. You can go read it for yourself, but you won't bc there's VOLUMES and VOLUMES of documents composing the FIDO, FIDO2/WebAuthn (Passkeys) spec.... and simply reading the spec won't get you "there" b/c you 1st need a DEEP technical foundation in cryptography basics... Authenticated Encryption (secure message signing), knowing the difference between symmetric vs asymmetric ciphers and their strength/weakness use cases, integer factorization and the discrete log problem and how this relates to PKI implementations leveraging RSA, DSA, DH, and ECC vs a symmetric cypher like AES-256 in CCM mode which passkeys also utilizes. The bottom line is you can't simply "spoof" a passkey. It's literally a UNIQUE 256-bit random number bound to a hardware device, bound to an AppID (a website domain or app), and linked to a EPHEMERAL challenge generated randomly & in REAL-TIME by the Relying Party(RP)/website.