if passkeys are stored "on device" and "in the cloud", then how much does this increase the dependency on companies like Google, Apple and Microsoft? will it still be possible to have a separate password manager that stores a passkey instead? modern authentication should not fuel vendor lock-in!
passkey is actually a FIDO credential token to say - you dont need to store them "on" enddevice or cloud - you can also store it on a Security Key like Yubico - you can then also plug that USB Stick in your Linux Workstation and authenticate there with it. So you see there is no Google, Apple, Microsoft involved here. However i think in 10 years probably 99,99 % will use it by them because its convenient.
Best demo on the subject I have seen so far. Some things were not fully clear for me though. - What happens if I create first passkey on a computer that does not have a camera? What will be the other options to spread to the other devices? - What medium is used to "remember the device" notification (mentioned, but not demoed) from the computer to the phone? - If someone shoul break into my Google or iCloud or MS account, how it is avoided that the hacker will have access to each and every service I use?
Regarding your last question, for Apple at least it is not enough to compromise the iCloud account - you also need to have access to one of the existing enrolled devices for that account.
Regarding the last question: this is the weakness of Passkeys. You need to have multi-factor authentication (MFA) on your Google and Apple accounts. Apple lately enforces this, Google is slower in its enforcement. Hopefully, MFA will be mandated soon to solve this problem.
Cant the owner of the service implement it this way you cannot sync passkey to other devices? How hard is it to hack that? Is this stored in the secure element?@@andrascser7235
Seems like it's a copy of SQRL Secure Quick Relabel Login. made about 2 years ago. Both have to run on each end but SQRL don't store your password on the server. Nice video. Thank you.
Interesting video, thanks guys. I love the user experience, but it seems that we would be totally reliant on secure access to the Google, Microsoft, xxx account to protect access to the keys right? I'd be interested to know how a user would keep track of which keys exist for access to a given account/service (e.g. for Tribank, how many passkeys do I have and where are they? How can I revoke one or more of them?). Should enrolment of a passkey remove a password from an account? If not, surely we still have potential password access issues remaining until either the password is set to be strong (full circle on the original problem) or removed entirely.
I know I'm two months late to this, but I just listened to a podcast episode that covers a lot of this! There was someone from Google and someone from Microsoft on and they did a great job of explaining these use cases and how things work between different ecosystems. It's called Android Bytes (by Esper), and the episode name was "What is a passkey and why should you care?"
The public key part of the passkey pair is sent to Google / Microsoft / Tri-Bank / PayPal / Whatever to register your passkey. This could actually be transmitted in the clear without any compromise in security as you need the Private Key part of the passkey pair in order to sign anything. The public key part of the passkey pair is used to verify that you have the private key. The private key does not leave the Secure Enclave of the device it is created on except for Apple's / Google's / Microsoft's servers (depending on the device it was created on) for sync across your other devices. As passkeys are biometric, it proves that you are the person who created the passkey, as well as having the device. So it's both something you are (biometrical proven), and something you have (the identity provider (Apple / Google / Microsoft) account the passkey was created for). The service should show a list of passkeys associated with the account and the device it was created on. This allows you to later revoke a key by simply removing its public key from the allowed keys in the database for the client. This would allow you to revoke any number of them. Passkeys should not remove a password from an account. In the event that you remove all passkeys from an account you still need a password to prove you are you. You should require a second factor in another way however to ensure a like level of security -- This time being something you know (The password) and something you have (the second factor device.) For this I would fall back to a FIDO USB key or Google Authenticator or Authy and not SMS. A Push notification to a device also works, as it only goes to devices already enrolled to get push notifications for that account.
If the passkey get synced with iCloud, doesn't this defeat the point of FIDO, since it is not tied to your hardware but to the Cloud? What if someone hacks my iCloud? Are we putting all of our eggs in the same basket, or am I missing something? If so, I think we should just keep using password and using passkeys only as 2FA
If my passkey stays on my device, how is it that the cloud is able to “sync” with it? I have learned that the only way to guarantee privacy is by NEVER giving out your personal info.
This is something that's often not mentioned with syncing passkeys - only an encrypted copy is stored in the cloud. So even Apple or Google can't access or use your passkeys. They are decrypted on your device using a PIN or password. And if you still don't trust Apple or Google to securely manage your passkeys, you can also use a hardware FIDO2 key like YubiKey, or use a password manager that supports passkeys (I think 1Password, Bitwarden and Dashlane have announced that they will support passkeys soon).
Is there a separate passkey (FIDO keypair) for each service I am signing into? Or, is there only one passkey associated with one identity that can then access all services? (e.g if I currently have 40 passwords for 40 services, will they be replaced with 40 FIDO keypairs? Or, just one keypair that now allows me to access all 40 services?)
You'll end up with 40 FIDO key pairs. A key pair is tied to the URL of the authentication server. With proper JS provided by the auth server, your browser will be able to (suggest) autofill based on the URL.
Isn't the weak link the biometrics? I can open my mother's iPhone by pointing it at my face, even when I am wearing glasses (she does not wear glasses). Works consistently. On the other hand, I have to constantly reset my Google Pixel fingerprint imprint, because it stops working. If biometrics are that unreliable, doesn't that affect the security of the passkey system?
Passkeys still reduce the attack surface to a smaller area - an attacker must have physical access to your device, whereas with passwords, remote attacks are possible (and very common, actually). I guess if you don't trust your family or housemates, you shouldn't leave your devices laying arround.
At minute 2:34, I'm seeing the edge browser calling in a chrome sheet when verifying identity. This is after the presenter already created the passkey on the chrome browser on the android phone. Does this mean Tribank knows to ask for an android passkey? Can anyone explain this??
Not following. The browser UI is from Edge and allows the user to say they want to sign in with a passkey from another device (Android, iOS, or FIDO security key).
You go into your passkey provider, like Google, security setting, go into the passkey section, pick the device that you have your passkey on and remove the permission.
for using the android phone on Windows, you said that it connected via blue tooth. is it just connecting the blue tooth. any other steps needs to be done?
The Bluetooth connection happens automatically in the background. Also, it isn't actually a Bluetooth pairing, more like "linking" just to verify that the devices are in physical reach of each other. On the phone, you will then have to confirm that you want to login.
1. You could just use a phone, which already has a fingerprint or FaceID scanner. 2. If your laptop doesn't have biometrics (fingerprint or face recognition scanner), it might still be possible to set up passkeys using a PIN. And since this PIN only works locally on your laptop, which is in your home where hopefully no unauthorized person has access to, it still is more secure than passwords which work from everywhere. You can maybe check if your laptop supports Windows Hello. 3. Or you could also use a FIDO2 hardware security key, such as a YubiKey. In that case, the passkeys would be stored securely on the hardware key, which you plug in every time you want to login.
What if you only use a Desktop? I have an android phone, but I never use it for browsing, banking etc so I dont need a sign in on that. Do you have to buy a fingerprint device for the PC? I dont use laptops
I think this depends on the possibilities of your PC. If it doesn't have biometrics (fingerprint or face recognition scanner), it might still be possible to set up passkeys using a PIN. And since this PIN only works locally on your PC, which is in your home where hopefully no unauthorized person has access to, it still is more secure than passwords which work from everywhere. You can maybe check if your PC supports Windows Hello. Or you could also use a FIDO2 hardware key, such as a YubiKey. In that case, the passkeys would be stored securely on the hardware key, which you plug in every time you want to login.
Google completely broken security keys support while they were actually migrating to passkeys on yubikeys instead of earlier way of support. What a mess. Does the owner of the device has an option to block sync? Actually the flaw is if one can attack account used to sync they can still phish user and acquire passkey on their device. Correct?
Can I develop my native mobile app (iOS or Andriod) with passkey support? Some people said we must use webview or webauthn. Does iOS and Andriod support passkey by their own API (not webview)?
This will _always_ be an attack vector that cannot be fully secured against. If your device is compromised, no one but you can really do anything to protect you. They can _try_ to mitigate the damage (e.g. with a secure enclave on device), but in the end you, yourself, have to take your own measures, and in case of a breach, take the steps to invalidate those keys at their respective services. Passkeys could make this step much easier, compared to passwords, because passkeys are associated with the identity provider. This means there could be a form of automatic revocation and renewal system in place in case you get compromised and need to reset everything. Whether they do this now is unknown, but I could see this as a possibility.
I'm worried that the registration sequence in the video maybe arbitrary or a tad confected (IIUC) Have you not glossed over a potential and very undesirable requirement of a website's user's having to answer "Hey we see you have a platform authenticator (eg: Windows Hello) Would you like to use that or we'll take a punt on Bluetooth? Ah, hold on, you're login to Google on this device how about that?" Why not just list "Platform authenticator" (obviously something by a differnt name 🙂) allong with Android phone, Other sign in, etc? Also if it's a shared computer, how many times do you/we keep asking the user if they'd like a local credential? Once again, Well done to *all* involved. This stuff is awesome!👍
Nice to see this becoming reality slowly! :) But: If I register a Windows device as the first device, I'll still need to register an iPhone or Android with a password, right? :/
I'll post a link on the regular comments. as I a'm sure the creator of SQRL spent years thinking of every possible problem and he has already solved the issues and he has no problem sharing with anyone.
It was also my question: for a newly user signing up, if passkey enrollment is enforced at signup, there is no need to provide a password as shown in 1:18, it should then be fine to go with ID-first approach (username only) at login. No real need for a password on (in this example) Tri-Bank side then at all. As long as they user has sufficient passkeys/devices enrolled, he's able to login/recover.
The primary question that comes to mind: How do I keep my PassKey safe from the big data hoarders - Google, Microsoft, Apple (and Meta)? What happens when (not if, when) their storage is inevitably compromised at some point in the future?
They wouldn't have the passkey they only provide the service. There are independent companies, like 1password (and just about every other password vault, that also will support passkey.
Sure would be nice to add some serious and completely thought out solving of the Authentication problem...as in sqrl from grc (do a web search) instead of just an incremental but still flawed authentication improvement that's going to need another revamp in 10 more years. FIDO Passkey's are still reliant on 3rd party data synchronizers (apple, google, microsoft etc), and have vendor lock-in. Of course consumer lock-in on technologies and platforms is standard business practices in the 21st century :(
This is no different than having a Certificate Authority for issuing certificates so you can connect securely to a website over TLS, for example. In fact, it's the exactly the same mechanism. It's about who you (the client) and the identity provider trusts, rather than solely on one or the other. The thing with authentication (and identity in general) is that there just isn't a better option without some authority that you can rely on at some point. A decentralized solution won't eliminate the trust factor, and could make it even worse considering that you don't have a single authority to trust on (violating the whole decentralization part). There are more than just Apple, Google and Microsoft that can be used as certificate authorities; Yubico (YubiKey) and Nitrokey are also possible to be used as authorities. But the limitation is that both you and the identity provider has to at least trust a common authority (or more) together in order to establish a secure connection or validating a passkey. Let's say that we allowed the identity provider to act as an authority. In that case we'd be back to the problem that passwords (and other secret-based authentication mechanisms) have; trusting the identity provider to be provide a secure service and prevents any form of data leak that could compromise their root keys and therefore compromise users and their secrets-which we know from experience doesn't work. This would also not be possible to just invalidate your key against said identity provider, because you trusted them in the first place, so you have to question whether you would trust them a second time. Having multiple authorities (of which there are others as well), we can choose which authorities to trust. Whether you choose to trust Apple, Microsoft or any of the other authorities is up to you as a user, not solely the identity provider. So it's not just that it's standard practice, it's that there really isn't any option that allows for true decentralized identity management without the trust factor.
@@silversword411 The problem with SQRL is that it relies on the user not being compromised in one way or another. One issue is that it's highly susceptible to phising attacks. The SQRL app will accept any valid QR and any identity provider (including a malicious actor) can create such QR codes with the intent to trick you to beliving it is the correct site. Of course they added additional protection against this sort of attack. The problem is that it now relies on having an agent (in-browser) which checks the IP comes from the server that you made the authentication request from. But this goes against the whole idea of SQRL, moving authentication to your phone-and this is only if you're not using QR codes. Passkeys (FIDO U2F) circumvents this by having an authority that can authenticate both the user _and_ the provider and that the users token can only be used from the device it is attached to for that specific provider. This is just one of many flaws that SQRL has. It is often more difficult to use without the benefit of more security against the most _common_ attacks, such as phising.
As a person with no education on this subject i have no ability to conclude if this safe or not. And i just have to 'trust' that it is safe. It is more easy to understand if a password is safe or unsafe. This aspect of the security on digital platforms is often overlooked.
How do you know passwords are safe? I mean yes, you can tell if a password is strong or not, but you can't verify if the authentication system of a website is actually secure. Every website nowadays uses a different authentication system. Some offer multi-factor authentication, some don't. Vulnerabilities or data breaches, sometimes even revealing clear-text passwords, are possible and have happened in the past. Passkeys are an open standard by the FIDO Alliance, which means it can be verified by everyone. Because passkeys are phishing-resistant and don't have a shared secret by design (and are therefore not at risk for data breaches, at least not for the login credentials), they are more secure than passwords already.
@@sibu7 it can be verified by anyone with the proper education/knowledge. I and all other without knowledge in this subject still has to trust the companies that push the different solutions.
I don't see the real security here: all is based on fingerprints on your devices and some cloudy servers. What if this single authentication is not available? What if the devices get lost / damaged? What if a security hole is detected? You always need the secret security in the head of the user - not on the machine or on the finger. The video just shows "look, you will get better passwords that you don't have to remember" ... it says nothing about how secure the hole thing.
Did you miss the phishing resistance, unique passkeys per website and no remote credential theft benefits? If one of your devices get lost, you can still access your passkeys if you have stored them in Apples iCloud or Google Password Manager (more password managers will support passkeys in the future). If you somehow lost all your devices and don't have access to your passkey provider anymore, you should have a backup or recovery login method available, similar to how you can already reset your credentials if you forgot your password or second factor.
This is not a very smart move, for example, if my password leaks, I can change it. However, if your biometry data leaks into the internet, what are you gonna do? Replace your face? Replace your fingers? *Biometry is unique,* there is no replacements or second chance. Now, what if there is a robbery, the guy try to steal your phone and take you with them or kills you. With password, there is no way they can recover it, with passkeys (and biometry overall), all they have to do is to scan your face? Or scan your finger? We don't need to go that far, if you are a journalist in a war zone and got capture, all they have to do is to scan your face or fingers to unlock whatever you have protected by passkeys. If a red country collects your biometric data and brute force against the system, this can cause a security breakdown, and expose the whole system (how the system will know if is really you or someone pretending to be you with spoof data), all they have to do is to break one to reach the rest since they are all interconnected, the whole system can fall like dominoes.
In WebAuthn, you don't share your biometrics with the server. What the server has is a public key and your device has the private key, your device won't sign the message except when you approve the request by any supported method on the OS. On Andriod, or Windows that can be your PIN, pattern or anything.
@@melkalioby So, if the user device get compromised or stolen (very easy these days) the criminal can *run a program in the background to capture whatever they need,* get my private key and *unlock ALL the services encrypted with it* (Google, Microsoft, Apple, etc). Basic security 101 - WE DON'T TRUST THE USER.
@@coisasnatv Nope, because the private key is stored in a secure hardware like TPM or Apple secure chip and your pin is required to decrypt the keys to be able to sign. This is much secure than any other solution available today
@@melkalioby TikTok among other software already capture biometric data (among other data, not to say key loggers, etc), if the hardware is compromised, criminals doesn't need to broke TPM or Apple secure chip, people are already giving these for free. And if your hardware security uses biometric data to access your private key, this is way less secure than passwords.
2:33 So When you try to login to a website on a desktop PC, you can't log in without opening your phone -- after all, no fingerprint scanner or camera is available to login. Great "easy" solution! Of course, this only overcomplicates logging in. Sometimes people actually put down their phone and don't have access to it. Which in this setup means not being able to login. 13:50 "How much better"? This isn't better at all! We used to be able to login to our account with ONE password. Now we have to scramble for a phone to scan a QR code to get THREE passkeys (and be stuck creating passkeys again when we buy a new device.) This is NOT an improvement, but multiple steps back in user-friendly design. I hope the day that passwords get deleted NEVER comes. At least that way we have a backup method to access our data when this system fails spectacularly.
Another spam advert for passkeys. I guess adoption is not going as fast as you hoped. You still need to mark your ads on RUclips (or actually pay for them).
Nice try, but this style of the presentation does not work for newcomers. What'd I expect to hear (in simple English, better with illustrations or diagrams): 1. Why do I even need passkeys? What problems does it solve? 2. What is the technology behind passkeys? 3. How exactly does it protect me? 4. What hardware, software and skills do I need to have in order to use it? 5. How does it compare to similar technologies, e.g. TOTP? 6. What impact does it have on UX? 7. What happens if I loose my passkey or it is stolen by an adversory? 8. What are the known gotchas and drawbacks of passkeys? Only when this covered it'd be nice to see passkeys in action. P.S. I wrote this comment in the middle of the video. Then discovered that Tim Cappalli partially answed some of the questions. Sorry for my impatience.
Passkey is a totally useless thing. 1) When the phone is lost or broken, you still have to log in with a password to access the account, so how can you say Passkey will replace password and you don't need to remember the password. 2) When a bad guy gets your phone, they can't unlock it with fingerprint or face recognition, but they can unlock it with a PIN number. A PIN number is usually 4 or 6 digits. This is easier to figure out than a password, so how can it be called more secure than a password. 3) In the case where the bad guy doesn't have your phone, they will pretend that the phone is lost or broken to be able to enter the password. So what is passkey called more secure. 4) The password is in my head. In the event of being threatened, I may not provide the password even if I am killed. The passkey is on the outside. If threatened, the bad guy will use my finger or face to unlock the phone easily. So how can Passkey be called more secure.
You can use a password manager to store your passkeys. Bitwarden and KeepassXC will let you create and store passkeys someday. 1Password does those things already.
Наука
This demo was brilliant. Clear flows, clear verbal explanation. Bravo and thank you.
if passkeys are stored "on device" and "in the cloud", then how much does this increase the dependency on companies like Google, Apple and Microsoft? will it still be possible to have a separate password manager that stores a passkey instead? modern authentication should not fuel vendor lock-in!
passkey is actually a FIDO credential token to say - you dont need to store them "on" enddevice or cloud - you can also store it on a Security Key like Yubico - you can then also plug that USB Stick in your Linux Workstation and authenticate there with it.
So you see there is no Google, Apple, Microsoft involved here. However i think in 10 years probably 99,99 % will use it by them because its convenient.
@@WLLiLLWso can you use yubikey instead of buying a a fingerprint sensor?
@@JasonLee-ue7er yes that is the only available option on Linux to my knowledge
Yes. Every password manager will eventually have a passkey option.
Good to see Google, Microsoft, Apple and others working together to realise FIDO2 passkeys on devices.
Best demo on the subject I have seen so far. Some things were not fully clear for me though.
- What happens if I create first passkey on a computer that does not have a camera? What will be the other options to spread to the other devices?
- What medium is used to "remember the device" notification (mentioned, but not demoed) from the computer to the phone?
- If someone shoul break into my Google or iCloud or MS account, how it is avoided that the hacker will have access to each and every service I use?
1. fingerprint
2. bluetooth
Regarding your last question, for Apple at least it is not enough to compromise the iCloud account - you also need to have access to one of the existing enrolled devices for that account.
They've shown u the happy path. Going from windows to mobile doesn't work currently.
Regarding the last question: this is the weakness of Passkeys. You need to have multi-factor authentication (MFA) on your Google and Apple accounts. Apple lately enforces this, Google is slower in its enforcement. Hopefully, MFA will be mandated soon to solve this problem.
Cant the owner of the service implement it this way you cannot sync passkey to other devices? How hard is it to hack that? Is this stored in the secure element?@@andrascser7235
Thanks for the great video and for covering user experience.
This is such a great demo and explanation! Great work
Great demo thank you... I guess it doesn't work on computers without fingerprint sensors?
Seems like it's a copy of SQRL Secure Quick Relabel Login. made about 2 years ago. Both have to run on each end but SQRL don't store your password on the server. Nice video. Thank you.
Interesting video, thanks guys. I love the user experience, but it seems that we would be totally reliant on secure access to the Google, Microsoft, xxx account to protect access to the keys right? I'd be interested to know how a user would keep track of which keys exist for access to a given account/service (e.g. for Tribank, how many passkeys do I have and where are they? How can I revoke one or more of them?). Should enrolment of a passkey remove a password from an account? If not, surely we still have potential password access issues remaining until either the password is set to be strong (full circle on the original problem) or removed entirely.
I know I'm two months late to this, but I just listened to a podcast episode that covers a lot of this! There was someone from Google and someone from Microsoft on and they did a great job of explaining these use cases and how things work between different ecosystems. It's called Android Bytes (by Esper), and the episode name was "What is a passkey and why should you care?"
The public key part of the passkey pair is sent to Google / Microsoft / Tri-Bank / PayPal / Whatever to register your passkey. This could actually be transmitted in the clear without any compromise in security as you need the Private Key part of the passkey pair in order to sign anything. The public key part of the passkey pair is used to verify that you have the private key. The private key does not leave the Secure Enclave of the device it is created on except for Apple's / Google's / Microsoft's servers (depending on the device it was created on) for sync across your other devices. As passkeys are biometric, it proves that you are the person who created the passkey, as well as having the device. So it's both something you are (biometrical proven), and something you have (the identity provider (Apple / Google / Microsoft) account the passkey was created for).
The service should show a list of passkeys associated with the account and the device it was created on. This allows you to later revoke a key by simply removing its public key from the allowed keys in the database for the client. This would allow you to revoke any number of them.
Passkeys should not remove a password from an account. In the event that you remove all passkeys from an account you still need a password to prove you are you. You should require a second factor in another way however to ensure a like level of security -- This time being something you know (The password) and something you have (the second factor device.) For this I would fall back to a FIDO USB key or Google Authenticator or Authy and not SMS. A Push notification to a device also works, as it only goes to devices already enrolled to get push notifications for that account.
If the passkey get synced with iCloud, doesn't this defeat the point of FIDO, since it is not tied to your hardware but to the Cloud?
What if someone hacks my iCloud?
Are we putting all of our eggs in the same basket, or am I missing something? If so, I think we should just keep using password and using passkeys only as 2FA
Your private key stays on your device, not the cloud.
If my passkey stays on my device, how is it that the cloud is able to “sync” with it? I have learned that the only way to guarantee privacy is by NEVER giving out your personal info.
This is something that's often not mentioned with syncing passkeys - only an encrypted copy is stored in the cloud. So even Apple or Google can't access or use your passkeys. They are decrypted on your device using a PIN or password. And if you still don't trust Apple or Google to securely manage your passkeys, you can also use a hardware FIDO2 key like YubiKey, or use a password manager that supports passkeys (I think 1Password, Bitwarden and Dashlane have announced that they will support passkeys soon).
Is there a separate passkey (FIDO keypair) for each service I am signing into? Or, is there only one passkey associated with one identity that can then access all services? (e.g if I currently have 40 passwords for 40 services, will they be replaced with 40 FIDO keypairs? Or, just one keypair that now allows me to access all 40 services?)
You'll end up with 40 FIDO key pairs. A key pair is tied to the URL of the authentication server. With proper JS provided by the auth server, your browser will be able to (suggest) autofill based on the URL.
Isn't the weak link the biometrics? I can open my mother's iPhone by pointing it at my face, even when I am wearing glasses (she does not wear glasses). Works consistently. On the other hand, I have to constantly reset my Google Pixel fingerprint imprint, because it stops working. If biometrics are that unreliable, doesn't that affect the security of the passkey system?
Passkeys still reduce the attack surface to a smaller area - an attacker must have physical access to your device, whereas with passwords, remote attacks are possible (and very common, actually). I guess if you don't trust your family or housemates, you shouldn't leave your devices laying arround.
does passskeys support face id (using windows hello)?
At minute 2:34, I'm seeing the edge browser calling in a chrome sheet when verifying identity. This is after the presenter already created the passkey on the chrome browser on the android phone. Does this mean Tribank knows to ask for an android passkey? Can anyone explain this??
Not following. The browser UI is from Edge and allows the user to say they want to sign in with a passkey from another device (Android, iOS, or FIDO security key).
How does one un-enroll a specific device when multiple devices are sharing the same key?
You go into your passkey provider, like Google, security setting, go into the passkey section, pick the device that you have your passkey on and remove the permission.
for using the android phone on Windows, you said that it connected via blue tooth. is it just connecting the blue tooth. any other steps needs to be done?
The Bluetooth connection happens automatically in the background. Also, it isn't actually a Bluetooth pairing, more like "linking" just to verify that the devices are in physical reach of each other. On the phone, you will then have to confirm that you want to login.
I am unclcar, Does this require a finger point scanner on the laptop?
1. You could just use a phone, which already has a fingerprint or FaceID scanner.
2. If your laptop doesn't have biometrics (fingerprint or face recognition scanner), it might still be possible to set up passkeys using a PIN. And since this PIN only works locally on your laptop, which is in your home where hopefully no unauthorized person has access to, it still is more secure than passwords which work from everywhere. You can maybe check if your laptop supports Windows Hello.
3. Or you could also use a FIDO2 hardware security key, such as a YubiKey. In that case, the passkeys would be stored securely on the hardware key, which you plug in every time you want to login.
No
What if you only use a Desktop? I have an android phone, but I never use it for browsing, banking etc so I dont need a sign in on that. Do you have to buy a fingerprint device for the PC? I dont use laptops
I think this depends on the possibilities of your PC. If it doesn't have biometrics (fingerprint or face recognition scanner), it might still be possible to set up passkeys using a PIN. And since this PIN only works locally on your PC, which is in your home where hopefully no unauthorized person has access to, it still is more secure than passwords which work from everywhere. You can maybe check if your PC supports Windows Hello. Or you could also use a FIDO2 hardware key, such as a YubiKey. In that case, the passkeys would be stored securely on the hardware key, which you plug in every time you want to login.
You can use a PIN for passkeys on your phone and/or desktop.
Google completely broken security keys support while they were actually migrating to passkeys on yubikeys instead of earlier way of support. What a mess.
Does the owner of the device has an option to block sync? Actually the flaw is if one can attack account used to sync they can still phish user and acquire passkey on their device. Correct?
Can I develop my native mobile app (iOS or Andriod) with passkey support? Some people said we must use webview or webauthn. Does iOS and Andriod support passkey by their own API (not webview)?
The video suggested that mobile apps work also, using the device's native APIs. See 1:54.
If a phone has it's EIN cloned, will that allow it to be used as a persons passkey device?
No. There is no relationship.
How is the private key secured on device? I’m thinking of the risk of being hacked and my private key from my passkey keypair being exposed.
This will _always_ be an attack vector that cannot be fully secured against. If your device is compromised, no one but you can really do anything to protect you. They can _try_ to mitigate the damage (e.g. with a secure enclave on device), but in the end you, yourself, have to take your own measures, and in case of a breach, take the steps to invalidate those keys at their respective services.
Passkeys could make this step much easier, compared to passwords, because passkeys are associated with the identity provider. This means there could be a form of automatic revocation and renewal system in place in case you get compromised and need to reset everything. Whether they do this now is unknown, but I could see this as a possibility.
I'm worried that the registration sequence in the video maybe arbitrary or a tad confected (IIUC) Have you not glossed over a potential and very undesirable requirement of a website's user's having to answer "Hey we see you have a platform authenticator (eg: Windows Hello) Would you like to use that or we'll take a punt on Bluetooth? Ah, hold on, you're login to Google on this device how about that?" Why not just list "Platform authenticator" (obviously something by a differnt name 🙂) allong with Android phone, Other sign in, etc? Also if it's a shared computer, how many times do you/we keep asking the user if they'd like a local credential?
Once again, Well done to *all* involved. This stuff is awesome!👍
Bluetooth, what?
What about linux support?
Ty Ty Ty
Nice to see this becoming reality slowly! :) But: If I register a Windows device as the first device, I'll still need to register an iPhone or Android with a password, right? :/
I'll post a link on the regular comments. as I a'm sure the creator of SQRL spent years thinking of every possible problem and he has already solved the issues and he has no problem sharing with anyone.
It was also my question: for a newly user signing up, if passkey enrollment is enforced at signup, there is no need to provide a password as shown in 1:18, it should then be fine to go with ID-first approach (username only) at login. No real need for a password on (in this example) Tri-Bank side then at all. As long as they user has sufficient passkeys/devices enrolled, he's able to login/recover.
Only if you want to log in to to this service from those devices
timah mana😑
The primary question that comes to mind: How do I keep my PassKey safe from the big data hoarders - Google, Microsoft, Apple (and Meta)? What happens when (not if, when) their storage is inevitably compromised at some point in the future?
They are end-to-end encrypted.
@@timcappalli619 Which helps me not at all if it's stored insecurely...
You can use hardware security keys like Yubikey.
@@FelixFischer Which helps me none at all if it isn't safe on the server side
They wouldn't have the passkey they only provide the service.
There are independent companies, like 1password (and just about every other password vault, that also will support passkey.
Sure would be nice to add some serious and completely thought out solving of the Authentication problem...as in sqrl from grc (do a web search) instead of just an incremental but still flawed authentication improvement that's going to need another revamp in 10 more years. FIDO Passkey's are still reliant on 3rd party data synchronizers (apple, google, microsoft etc), and have vendor lock-in. Of course consumer lock-in on technologies and platforms is standard business practices in the 21st century :(
This is no different than having a Certificate Authority for issuing certificates so you can connect securely to a website over TLS, for example. In fact, it's the exactly the same mechanism. It's about who you (the client) and the identity provider trusts, rather than solely on one or the other.
The thing with authentication (and identity in general) is that there just isn't a better option without some authority that you can rely on at some point. A decentralized solution won't eliminate the trust factor, and could make it even worse considering that you don't have a single authority to trust on (violating the whole decentralization part).
There are more than just Apple, Google and Microsoft that can be used as certificate authorities; Yubico (YubiKey) and Nitrokey are also possible to be used as authorities. But the limitation is that both you and the identity provider has to at least trust a common authority (or more) together in order to establish a secure connection or validating a passkey.
Let's say that we allowed the identity provider to act as an authority. In that case we'd be back to the problem that passwords (and other secret-based authentication mechanisms) have; trusting the identity provider to be provide a secure service and prevents any form of data leak that could compromise their root keys and therefore compromise users and their secrets-which we know from experience doesn't work. This would also not be possible to just invalidate your key against said identity provider, because you trusted them in the first place, so you have to question whether you would trust them a second time.
Having multiple authorities (of which there are others as well), we can choose which authorities to trust. Whether you choose to trust Apple, Microsoft or any of the other authorities is up to you as a user, not solely the identity provider.
So it's not just that it's standard practice, it's that there really isn't any option that allows for true decentralized identity management without the trust factor.
@@dealloc you are incorrect. Do the search for sqrl and read up on it. There is no authority requirement.
@@silversword411 The problem with SQRL is that it relies on the user not being compromised in one way or another. One issue is that it's highly susceptible to phising attacks. The SQRL app will accept any valid QR and any identity provider (including a malicious actor) can create such QR codes with the intent to trick you to beliving it is the correct site.
Of course they added additional protection against this sort of attack. The problem is that it now relies on having an agent (in-browser) which checks the IP comes from the server that you made the authentication request from. But this goes against the whole idea of SQRL, moving authentication to your phone-and this is only if you're not using QR codes.
Passkeys (FIDO U2F) circumvents this by having an authority that can authenticate both the user _and_ the provider and that the users token can only be used from the device it is attached to for that specific provider.
This is just one of many flaws that SQRL has. It is often more difficult to use without the benefit of more security against the most _common_ attacks, such as phising.
cloud gets hacked, now what? How are my private keys protected from attackers getting access to my accounts? Asymmetric cryptography this that?
As a person with no education on this subject i have no ability to conclude if this safe or not. And i just have to 'trust' that it is safe. It is more easy to understand if a password is safe or unsafe. This aspect of the security on digital platforms is often overlooked.
How do you know passwords are safe? I mean yes, you can tell if a password is strong or not, but you can't verify if the authentication system of a website is actually secure. Every website nowadays uses a different authentication system. Some offer multi-factor authentication, some don't. Vulnerabilities or data breaches, sometimes even revealing clear-text passwords, are possible and have happened in the past.
Passkeys are an open standard by the FIDO Alliance, which means it can be verified by everyone. Because passkeys are phishing-resistant and don't have a shared secret by design (and are therefore not at risk for data breaches, at least not for the login credentials), they are more secure than passwords already.
@@sibu7 it can be verified by anyone with the proper education/knowledge. I and all other without knowledge in this subject still has to trust the companies that push the different solutions.
I don't see the real security here: all is based on fingerprints on your devices and some cloudy servers. What if this single authentication is not available? What if the devices get lost / damaged? What if a security hole is detected? You always need the secret security in the head of the user - not on the machine or on the finger.
The video just shows "look, you will get better passwords that you don't have to remember" ... it says nothing about how secure the hole thing.
Did you miss the phishing resistance, unique passkeys per website and no remote credential theft benefits? If one of your devices get lost, you can still access your passkeys if you have stored them in Apples iCloud or Google Password Manager (more password managers will support passkeys in the future). If you somehow lost all your devices and don't have access to your passkey provider anymore, you should have a backup or recovery login method available, similar to how you can already reset your credentials if you forgot your password or second factor.
This is not a very smart move, for example, if my password leaks, I can change it. However, if your biometry data leaks into the internet, what are you gonna do?
Replace your face? Replace your fingers?
*Biometry is unique,* there is no replacements or second chance.
Now, what if there is a robbery, the guy try to steal your phone and take you with them or kills you. With password, there is no way they can recover it, with passkeys (and biometry overall), all they have to do is to scan your face? Or scan your finger?
We don't need to go that far, if you are a journalist in a war zone and got capture, all they have to do is to scan your face or fingers to unlock whatever you have protected by passkeys. If a red country collects your biometric data and brute force against the system, this can cause a security breakdown, and expose the whole system (how the system will know if is really you or someone pretending to be you with spoof data), all they have to do is to break one to reach the rest since they are all interconnected, the whole system can fall like dominoes.
.
In WebAuthn, you don't share your biometrics with the server. What the server has is a public key and your device has the private key, your device won't sign the message except when you approve the request by any supported method on the OS. On Andriod, or Windows that can be your PIN, pattern or anything.
@@melkalioby So, if the user device get compromised or stolen (very easy these days) the criminal can *run a program in the background to capture whatever they need,* get my private key and *unlock ALL the services encrypted with it* (Google, Microsoft, Apple, etc).
Basic security 101 - WE DON'T TRUST THE USER.
@@coisasnatv Nope, because the private key is stored in a secure hardware like TPM or Apple secure chip and your pin is required to decrypt the keys to be able to sign. This is much secure than any other solution available today
@@melkalioby TikTok among other software already capture biometric data (among other data, not to say key loggers, etc), if the hardware is compromised, criminals doesn't need to broke TPM or Apple secure chip, people are already giving these for free. And if your hardware security uses biometric data to access your private key, this is way less secure than passwords.
2:33 So When you try to login to a website on a desktop PC, you can't log in without opening your phone -- after all, no fingerprint scanner or camera is available to login.
Great "easy" solution! Of course, this only overcomplicates logging in. Sometimes people actually put down their phone and don't have access to it. Which in this setup means not being able to login.
13:50 "How much better"? This isn't better at all! We used to be able to login to our account with ONE password. Now we have to scramble for a phone to scan a QR code to get THREE passkeys (and be stuck creating passkeys again when we buy a new device.) This is NOT an improvement, but multiple steps back in user-friendly design. I hope the day that passwords get deleted NEVER comes. At least that way we have a backup method to access our data when this system fails spectacularly.
sure, let's store our private keys in the cloud, why not??
this is stupid. hardware wallets are already the solution in place.
Another spam advert for passkeys.
I guess adoption is not going as fast as you hoped.
You still need to mark your ads on RUclips (or actually pay for them).
Nice try, but this style of the presentation does not work for newcomers.
What'd I expect to hear (in simple English, better with illustrations or diagrams):
1. Why do I even need passkeys? What problems does it solve?
2. What is the technology behind passkeys?
3. How exactly does it protect me?
4. What hardware, software and skills do I need to have in order to use it?
5. How does it compare to similar technologies, e.g. TOTP?
6. What impact does it have on UX?
7. What happens if I loose my passkey or it is stolen by an adversory?
8. What are the known gotchas and drawbacks of passkeys?
Only when this covered it'd be nice to see passkeys in action.
P.S. I wrote this comment in the middle of the video.
Then discovered that Tim Cappalli partially answed some of the questions. Sorry for my impatience.
Android is so ugly
Passkey is a totally useless thing.
1) When the phone is lost or broken, you still have to log in with a password to access the account, so how can you say Passkey will replace password and you don't need to remember the password.
2) When a bad guy gets your phone, they can't unlock it with fingerprint or face recognition, but they can unlock it with a PIN number. A PIN number is usually 4 or 6 digits. This is easier to figure out than a password, so how can it be called more secure than a password.
3) In the case where the bad guy doesn't have your phone, they will pretend that the phone is lost or broken to be able to enter the password. So what is passkey called more secure.
4) The password is in my head. In the event of being threatened, I may not provide the password even if I am killed. The passkey is on the outside. If threatened, the bad guy will use my finger or face to unlock the phone easily. So how can Passkey be called more secure.
You can use a password manager to store your passkeys. Bitwarden and KeepassXC will let you create and store passkeys someday. 1Password does those things already.