Diffie-Hellman key exchange paper was published in 1976. RSA came in 1977. PGP in the 90s. 2011-2013 Facebook SSL/TLS by default. 2012 HSTS RFC release. It has been a looooong and slow journey.
Indeed, essentially that's what PGP does. Problem is that now hackers will go after the keypass server, and with that they just got unlimited passkeys by pairing it with user's public key. There are always pros and cons with virtually everything.
Right, and now hackers will go after the passkey server, and with that they just got unlimited passkeys by pairing it with user's public key. There are always pros and cons with virtually everything.
@@Megaranator some password managers like 1password store passkeys in their servers. Device passkeys might also be stored somewhere else when it's not physical key and could also be stolen by malicious software. And if it's a physical key, then manufacturer could be storing origin keys without your knowledge. Buying a physical key from someone is like asking other company to create your password. In all, passkeys are worse than long good passwords since it's cryptographic keys are stored in digital media. Add simple 2FA TOTP and it's good enough.
Part of the problem with help desk calls over forgotten/lost passwords is because jobs require you to "change" your password every 3 months, meaning most people need to write down a new password 4 times a year or they'll do the human behavior of only changing 1 or 2 characters until they can repeat the same passwords, making their "new" password easier to guess and lowering the security of passwords.
If soneone has a good password, changing 2-3 chars doesn't make it easy to guess. If you have a key logger in your system you can have all the fancy protection and won't help.
This password changing bullshit is SO ANNOYING and really isn't needed. And yes people come up with the simplest password possible knowing they'll have to changebit soon anyways
Yeah, 90 day password rotations are insane when you already need like 8+ characters, special, number, capital, etc. Meanwhile my PHYSICAL access 4 digit combo (lmao) has been the same for 6 years.
Heh, I work for a company that has the 90 day forced password change on their Windows domain. I work offsite now but at the time I didn't run Windows and I only ever logged into the Windows Domain via the Exchange server through Thunderbird... there's no mechanism for the forced password change in Thunderbird so every 90 days I would just stop getting any emails. I eventually convinced them to set my password expiry to "never."
When I describe the asymetric cryptografic concept, my favourite sample is a padlock. You have a partner you want to share something with Your partner is too far away to share it personally to keep it secure Public postal service is the only transport way So... You buy a brand new padlock You keep the key in your pocket and send the padlock to your partner Your partner buys a box, puts the secret in the box and locks it with the padlock (and is so not able to open the box anymore) He sends the box to you You open the box with the key in your pocket. Padlock = Public Key Key = Private Key
Nice explanation. An asymmetric key pair has two keys, and both can be used to encrypt and decrypt a message. What makes the padlock "public" is that is sent over the network and should never be trusted, because someone might have seen its mechanism of encryption.
7:20 Important to highlight that a Diffie-Hellmann-Exchange and asymmetric Encryption are two completly separate things. One is used to anonymously exchange keys, the other can be used to sign or encrypt data
@@Melvin420x12 challenge accepted. luckily for me I made a full arbitrary bit length base rsa implementation in js in 2012 from the ground up, and a php rsa implementation using gmp for end to end encryption for my home brew rich chat server... all free for any use and open source- no integrated license. are we taking mechanics or a deep dive on the processes behind it, Or a discussion of the top level programs that use it that end users will be exposed to? or just a live rewatch of this video with tangent cut aways to fill in missing info? I'll always say that the best way to understand these things is to go code them yourself. let me know if you can solve the division issue. I gave up optimizing it over a decade ago.
@@Melvin420x12 apparently my reply got deleted. didn't say anything off... no links, no mention of any other site or self promo.... just a description of my previous efforts in rsa.
These are literally just the next natural thing to do after acknowledging that the best option for everyone is using a password manager; at which point the passwords in that password manager might as well be a private key instead of just a random block of text. It still has the same user end problems that (1) you're in a mess if you lose the password manager itself, and (2) that you still need to make the password manager itself secure, which always comes back to needing a password. But making a standard around essentially forcing users to use a slightly more clever password manager makes sense.
yeah. auth apps which do not let the keys out again. Posibility of having a second key for the site, login data is also something. Only e.g. passkey or another solution, in one yubikey etc. How to 'back up' this? I do not have a working solution for this/for me. Or it's not practicall for things that are on the highest level of importants. Or how is the fall back? Often you can do a 2fa with yubikey etc, but when the fall back is still email or a phone number... I do see the benefits against phishing with passkey but I also feel not good with it when it's in a phone. e.G. Google/android. When you use googles auth app, your phone breaks or get's stollen and you have no other google account/phone which is active, you really have a tough time getting that account back, even when you have the password.
I'd say the risk is about the same if you lose the device, but significantly lower overall. I mean, even today, if you lose your device, and the thief could log in to your device, they'd likely have access to all of the accounts you check "keep me logged in" on, which likely includes email, which then includes nearly everything. Even still, if you lose your computer, it's a matter of invalidating the passkeys and you should be more or less safe. The point is: you'll know when you're breached, which is not the case with a password. Now, when you weigh that (worst-case) scenario with all the different ways passwords can be stolen/compromised/leaked/forgotten/etc., passkeys come out FAR on-top when it comes to security. The fact that with a passkey you can only sign in with the device (no way for remote account breaching), we're looking at a significantly smaller attack surface, with pretty much the only weakness being a thief with 1. physical access to your computer, and 2. knowledge of your computer password.
I think there's a relatively simple solution. Use a single password on the client side, use passkeys on the server-side. Passwords on the client side are used to decrypt the passkey into memory, use it, then immediately drop the memory. The server then can see the certificate is valid while never seeing your password. One might recognize a similarity to using an encrypted password manager that is accessed via your password. It's essentially the same thing, but now not even the server knows your real password, *nor* the passkey. Just the public key it corresponds to. This is simply far, far safer than what we have right now. And it comes with the added benefit of uniformity between large passkeys, meaning vulnerabilities like rainbow tables become utterly impractical. Now the only risk is you losing your password or writing it down somewhere. Rather than sending your password off to a server which is run by incompetents who end up leaking your password out, as we did in the old days. And still do, haha.
That's why you need to set a PIN or fingerprint for your passkey authenticator. Stealing a physical device is still way more effort than phishing, which is something that's effectively mitigated by using passkeys.
21:40 That 44 bits of entropy is not by guessing letters, It's by knowing the exact dictionary of words used. 11 bits per word means 2048 words. That wordlist was originally made for Bitcoin wallets with the BIP39 proposal. A list of 2048 unique, easy to distinguish words
Microsoft deserves more credit than is given. As far as back as Windows Vista there has been support for Trusted Platform Modules or TPM’s. These help store encryption keys and generate high entropy random numbers needed to generate strong keys.
Eh. I use a password manager and unique passwords for every site/service. I've also set my password manager to clear the clipboard after 2 minutes and to lock itself entirely after 15 minutes, so it's never left unlocked for long. Also, the password manager wouldn't suggest automatically filling in my credentials on a fake domain, so even if I fell for a phishing mail and did the dumb thing of clicking on a link there, I'd still notice something being wrong, because there'd be no prompt for me to unlock my password manager.
I do the same as you. Except for clearing the clipboard. Thanks for that recommendation. I usually enter the password first so that the last thing I copy is the username. But your idea is better for sure as different systems sometimes store the last N clipboard items. I believe this method is perfectly safe so long as your PW database is appropriately protected. No one is guessing those strong passwords. The entire reason people say "passwords suck" is actually because users suck. Only ONE member of my family uses a password manager. Everyone else does the same nonsense of reusing the same passwords and making them combos of words and numbers that have significance to them (i.e pet_name+birthday). And of course they STILL forget them all the time.
@@turc1656 Yeah, clearing the clipboard is something not that obvious, but it's yet another way one might accidentally leak passwords. Many (most?) password managers have support for setting a timeout for that, like e.g. KeePass and its forks and variants and bitwarden.
Yeah, exactly this. The only online password I truly have to remember is my Google account's password because all my passwords are stored in the password manager included with it. I just have a ludicrously difficult password for that Google account that is impossible to guess and have had it memorized for years now. It's better than having multiple passwords to remember, or passkeys for that matter. Also, I kind of hate how the trend in authentication is going towards mobile phone dependence. Like, for me, a phone is pretty much disposable, and in a place like Karachi, Pakistan, can easily get snatched. Some forms of 2fa legitimately leave you locked out in those cases.
Theo: Locking / unlocking are not roles of public/private keys respectively. Rather whatever is encrypted by one is only decrypted with the other. So I *secure* information by encrypting with my public key, and I *publish/authenticate* information by encrypting with my private key.
Passwords have a place in society. It's a what you know type of authentication and that is sometimes way more cost-effective in certain cases than a what you have or what you are
I don't think Theo or the writers care about real security protocols. Neither mention integration of auth chips to biometrics and passwords as a holistic system. They just want to talk about magical logins without the "effort" of passwords etc.
I do not like analogy of username/password. It is better treat them like a 2 functions, that are inverses of themself. You can use your private key to proof your identity: everyone can check that only you could encrypt that with your private key by calling your public key (it is public!), but you can use MY public key to encrypt something for me - only I can decrypt it with my private key.
Agreed! I've stopped watching this video after seven minutes, because Theo is getting a lot of things wrong here (his drawing on how public/private key cryptography works, stating that you can only encrypt with the public key (which is wrong, because you can encrypt with a private key and then decrypt that with the public key), confusing Diffie-Hellman with RSA)
You are right, I did the same. After 7 minutes it was too much for me, even I am not specialist in this matter. Dear Theo, please make something to keep it "legit" - we can help with some proof-reading or suggest some articles, but you need to make something with this - what you told was just bit too far from true and with your fanbase it will hurt the public if someone will not rectify it imho
Lol im just building passkey based auth right now for our uni project its great to see how passkeys are working and i can now say i have a deep understanding of the technology
as for the math of public key encryption, at a high level when you generate the keys it picks two really large prime numbers (relatively easy for a computer to find), and then multiplies them together, and that result is your public key, with the factors being your private key. it's _really_ computationally expensive (on normal computers) to factor a large number into two primes (you just have to brute force it basically)
Until there is a solid migration story in place, Passkeys are just a tool for vendors to create lock-in IMO. And the fact that it's being pushed so hard *before* a migration story is in place means that the lock-in is 100% the point. I don't trust it one bit.
@@PavitraGolchha depends on what manager you use for passkeys. This won’t be an issue for example if you use the native passwords app which is on all Apple devices.
@@PavitraGolchha Pretty sure Apple devices back up to iCloud and Google & Microsoft back up to their password managers as well. It's no different to if you lost your phone that you used to generate TOTP codes before, or a physical FIDO2/U2F security key.
I trust you Theo, so now by extension I trust passkeys. Well at least I’ll consider clicking yes the next time I’m prompted to use one. Thank you for the video, and thank you Clerk for the article
I use a password manager. Out of 516, 427 are compromised. To note, only 371 are reused, so there are more compromised passwords than reused passwords, that's at least 57 (56+1) breaches. It's just too much work to change all passwords, so I end up changing them only when I use a service I haven't used in a while or it's an important one.
Sounds like we can establish the same flow with password as well. No need "passkey" at all. Step 1. Server trusts multiple password hashes. Step 2. User auto-generates unique password on each device, and use biometric or any form of secure way to unlock that password during login. Done. Sweet and easy. The only difference is digital signature vs by plain text secret.
ok I'm wrong. In above approach, servers will see user's device-specific password. Meaning if user signed into one malicious server, the server can then use this password to login other websites. While using digital signature, servers cannot see any secret of the user.
Yeah, that's basically what we're doing. The asynchronous cryptography stuff is just to add a bunch of extra security, better prevent pfhishing, and all that juicy stuff. Your system covers the main bases though. But once you have that system, it seems silly to not use public key cryptography on top since it's effectively free. Of course, this assumes you're properly salting, peppering, and hashing your passwords.
I don't think this article addressed using multiple devices? do you store the passkey on the device, in the browser, in an extension, or what? edit: ok 30:45
Technically it's on the service to allow you to create multiple passkeys somehow. I was already working on implementing primarily-WebAuthn authentication for a bit now when this video came out and my scheme for multi-device auth is simple. You use an authenticated device (one that used a passkey to log in) to accept a request for a new passkey. New passkey requests themselves must be made with a password. This scheme is inherently less suceptable to social engineering since, with a decent UI, it's made clear to the user that they're authorizing a new device to use their account-not simply logging in. Even if the request password gets leaked somehow (password should be treated with normal levels of password security; salt, pepper, and hashing please), say through a phfishing site, the most they can do is do auth spam. The nice part, though? They can just reset their passkey request password and the auth spam goes away.
@@BellCube - That's exactly what this video's sponsor does, it's a master password repository for creating duplicates in case a device is lost or stolen. Basically entrusting your passkey's master password to some cloud service.... what could possibly go wrong?! lol
@@BillAnt Yeah... that's not the point of the comment. The point is that there are solutions for the key duplication problem that don't rely on passwords to keep themselves secure. The scheme I mentioned only uses passwords as a form of required MFA and everything possible is stored on the user's devices. No third-party providers in sight.
I agree with you with regards to SMS, HOWEVER, it gets used because everyone with a mobile phone (At least here in Australia, dunno about Backwards US where talk+text is charged.....) can basically receive an SMS.
I don't really understand how keys are better than just using a password manager. To me, they look very similar, you still need to store all those keys, so it's essentially the same thing but different color, isn't it?
Hi theo. I gotta say as a mathematician I'd love some level of depth when you try to explain concepts. It stops people from thinking everything math-realted is witchcraft. Still love your content!
I used to read Better Explained a lot because I was taught to remember math formula without understanding anything. Now I usually appreciates math a bit, a lot when it’s explained. The difficult part for me is that my foundation is so weak, I have to look up every concept that most explanation refers to.
@@RobGThaiImo the fact that you need to look up every concept math related is not only due to your lack of foundation, but also due to the way math works. Every definition, if not based on the axioms themselves is based on another definition. From those objects we derive properties and theorems (aka the truth). To understand any concept in math, you take a definition and start digging. You become good at math when you've digged enough and enough times that you don't need to look that many concepts anymore, because you know them. It's similar to learning a language, except instead of a dictionary of what a word means you need a degree-level experience to start to get it.
This appears to have the exact same secuirity level of using a password manager: - You generate passwords for every website - You rely on a tool to send and consume the authentication process - You create a single weak point on the security chain that is you instead of the server (as you still have an unique password in the password manager)
No, since Passkeys have phishing prevention. If you copy/paste the password into the wrong website, it’s compromised. But the passkey system ensures a hostile website can’t use the challenge response to log into your account.
@@diadetediotedio6918 That isn’t always possible, ex. desktop apps which use web login windows. And it doesn’t rely on the security of an SSL certificate matching the domain name to the server, since password managers can only do text matching (though I’d agree it’s very hard to have that happen).
@@Skyb0rg But it is possible, my point was not about "the lowest safer password manager", it was about password managers in general and their best capabilities. A steelman of this argument would follow this lines: "A good password manager with pishing protections (for example by having an extension in the browser that checks the certificates and stores them when creating accounts) and good password protections (for example, that never shows the user their passwords, that generates strong and safer passwords, that keeps them encrypted all the time but on the act of login, that never repeats passwords, that associates passwords created with the sites they were created, etc) equates in security level a passkey".
Passkeys are waaaay more secure than passwords for several reasons: 1. They are phishing resistant. Yes, password managers can help mitigate this risk, but only to a limited degree. The average user would probably think their PM is bugging out and mindlessly type in the password manually. 2. Passwords can be stolen even if you have good security practices. Data breaches happen all the time. With passkeys, even if a data breach occurs your authentication secret is not exposed. 3. Passkeys have cloning detection. Each time a passkey gets used, the auth response will contain a counter that monotonically increases. If the value ever decreases, that indicates someone cloned your passkey, and the web service can detect that to prevent unauthorized access. Lastly your password manager can also be protected using a passkey stored by a hardware key like a Yubikey. That provides the ultimate protection since you no longer have a master password which can be exposed.
Microsoft and Google deserve a little more credit. Passkeys (FORMERLY WebAuthn) was adopted by Edge and Firefox a few years before Safari got it. It wasn’t until Apple adopted it and gave it a fancy name did anyone pay attention.
To clarify, WebAuthN wasn't renamed to passkeys. Passkeys are a technology built on the FIDO2 spec, which in turn is composed of two protocols, WebAuthN and CTAP2. Passkeys are actually just a rebranding of FIDO2 resident credentials.
Wait, does this mean we can eliminate Oauth callbacks? That would save me so many headaches in cross-platform projects. Step 1: "Hey I'm me! Send a challenge please!" *receives challenge in response* Step 2: "Hey I decoded your challenge! It says 'challenge-stuff'. Send a token, please!" *receives token in response* No browser, no redirect, no hassle. If that's actually how it works, I would immediately adopt it for securing basically everything. That sounds awesome.
Do not store them in your password manager with your password or in your 2fa manager. It will defeat the purpose of 2fa. When you create these passkeys, either use a dedicated password manager with a separate, unique email and strong password which is NOT in your password manager, or create them per device on the device's dedicated password manager, IF it is a secure manager (like Mac with the Secure Enclave). Or you could use a dedicated security key. The convenience and security are undeniable, however if they are stolen, they provide access to your account by themselves. Keep them separate and securely stored.
Sounds like you could do the same setup/flow with zero knowledge proofs. The advantage is that even if the device falls for the fake domain, the secret is never sent in the first place and so it would be useless.
or you can have the hardware device also store the origin so it authenticates the site before releasing the credential information back to the site. This is in fact how it works as this is all basically FIDO2 being rebranded.
Good hackers will find a way around it, either by directly stealing the algo from the keypass servers, or by social engineering. If there's a will, there's a way, and when million$ or billion$ are at stake, they'll do anything to get it.
@BillAnt If we look at the WebAuthn standard (what everyone considering passkeys should be using and, frankly, is probably talking about), here's why neither of those is a viable option. 1. Nabbing the Algorithm The algorithms used are all open-source and usable by anyone. A proprietary alrogithm is, in my opinion, an insecure one. The whole system works on zero-knowledge proofs, as one of the comments before noted. You have to prove you know something without ever telling me what it is. 2. Social Engineering We'll start with the fact that it's outright impossible to get the private key out of a device without root-level remote code execution with and, on 90% of devices (with the number increasing as newer devices are used), impossible without outright physical hardware access and a lot of reverse-engineering work. Realistically, you're not getting that private key. So let's try getting the user's browser to sign a request for us. First instinct might be a MITM attack. WebAuthn is only available in secure contexts (file URIs, localhost, and HTTPS). Well crap. OK, let's try using a phishing site. The WebAuthn standard requires you to sign a request for a particular server identified by hostname (like something like "auth.bellcube.dev"). OK, let's try spoofing it. Well, darn, the user's browser won't sign a request with a hostname other than the one in the browser window. Let's use our own hostname and try to pass that on to the real server anyway. User has no passkeys for this hostname. Shoot. But let's say they're using a badly-coded device that doesn't store keys with hostnames. You get them to sign your malicious request with a valid. So let's pass that on to the real server. Shoot, they denied it because it had the wrong hostname.
The reason we haven't tried biometrics is because of the pfhishing potential. You've only got 11 reasonable sources of biometric data-10 fingers, one face. Most people only use 1-2 fingers or one face; they don't mix and match. Once your fingerprint is pfhished once, every single service you used that with is now compramised. Again, you only have one face. Can't change it if it gets compramised, either. Other problem with biometrics is that you can't use the to sign data without just being a private key with extra steps. With biometrics, you have to use fuzzy matching because the sensors aren't perfect. "Is it close enough" is all we're looking for. Which means you have to have some data to match against already. If you try to sign something using the raw sensor data as a key, you basically get a pseudorandom string back. Now, you could try using biometrics locally to initiate a signing process using an on-device private key... oh wait, that's what we're doing already with WebAuthn!
Can confirm those google auths defaulting to the app are annoying! But passkeys have a big turn off since the private keys aren't as portable as passwords or OTPs.
Prediction: passkeys will not see significant adoption and so companies will stop pushing them. People will continue to predominantly use SSO and passwords.
At least on all Apple devices, with the apple passwords app, it natively therefore supports passkeys. Most of my passwords have therefore become passkeys
I'm all for increasing security but there's one thing I still don't understand: How do passkeys work if I'm away from my device? I travel for work a lot and sometimes I need to sing in to a service on a new device without having access to my main device (where, presumably, my private key is stored). And if my private key device is small enough to lose (e.g. a usb key), we're not fixing the "I lost my password" issue, we're making it worse (a usb key is far easier to lose than one's memory, usually). And surely it's not expected that we store our private keys in a cloud that is accessible over the internet. That would mean that in case of an attack, instead of one of my passwords getting stolen/leaked, it's now all of them. I assume there's already a solution for this issue that doesn't require me to store my private keys on the internet or give them to someone else. We wouldn't start pushing the technology if there was no solution to this, right? But this problem is a genuine dealbreaker for me and I don't know how to solve it.
That's where phone-based passkey auth comes into play. Most modern devices (Macs, Windows 11 [but not 10], Android, and IDK about iOS but Apple's pretty good about this so maybe) support using your phone to scan a QR code, the phone signs the request, and sends it back done and dusted. Lets you use your phone just like a FIDO2 security key. Does not create lasting credentials on the device; only one auth session.
@@BellCube Thanks for the info. Now that you say it, it does sound very obvious. Just use whatever authenticator app is already on your phone. It still rubs me the wrong way that my private key is stored on an easily losable/stealable device. But with most of my concerns addressed now so I'll just trust that devs that are smarter than me or have more experience than me have figured this out (or will very soon).
If you end up making your phone a single point of failure for accessing your most important accounts or authenticating yourself, then you remind me of Plato, Aristotle, and Socrates.
I originally was not a fan of the idea. I use ssh keys alot now, so I have warmed up to it, but I would like the same amount of control as I do with ssh keys.
pass me the aluminium hat but this is just raise the acceptance to have an unique ID and use it everywhere. Which is mandatory for the Central Bank Digital Currency. In general of course this is helpful and can used for the good but also for the worse. that it becomes more and more famous these days is not just random. Its even not a new technology.
I like Passkeys, but I don’t understand how they protect you from insecure passwords when I’ve yet to encounter a service where I can use *just* a passkey. Everyone instead offers it as an additional authentication option. Surely that’s just increasing the attack surface?! 🤦♂️
Most services are older than the tech's adoption into browsers, frankly. Hard to switch to passkey-based auth when all of your users use passwords. When this video came out, I was already working on a service that used WebAuthn as the primary mode of authentication. With my auth scheme, you have to request a new passkey from an authenticated device. You get no notification on your devices so you have to go to settings to approve the new device for yourself. Additionally, requesting a new passkey requires you to enter a password that only exists for this purpose.
I re-use the almost-same password for throwaway accounts that are basically unrelated to my identity and have zero connection to anything money-related. I just fail to see the problem of someone breaching the e.g. Rust issue tracker and getting my password, and now they can wreak havoc on the GIMP form where I used the basically-same password. Worst case is they spam there and I get banned. I don’t care.
So what happens if your computer breaks or you have to use many different machines? Usually password managers are paid services if you want to put on multiple machines, is this the same? I travel frequently and use different phones, etc but I don't want to pay for expensive services and spend time configuring devices so O can just log into my accounts, is this solution any better than sending magic links to email? 2FA to a phone number is the worst tho, hard to share access btw people to accounts with 2FA you have to set up forwarding of the sms to email then email to another email, isn't a password and 2fa w authenticator app like authy still secure enough? Thats he most convenient and least expensive way to manage logins IMO for 90% of use cases, its super easy to set up 2FA authenticator app on multiple devices and its free
I had the same problem with Google and the default 2FA. My solution was to use passkeys and instead of filling in my password (after filling in my email), I click on more options and select passkey. Hope this helps.
Problem with longer passwords like a passphase is that some fields in certain sites is restricted to a certain length, which to my understanding is stupid from a security standpoint... that's one point of cracking the site's password much easier...
It's important to note that the spec contains tools for the relying party to RESTRICT where you are allowed to keep your passkey. The relying party can decide which password manager THEY trust, in a way that's technically impossible to bypass on the user side. This has vast potential for abuse, and it's the sole reason I hope the Passkey future never comes.
There's nothing stopping web services from setting up their own proprietary login system today. The reason FIDO2/WebAuthN supports restricting certain authenticators is to help mitigate risks from untrustworthy authenticator manufacturers, and even that functionality would really only be used in corp scenarios. For example, your company probably wouldn't want to allow authentication using a hardware key manufactured in Russia.
The complexity of technology which will make us more and more dependent on it. IT hallucinations didn't start with chat GPT. You will need n*n thingy to be able to authenticate, you will store some stuff on the cloud, some clever dudes will be able to access it ( as we know it is not a mater of if but of when ) and then they will use your identity ( your fancy identity ) and you won't be able to do anything about it.
Nice vid, question that someone might be able to answer this silly question -- how does this work if I login from device A and then login with device B in the same github account? does the server now have two public keys for my single account?
@@SharlosRevenkai Cross Device Authentication is also an option -- effectively sending the authentication request to another device without really syncing the keys. With persistent linking, the other device just becomes another option among others from which you can choose when authenticating. This isn't cloud syncing since I'm not even signed into my Chrome browser on my laptop. It basically communicates via bluetooth somehow. That's the one complaint I have about passkeys though that is making it difficult for us to really adopt it more at work. The UX is great if you are all-in on either the Google ecosystem or the Apple ecosystem, but less so if you have a more heterogeneous setup, like a Windows laptop and an iPhone. You can either use the OS level platform authenticator and bind the passkey to that single machine (which probably isn't going to sync anywhere) or use your phone, but since Chrome and iPhones don't support persistent linking between each other, you have to scan a QR code on chrome every time. That was a pretty common scenario that failed our UAT process. Things like Bitwarden (and 1password, I'm sure) kind of side step that issue at least on desktop. I'm not sure how/if password managers can be used as a passkey source for mobile yet. I sure haven't had much luck with it, although my primary testing ground has primarily been an Android phone running GrapheneOS rather than the standard Goolge suite.
Bitwarden also supports passkeys on their free tier. Where crypto is concerned, the reason such signing all the time was doable, was because all the energy heavy processing was distributed. The environmental impact of bitcoin has been well documented. Maybe remember y'all are standing on the shoulders of PGP. The whole crypto world has only survived this far because the processing and energy costs are being made somebody else's problem and even then has the artificial value it claims to prevent worse than any 'fiat' currency. No company wants to be providing free services like this unless the cost can be almost zero itself and it's made necessary by the failures of existing systems. Yubikeys are great and very simple but also cost more than most people would be willing to pay. Maybe in 10 years we'll all be moving on to something else.
But what protects the private key from theft? With PGP and SSH you typically have to enter a password in order to unlock the private key, before it can be used.
In an ideal setup (which is 90% of devices in 2024), the private key is generated on a separate hardware device like a TMP module or a FIDO2-compliant security key (like a Yubikey). The key never leaves the device, either-all you get are the signatures and encrypted data you ask for. The device can implement their own forms of user verification; for example, when using my Yubikey with Cloudflare, they require me to use a PIN with the key. There's a bunch of security measures in place that make it effectively impossible to pfhish even a single signature out of a device without direct software access, too. And on mobile, it's locked down by app.
This suffers from the exact same issue password managers generally create - lack of portability. What happens when you have to quickly sign into your email on a work computer, at the library, at a friend’s house, etc.? Most people use computer that are not their own sometimes and this would make logging in through said computers virtually impossible meaning you could easily run into major issues if you switch to passkey auth even if you fully know what you are doing.
That's where phone-based passkey auth comes into play. Most modern devices (Macs, Windows 11 [but not 10], Android, and IDK about iOS but Apple's pretty good about this so maybe) support using your phone to scan a QR code, the phone signs the request, and sends it back done and dusted. Lets you use your phone just like a FIDO2 security key. Does not create lasting credentials on the device; only one auth session.
What exactly is the "revolution" with yubikeys? They still require a password, and now I constantly have a flimsy, easily breakable, USB stick taking up one of my ports.
They don’t require a password. If you use them as a passkey, all you need is the yubikey (and possibly a short PIN). Of course, you can also just use them as a 2nd factor for logins that still require a password, too, but that’s not what this is about. Passkeys go a step further and get rid of the password. If you are concerned about breaking or loosing the yubikey (or any other hardware key that supports Fido2, for that matter), just get a second one as backup and set up all accounts on both, but only use one for regular usage and have the other one in a safe place.
@@johannesloher2817 I use it at work, and we have to enter in a password every time we use them for authenticating in an application. Maybe my situation is different. Also, setting them up on the computer was a pain in the ass.
@@johannesloher2817 Some services do request that the authenticating device do something called "user verification"; for a standalone FIDO2 security key, this typically means entering a PIN. Not all services request this.
My work requires a min 12+ alphanumeric special character password + yubikey. I actually want to stab out my eyes by the time I get into every application required just to start work. The yubikey is wire chained to the actual PC too so hopefully it's in a port you don't mind sacrificing forever cause it's not moving 😂🫠
There will be just as many calls for help and time and money spent by help desks. People are dumb and they're also not their computer or phone! At the end of the day a password has to be somewhere and this just adds complexity to that people won't work with well.
Okay but how do you store and sync the private keys to protect against the case of your computer going haywire? Your access to services you registered to using the private keys on your now-dead client is gone unless you can recreate the private keys, in which case we're back to square one: passwords or using a third-party cloud solution, which beats the entire purpose of offline and interaction-less safekeeping.
Its all good but comparing them with stats like password leaks in social media is not suitable right? I mean, the main adv of choosing a username password approach is cus its ability to be device independent (which is what any social media needs?) unlike crypto which are device dependent?
6:30 - this is simply false and it's a common misconception about asymmetrical cryptography. Both public and private keys can lock AND unlock what was locked by the other. By encrypting with the private key and decrypting with the public key (which everyone can do bc it's public) you obviously can't hide sensitive data but you can actually prove it was "signed" by the owner of the private key. And this is how what he wrongly described at 5:40 actually works. The server doesn't lock with the public key, but instead sends you a string, which you encrypt with your private key, send back and they decrypt with your public key to see if it matched with what they sent initially. If it doesn't, obviously you don't have the right private key which means it's not you. Edit: I arrived at 9:00 - the part where he realizes his ignorance
Ill stop using same passwords when companies stop requiring a mandatory change of pass, or require caps non caps numbers and 1 of ONLY 4 specific Special characters and over 8 characters, like at that point just give me an acceptable password i aint thinking of all that
Seems wild to discuss this without mentioning recovery. What happens if my phone breaks? Either it’s possible to access using 1fa or it’s impossible to recover. Has this been solved in some way?
That's the real tradeoff, now isn't it. Even if you have a hundred passkey'd devices, you can lose all hundred of those and lose access. There's a distinction I heard once between different authentication factors. "What you know" would be something like a password or your mother's maiden name. "What you are" would be biometrics (fingerprint or Face ID). "What you have" would be something like, say, a private key stored deep in the depths of your machine's TPM or similar kind of hardware authentication chip. The problem with "are" authenticators is that you only have one set of fingers and one face. Password reuse ensues. Someone pfhishes your biometrics and you're done for. Can't use those. I think we've all seen the problems with "know" factors by now. You forget, it gets leaked, the database gets hacked and it turns out the service only encrypted the password with an encryption key that's RIGHT THERE and now they have the password you used for 100 different sites because password reuse is very common, etc. "Have" factors are the last remaining bastion. But, of course, these are suceptable to losing access. But so are your glasses. So are your car and house keys. So is your phone. So the next best option is to do what you do with your car and house keys. You make copies. So, the tradeoffs tl;dr: "know" (passwords, mother's maiden name) is suceptable to leakage, forgetting, and very much so to cracking "are" (biometrics; fingerprints, FaceID) is so pfhishable it should only ever be used locally "have" (keys, devices) can be lost relatively easily
The thing is, IF the attacker was able to sign into the database/redis cache with the public keys, he could change them to his public key, right? That will mean that on next login attempt (done by the hacker) he will have a successful login and thus access to the entire account. Am I right?
Passkeys are cool, BUT they seem more of a way to vendor-lock authentication to apple, google and microsoft, rather than actual open standard everyone can benefit from.
Passkeys would be great if they worked. All the browsers want me to use a physical security key, which seems risky as a single point of failure but also complete overkill. If all it is is public key cryptography, there's no reason I shouldn't be able to store those keys locally on this computer (I know it's less secure, but my threat model doesn't include anyone accessing my local files so I don't care). I get pushing for that or biometrics by default, that's a great idea, but please, there's no technical reason to *force* me to do that. It's supposed to be a *user* agent, as in, *my* agent, why is it fighting me? When you say it's public key crypto, it sounds so simple, but then I see the mess of a standard and the horrible UX and it's just not simple. For now, I only see big tech companies having decent implementations, but with no clear way to export keys, so it just looks like vendor lock-in to me. User agents need to standardize on a way to interface with extensions or programs that actually manage the keys, otherwise there's no way for me to actually use it.
AI that can guess what I type based on sound? Me with 12 different switches: Yeaaa.... No. Unless it trains with my specific keyboard, than I am fucked faster.
@@quinnherden Guess it depends on the AI. If it just predicts the volume of each keystroke, it will not work. But let it know and hear a few sentences I have written and I am out of luck.
26:13 x86 and windows do have this. ever heard of tpm? the stuff that everyone complains about being a windows 11 requirement? or what about microsoft pluton. its so "secure" that it will not allow you to use any operating system which is not windows. i do not want that. also that has nothing to do with passwords vs passkeys, this is against someone getting physical access to your machine and doing stuff like reading your ram. completely different attack and has nothing to do with anything in this video.
The company i work at, recently started using fido. It's great when it works and the suite that we use has a password auto renewal. The only problem is that sometime when the password auto renew, it dosent sync up with ldap. So we can log into our computer but any software and or web access that requires our ldap log in dont work.
I have yet to find a video where someone actually does a good job of explaining passkeys, and unfortunately this video also misses the mark. Judging by the comments it seems tons of people are still confused and don't understand the benefits compared to passwords and other public key cryptography authentication flows.
i always thought that only private key can "encrypt message" and then public key is the one "decrypting it" verifying in the process that "yes it was encrypted by one human, the one holding private key". You said multiple times that it can work in the reverse where anyone can "encrypt with public key" and only i can "decrypt with secret key". We learn everyday i guess
Well, using private key on message actually signs it - verifies that owner of the private key that matches public key associated with an entity is the author of the message. Encrypting is done with public key, because it makes it unreadable for everyone except of the owner of the private key.
Public key is, by definition, "public". If public key was the one responsible for decrypting messages, anybody could decrypt the message. So of course it has to be the "private" key which decrypts the message.
@@Gornius i thought this is how symmetric keys work (done some AES encryption on one project), while public/private i thought are asymmetric, so encryption goes just one way (private encrypts, public decrypts) ....probably just need to read on this
@@alexsmart2612 hold on, but the point was (i thought) that anyone can read the message but its verified to come from the sender with private key without anyone changing its contents. This whole signing idea is the one way it should work ...the other direction is the news to me. So really the public one can "decrypt" for sure
25:44 I'm sorry but... biometrics, which every time Apple does a new release, is broken within 2 or even 1 week after release with a cheap documented solution to circumvent it.
It's crazy that this only starts to rise now but PGP has existed for decades
Diffie-Hellman key exchange paper was published in 1976. RSA came in 1977. PGP in the 90s. 2011-2013 Facebook SSL/TLS by default. 2012 HSTS RFC release. It has been a looooong and slow journey.
Indeed, essentially that's what PGP does. Problem is that now hackers will go after the keypass server, and with that they just got unlimited passkeys by pairing it with user's public key. There are always pros and cons with virtually everything.
@@BillAntwth is keypass server
You cowards probably didn't even read PGP: Source Code and Internals (1995)
@@radomane Hehe and the exact same concept with Bitcoin keys being used to sign transactions.
I was originally skeptical of passkeys but in practice they are SO GOOD for *both* user experience and security
Right, and now hackers will go after the passkey server, and with that they just got unlimited passkeys by pairing it with user's public key. There are always pros and cons with virtually everything.
I guess as long as there's a good open standard API which automates most of the auth steps, it could be a practically seamless experience.
@@BillAnt what's a passkey server? There's no 3rd party server involved. This is password login but considerably more secure by default.
Same
@@Megaranator some password managers like 1password store passkeys in their servers. Device passkeys might also be stored somewhere else when it's not physical key and could also be stolen by malicious software. And if it's a physical key, then manufacturer could be storing origin keys without your knowledge. Buying a physical key from someone is like asking other company to create your password. In all, passkeys are worse than long good passwords since it's cryptographic keys are stored in digital media. Add simple 2FA TOTP and it's good enough.
Part of the problem with help desk calls over forgotten/lost passwords is because jobs require you to "change" your password every 3 months, meaning most people need to write down a new password 4 times a year or they'll do the human behavior of only changing 1 or 2 characters until they can repeat the same passwords, making their "new" password easier to guess and lowering the security of passwords.
If soneone has a good password, changing 2-3 chars doesn't make it easy to guess. If you have a key logger in your system you can have all the fancy protection and won't help.
@@danielratiu4318we know that it'll go BobbyIsTheBestDog1 > BobbyIsTheBestDog12 > BobbyIsTheBestDog123 and so on.
This password changing bullshit is SO ANNOYING and really isn't needed. And yes people come up with the simplest password possible knowing they'll have to changebit soon anyways
Yeah, 90 day password rotations are insane when you already need like 8+ characters, special, number, capital, etc. Meanwhile my PHYSICAL access 4 digit combo (lmao) has been the same for 6 years.
Heh, I work for a company that has the 90 day forced password change on their Windows domain. I work offsite now but at the time I didn't run Windows and I only ever logged into the Windows Domain via the Exchange server through Thunderbird... there's no mechanism for the forced password change in Thunderbird so every 90 days I would just stop getting any emails. I eventually convinced them to set my password expiry to "never."
When I describe the asymetric cryptografic concept, my favourite sample is a padlock.
You have a partner you want to share something with
Your partner is too far away to share it personally to keep it secure
Public postal service is the only transport way
So... You buy a brand new padlock
You keep the key in your pocket and send the padlock to your partner
Your partner buys a box, puts the secret in the box and locks it with the padlock (and is so not able to open the box anymore)
He sends the box to you
You open the box with the key in your pocket.
Padlock = Public Key
Key = Private Key
Basically you're sending a locked "container" for your secret data.
this is such a nice example, my teacher used this exact example back in school
Albeit not exact thisi s a very very VERY good analogy that I am going to steal real quick for when I have to explain this.
@@diablo.the.cheater a VERY good analogy indeed
Nice explanation. An asymmetric key pair has two keys, and both can be used to encrypt and decrypt a message. What makes the padlock "public" is that is sent over the network and should never be trusted, because someone might have seen its mechanism of encryption.
7:20 Important to highlight that a Diffie-Hellmann-Exchange and asymmetric Encryption are two completly separate things.
One is used to anonymously exchange keys, the other can be used to sign or encrypt data
listening to Theo be confidently wrong about rsa for 15 minutes gives me life.
maybe not wrong but def displaying a lack of deep understanding
Awesome, that means there's a place for you to make a good in-depth video that explains the topic better! I'm subscribed, looking forward!
Theo confidently says a lot of misleading or wrong stuff, I always watch his videos with a grain of salt nowadays.
@@Melvin420x12 challenge accepted. luckily for me I made a full arbitrary bit length base rsa implementation in js in 2012 from the ground up, and a php rsa implementation using gmp for end to end encryption for my home brew rich chat server... all free for any use and open source- no integrated license.
are we taking mechanics or a deep dive on the processes behind it, Or a discussion of the top level programs that use it that end users will be exposed to?
or just a live rewatch of this video with tangent cut aways to fill in missing info?
I'll always say that the best way to understand these things is to go code them yourself. let me know if you can solve the division issue. I gave up optimizing it over a decade ago.
@@Melvin420x12 apparently my reply got deleted. didn't say anything off... no links, no mention of any other site or self promo.... just a description of my previous efforts in rsa.
looks like I've been shadow banned. ha.
why in the name of all that's holy do you pronounce 2FA like "toofah"
These are literally just the next natural thing to do after acknowledging that the best option for everyone is using a password manager; at which point the passwords in that password manager might as well be a private key instead of just a random block of text.
It still has the same user end problems that (1) you're in a mess if you lose the password manager itself, and (2) that you still need to make the password manager itself secure, which always comes back to needing a password. But making a standard around essentially forcing users to use a slightly more clever password manager makes sense.
Hopefully it also leads to better user experience and a good best-practice on how to secure all of it.
i am actually more afraid of loosing access by 2fa than i need that security. Especially if the phone breaks that is used for auth google.
yeah. auth apps which do not let the keys out again. Posibility of having a second key for the site, login data is also something. Only e.g. passkey or another solution, in one yubikey etc. How to 'back up' this? I do not have a working solution for this/for me. Or it's not practicall for things that are on the highest level of importants. Or how is the fall back? Often you can do a 2fa with yubikey etc, but when the fall back is still email or a phone number... I do see the benefits against phishing with passkey but I also feel not good with it when it's in a phone. e.G. Google/android. When you use googles auth app, your phone breaks or get's stollen and you have no other google account/phone which is active, you really have a tough time getting that account back, even when you have the password.
Don't use Auth Google. Please. Use any other service.
@@nopenope1for yubikey you should have two, one to carry with you and a another for backup in a secure place (or three, if you wish)
@@Waine2000 MS auth ;)
@@Waine2000do you mind elaborating
$17.50 to reset a password. I wonder how they calculated that cost.
Sounds like the amount spent on both employees interacting: the service desk and the employee that needs the reset.
@@mosescosme8629 Yeah and out of that $15 go to mr Yacht
Passkeys are great. The only downside for me is that there's a much bigger risk when you lose the device that stores your key.
I'd say the risk is about the same if you lose the device, but significantly lower overall. I mean, even today, if you lose your device, and the thief could log in to your device, they'd likely have access to all of the accounts you check "keep me logged in" on, which likely includes email, which then includes nearly everything. Even still, if you lose your computer, it's a matter of invalidating the passkeys and you should be more or less safe. The point is: you'll know when you're breached, which is not the case with a password.
Now, when you weigh that (worst-case) scenario with all the different ways passwords can be stolen/compromised/leaked/forgotten/etc., passkeys come out FAR on-top when it comes to security. The fact that with a passkey you can only sign in with the device (no way for remote account breaching), we're looking at a significantly smaller attack surface, with pretty much the only weakness being a thief with 1. physical access to your computer, and 2. knowledge of your computer password.
Better than 2fa where the secret is stored on the server side, yikes.
I think there's a relatively simple solution. Use a single password on the client side, use passkeys on the server-side. Passwords on the client side are used to decrypt the passkey into memory, use it, then immediately drop the memory. The server then can see the certificate is valid while never seeing your password. One might recognize a similarity to using an encrypted password manager that is accessed via your password. It's essentially the same thing, but now not even the server knows your real password, *nor* the passkey. Just the public key it corresponds to.
This is simply far, far safer than what we have right now. And it comes with the added benefit of uniformity between large passkeys, meaning vulnerabilities like rainbow tables become utterly impractical. Now the only risk is you losing your password or writing it down somewhere. Rather than sending your password off to a server which is run by incompetents who end up leaking your password out, as we did in the old days. And still do, haha.
That's why you need to set a PIN or fingerprint for your passkey authenticator. Stealing a physical device is still way more effort than phishing, which is something that's effectively mitigated by using passkeys.
Agreed
21:40
That 44 bits of entropy is not by guessing letters, It's by knowing the exact dictionary of words used.
11 bits per word means 2048 words. That wordlist was originally made for Bitcoin wallets with the BIP39 proposal. A list of 2048 unique, easy to distinguish words
Microsoft deserves more credit than is given. As far as back as Windows Vista there has been support for Trusted Platform Modules or TPM’s. These help store encryption keys and generate high entropy random numbers needed to generate strong keys.
Eh. I use a password manager and unique passwords for every site/service. I've also set my password manager to clear the clipboard after 2 minutes and to lock itself entirely after 15 minutes, so it's never left unlocked for long. Also, the password manager wouldn't suggest automatically filling in my credentials on a fake domain, so even if I fell for a phishing mail and did the dumb thing of clicking on a link there, I'd still notice something being wrong, because there'd be no prompt for me to unlock my password manager.
@@myspace_forever You still need credentials to create an account in the first place, so it's not "just using passkeys", innit?
Yeah, that's completely fine and equaly safe as passkeys. No need to change. Maybe MFA is a point, but most password managers support it today either.
I do the same as you. Except for clearing the clipboard. Thanks for that recommendation. I usually enter the password first so that the last thing I copy is the username. But your idea is better for sure as different systems sometimes store the last N clipboard items.
I believe this method is perfectly safe so long as your PW database is appropriately protected. No one is guessing those strong passwords.
The entire reason people say "passwords suck" is actually because users suck. Only ONE member of my family uses a password manager. Everyone else does the same nonsense of reusing the same passwords and making them combos of words and numbers that have significance to them (i.e pet_name+birthday). And of course they STILL forget them all the time.
@@turc1656 Yeah, clearing the clipboard is something not that obvious, but it's yet another way one might accidentally leak passwords. Many (most?) password managers have support for setting a timeout for that, like e.g. KeePass and its forks and variants and bitwarden.
Yeah, exactly this. The only online password I truly have to remember is my Google account's password because all my passwords are stored in the password manager included with it. I just have a ludicrously difficult password for that Google account that is impossible to guess and have had it memorized for years now. It's better than having multiple passwords to remember, or passkeys for that matter. Also, I kind of hate how the trend in authentication is going towards mobile phone dependence. Like, for me, a phone is pretty much disposable, and in a place like Karachi, Pakistan, can easily get snatched. Some forms of 2fa legitimately leave you locked out in those cases.
Theo: Locking / unlocking are not roles of public/private keys respectively. Rather whatever is encrypted by one is only decrypted with the other. So I *secure* information by encrypting with my public key, and I *publish/authenticate* information by encrypting with my private key.
Passwords have a place in society. It's a what you know type of authentication and that is sometimes way more cost-effective in certain cases than a what you have or what you are
I don't think Theo or the writers care about real security protocols. Neither mention integration of auth chips to biometrics and passwords as a holistic system. They just want to talk about magical logins without the "effort" of passwords etc.
I do not like analogy of username/password. It is better treat them like a 2 functions, that are inverses of themself. You can use your private key to proof your identity: everyone can check that only you could encrypt that with your private key by calling your public key (it is public!), but you can use MY public key to encrypt something for me - only I can decrypt it with my private key.
Agreed! I've stopped watching this video after seven minutes, because Theo is getting a lot of things wrong here (his drawing on how public/private key cryptography works, stating that you can only encrypt with the public key (which is wrong, because you can encrypt with a private key and then decrypt that with the public key), confusing Diffie-Hellman with RSA)
You are right, I did the same. After 7 minutes it was too much for me, even I am not specialist in this matter.
Dear Theo, please make something to keep it "legit" - we can help with some proof-reading or suggest some articles, but you need to make something with this - what you told was just bit too far from true and with your fanbase it will hurt the public if someone will not rectify it imho
its basically just what ssh does since ages
Lol im just building passkey based auth right now for our uni project its great to see how passkeys are working and i can now say i have a deep understanding of the technology
as for the math of public key encryption, at a high level when you generate the keys it picks two really large prime numbers (relatively easy for a computer to find), and then multiplies them together, and that result is your public key, with the factors being your private key. it's _really_ computationally expensive (on normal computers) to factor a large number into two primes (you just have to brute force it basically)
The color analogy works best visually. When you see it once, it's like "OOOOOOH". Also I find the public/private scheme absolutely brilliant.
Until there is a solid migration story in place, Passkeys are just a tool for vendors to create lock-in IMO. And the fact that it's being pushed so hard *before* a migration story is in place means that the lock-in is 100% the point. I don't trust it one bit.
Lock in? How?
I fear what happens when my phone is broken or stolen 🤔
@@PavitraGolchha depends on what manager you use for passkeys. This won’t be an issue for example if you use the native passwords app which is on all Apple devices.
@@PavitraGolchha Pretty sure Apple devices back up to iCloud and Google & Microsoft back up to their password managers as well.
It's no different to if you lost your phone that you used to generate TOTP codes before, or a physical FIDO2/U2F security key.
How do you lock in someone to a services with passkeys?????
Wait... so I'm not supposed to push my private SSH key to GitHub?
🤦♂
I trust you Theo, so now by extension I trust passkeys. Well at least I’ll consider clicking yes the next time I’m prompted to use one. Thank you for the video, and thank you Clerk for the article
Finally! I've been waiting for this to be in clerk forever
Great video, i never actually fully understood public / private keys until your explanation!
Yeah, I'm super excited about this transition.
I use a password manager. Out of 516, 427 are compromised. To note, only 371 are reused, so there are more compromised passwords than reused passwords, that's at least 57 (56+1) breaches.
It's just too much work to change all passwords, so I end up changing them only when I use a service I haven't used in a while or it's an important one.
Depending on your password manager, they can change it for you with a random generation
I love that theo is sponsored by passkeys but bring secret double octopus in his video!
Sounds like we can establish the same flow with password as well. No need "passkey" at all.
Step 1. Server trusts multiple password hashes.
Step 2. User auto-generates unique password on each device, and use biometric or any form of secure way to unlock that password during login.
Done. Sweet and easy.
The only difference is digital signature vs by plain text secret.
ok I'm wrong.
In above approach, servers will see user's device-specific password. Meaning if user signed into one malicious server, the server can then use this password to login other websites. While using digital signature, servers cannot see any secret of the user.
Yeah, that's basically what we're doing. The asynchronous cryptography stuff is just to add a bunch of extra security, better prevent pfhishing, and all that juicy stuff. Your system covers the main bases though. But once you have that system, it seems silly to not use public key cryptography on top since it's effectively free.
Of course, this assumes you're properly salting, peppering, and hashing your passwords.
I don't think this article addressed using multiple devices? do you store the passkey on the device, in the browser, in an extension, or what?
edit: ok 30:45
Don't worry, clever hackers will figure out a way around this too. heh
Technically it's on the service to allow you to create multiple passkeys somehow. I was already working on implementing primarily-WebAuthn authentication for a bit now when this video came out and my scheme for multi-device auth is simple. You use an authenticated device (one that used a passkey to log in) to accept a request for a new passkey. New passkey requests themselves must be made with a password. This scheme is inherently less suceptable to social engineering since, with a decent UI, it's made clear to the user that they're authorizing a new device to use their account-not simply logging in. Even if the request password gets leaked somehow (password should be treated with normal levels of password security; salt, pepper, and hashing please), say through a phfishing site, the most they can do is do auth spam. The nice part, though? They can just reset their passkey request password and the auth spam goes away.
@@BellCube - That's exactly what this video's sponsor does, it's a master password repository for creating duplicates in case a device is lost or stolen. Basically entrusting your passkey's master password to some cloud service.... what could possibly go wrong?! lol
@@BillAnt Yeah... that's not the point of the comment. The point is that there are solutions for the key duplication problem that don't rely on passwords to keep themselves secure. The scheme I mentioned only uses passwords as a form of required MFA and everything possible is stored on the user's devices. No third-party providers in sight.
I agree with you with regards to SMS, HOWEVER, it gets used because everyone with a mobile phone (At least here in Australia, dunno about Backwards US where talk+text is charged.....) can basically receive an SMS.
I don't really understand how keys are better than just using a password manager. To me, they look very similar, you still need to store all those keys, so it's essentially the same thing but different color, isn't it?
In theory the advantage can be of passkey is that the key is stored in hardware where it can't be exported.
@@autohmaeBut why couldn't it be? It's just information right?
@@crancpiti look up what a ARM secure element/trustzone and TPM (trusted platform module) and Apple Secure Enclave
CS50 cybersecurity does a great job explaining these
Hi theo. I gotta say as a mathematician I'd love some level of depth when you try to explain concepts. It stops people from thinking everything math-realted is witchcraft. Still love your content!
I used to read Better Explained a lot because I was taught to remember math formula without understanding anything. Now I usually appreciates math a bit, a lot when it’s explained. The difficult part for me is that my foundation is so weak, I have to look up every concept that most explanation refers to.
@@RobGThaiImo the fact that you need to look up every concept math related is not only due to your lack of foundation, but also due to the way math works. Every definition, if not based on the axioms themselves is based on another definition. From those objects we derive properties and theorems (aka the truth). To understand any concept in math, you take a definition and start digging. You become good at math when you've digged enough and enough times that you don't need to look that many concepts anymore, because you know them. It's similar to learning a language, except instead of a dictionary of what a word means you need a degree-level experience to start to get it.
I don't care if this is sponsored, this is a great video
This appears to have the exact same secuirity level of using a password manager:
- You generate passwords for every website
- You rely on a tool to send and consume the authentication process
- You create a single weak point on the security chain that is you instead of the server (as you still have an unique password in the password manager)
No, since Passkeys have phishing prevention. If you copy/paste the password into the wrong website, it’s compromised. But the passkey system ensures a hostile website can’t use the challenge response to log into your account.
@@Skyb0rg
The password manager can have pishing prevention as well by just checking the URL's for you, this is not a counter-argument.
@@diadetediotedio6918 That isn’t always possible, ex. desktop apps which use web login windows. And it doesn’t rely on the security of an SSL certificate matching the domain name to the server, since password managers can only do text matching (though I’d agree it’s very hard to have that happen).
@@Skyb0rg
But it is possible, my point was not about "the lowest safer password manager", it was about password managers in general and their best capabilities.
A steelman of this argument would follow this lines:
"A good password manager with pishing protections (for example by having an extension in the browser that checks the certificates and stores them when creating accounts) and good password protections (for example, that never shows the user their passwords, that generates strong and safer passwords, that keeps them encrypted all the time but on the act of login, that never repeats passwords, that associates passwords created with the sites they were created, etc) equates in security level a passkey".
Passkeys are waaaay more secure than passwords for several reasons:
1. They are phishing resistant. Yes, password managers can help mitigate this risk, but only to a limited degree. The average user would probably think their PM is bugging out and mindlessly type in the password manually.
2. Passwords can be stolen even if you have good security practices. Data breaches happen all the time. With passkeys, even if a data breach occurs your authentication secret is not exposed.
3. Passkeys have cloning detection. Each time a passkey gets used, the auth response will contain a counter that monotonically increases. If the value ever decreases, that indicates someone cloned your passkey, and the web service can detect that to prevent unauthorized access.
Lastly your password manager can also be protected using a passkey stored by a hardware key like a Yubikey. That provides the ultimate protection since you no longer have a master password which can be exposed.
Microsoft and Google deserve a little more credit. Passkeys (FORMERLY WebAuthn) was adopted by Edge and Firefox a few years before Safari got it.
It wasn’t until Apple adopted it and gave it a fancy name did anyone pay attention.
To clarify, WebAuthN wasn't renamed to passkeys. Passkeys are a technology built on the FIDO2 spec, which in turn is composed of two protocols, WebAuthN and CTAP2. Passkeys are actually just a rebranding of FIDO2 resident credentials.
Wait, does this mean we can eliminate Oauth callbacks? That would save me so many headaches in cross-platform projects. Step 1: "Hey I'm me! Send a challenge please!" *receives challenge in response* Step 2: "Hey I decoded your challenge! It says 'challenge-stuff'. Send a token, please!" *receives token in response* No browser, no redirect, no hassle. If that's actually how it works, I would immediately adopt it for securing basically everything. That sounds awesome.
Whenver I see a titles like this I know Theo just got a bag lol 💰💰💰
Do not store them in your password manager with your password or in your 2fa manager. It will defeat the purpose of 2fa. When you create these passkeys, either use a dedicated password manager with a separate, unique email and strong password which is NOT in your password manager, or create them per device on the device's dedicated password manager, IF it is a secure manager (like Mac with the Secure Enclave).
Or you could use a dedicated security key.
The convenience and security are undeniable, however if they are stolen, they provide access to your account by themselves. Keep them separate and securely stored.
Sounds like you could do the same setup/flow with zero knowledge proofs. The advantage is that even if the device falls for the fake domain, the secret is never sent in the first place and so it would be useless.
or you can have the hardware device also store the origin so it authenticates the site before releasing the credential information back to the site. This is in fact how it works as this is all basically FIDO2 being rebranded.
Good hackers will find a way around it, either by directly stealing the algo from the keypass servers, or by social engineering. If there's a will, there's a way, and when million$ or billion$ are at stake, they'll do anything to get it.
@@BillAntpasskey server?
@@quinnherden - Yes initial key-exchange and time synchronization servers. Guess who sponsored this video?
@BillAnt If we look at the WebAuthn standard (what everyone considering passkeys should be using and, frankly, is probably talking about), here's why neither of those is a viable option.
1. Nabbing the Algorithm
The algorithms used are all open-source and usable by anyone. A proprietary alrogithm is, in my opinion, an insecure one. The whole system works on zero-knowledge proofs, as one of the comments before noted. You have to prove you know something without ever telling me what it is.
2. Social Engineering
We'll start with the fact that it's outright impossible to get the private key out of a device without root-level remote code execution with and, on 90% of devices (with the number increasing as newer devices are used), impossible without outright physical hardware access and a lot of reverse-engineering work. Realistically, you're not getting that private key. So let's try getting the user's browser to sign a request for us. First instinct might be a MITM attack. WebAuthn is only available in secure contexts (file URIs, localhost, and HTTPS). Well crap. OK, let's try using a phishing site. The WebAuthn standard requires you to sign a request for a particular server identified by hostname (like something like "auth.bellcube.dev"). OK, let's try spoofing it. Well, darn, the user's browser won't sign a request with a hostname other than the one in the browser window. Let's use our own hostname and try to pass that on to the real server anyway. User has no passkeys for this hostname. Shoot. But let's say they're using a badly-coded device that doesn't store keys with hostnames. You get them to sign your malicious request with a valid. So let's pass that on to the real server. Shoot, they denied it because it had the wrong hostname.
Something you have, something you know, and something you are. The last is adding biometrics.
The reason we haven't tried biometrics is because of the pfhishing potential. You've only got 11 reasonable sources of biometric data-10 fingers, one face. Most people only use 1-2 fingers or one face; they don't mix and match. Once your fingerprint is pfhished once, every single service you used that with is now compramised. Again, you only have one face. Can't change it if it gets compramised, either.
Other problem with biometrics is that you can't use the to sign data without just being a private key with extra steps. With biometrics, you have to use fuzzy matching because the sensors aren't perfect. "Is it close enough" is all we're looking for. Which means you have to have some data to match against already. If you try to sign something using the raw sensor data as a key, you basically get a pseudorandom string back. Now, you could try using biometrics locally to initiate a signing process using an on-device private key... oh wait, that's what we're doing already with WebAuthn!
Can confirm those google auths defaulting to the app are annoying!
But passkeys have a big turn off since the private keys aren't as portable as passwords or OTPs.
Prediction: passkeys will not see significant adoption and so companies will stop pushing them. People will continue to predominantly use SSO and passwords.
Passkeys will thrive in enterprise. For regular users? Most of them don't use password manager so I wouldn't expect them to use Passkeys
Because passwords are just better.
@@Aerroon one time use? sure... long term and for critical accounts? don't joke, unless you are _jiatan_ type agent
At least on all Apple devices, with the apple passwords app, it natively therefore supports passkeys. Most of my passwords have therefore become passkeys
@@game_time1633 And what happens if something happens to your apple devices and you have to use an Android phone or a Windows PC for a bit?
I'm all for increasing security but there's one thing I still don't understand:
How do passkeys work if I'm away from my device? I travel for work a lot and sometimes I need to sing in to a service on a new device without having access to my main device (where, presumably, my private key is stored). And if my private key device is small enough to lose (e.g. a usb key), we're not fixing the "I lost my password" issue, we're making it worse (a usb key is far easier to lose than one's memory, usually). And surely it's not expected that we store our private keys in a cloud that is accessible over the internet. That would mean that in case of an attack, instead of one of my passwords getting stolen/leaked, it's now all of them.
I assume there's already a solution for this issue that doesn't require me to store my private keys on the internet or give them to someone else. We wouldn't start pushing the technology if there was no solution to this, right? But this problem is a genuine dealbreaker for me and I don't know how to solve it.
That's where phone-based passkey auth comes into play. Most modern devices (Macs, Windows 11 [but not 10], Android, and IDK about iOS but Apple's pretty good about this so maybe) support using your phone to scan a QR code, the phone signs the request, and sends it back done and dusted. Lets you use your phone just like a FIDO2 security key. Does not create lasting credentials on the device; only one auth session.
@@BellCube Thanks for the info. Now that you say it, it does sound very obvious. Just use whatever authenticator app is already on your phone. It still rubs me the wrong way that my private key is stored on an easily losable/stealable device. But with most of my concerns addressed now so I'll just trust that devs that are smarter than me or have more experience than me have figured this out (or will very soon).
@@borerofhope Better than an app-this is part of your phone's OS already!
If you end up making your phone a single point of failure for accessing your most important accounts or authenticating yourself, then you remind me of Plato, Aristotle, and Socrates.
I originally was not a fan of the idea. I use ssh keys alot now, so I have warmed up to it, but I would like the same amount of control as I do with ssh keys.
Problem with things like password keepers are when I need to somehow type in a 40 digit long password on my Kindle touch keyboard.
pass me the aluminium hat but this is just raise the acceptance to have an unique ID and use it everywhere. Which is mandatory for the Central Bank Digital Currency. In general of course this is helpful and can used for the good but also for the worse.
that it becomes more and more famous these days is not just random. Its even not a new technology.
I'm actually not so sure how much the Secure Enclave is used for this. But I'd have to look into it.
I like Passkeys, but I don’t understand how they protect you from insecure passwords when I’ve yet to encounter a service where I can use *just* a passkey. Everyone instead offers it as an additional authentication option. Surely that’s just increasing the attack surface?! 🤦♂️
Most services are older than the tech's adoption into browsers, frankly. Hard to switch to passkey-based auth when all of your users use passwords.
When this video came out, I was already working on a service that used WebAuthn as the primary mode of authentication. With my auth scheme, you have to request a new passkey from an authenticated device. You get no notification on your devices so you have to go to settings to approve the new device for yourself. Additionally, requesting a new passkey requires you to enter a password that only exists for this purpose.
@@BellCube I’m not expecting anyone to make passkeys the only method of auth for all their users. But they should allow any individual user to do so.
I re-use the almost-same password for throwaway accounts that are basically unrelated to my identity and have zero connection to anything money-related. I just fail to see the problem of someone breaching the e.g. Rust issue tracker and getting my password, and now they can wreak havoc on the GIMP form where I used the basically-same password. Worst case is they spam there and I get banned. I don’t care.
biometric , or your system lock code is needed everytime / once a broswer /app session for passkey.
So what happens if your computer breaks or you have to use many different machines? Usually password managers are paid services if you want to put on multiple machines, is this the same? I travel frequently and use different phones, etc but I don't want to pay for expensive services and spend time configuring devices so O can just log into my accounts, is this solution any better than sending magic links to email?
2FA to a phone number is the worst tho, hard to share access btw people to accounts with 2FA you have to set up forwarding of the sms to email then email to another email, isn't a password and 2fa w authenticator app like authy still secure enough? Thats he most convenient and least expensive way to manage logins IMO for 90% of use cases, its super easy to set up 2FA authenticator app on multiple devices and its free
Does it mean people in military academies will start exchanging private keys instead of cutting their hands? It's SSH pact, baby!
I had the same problem with Google and the default 2FA. My solution was to use passkeys and instead of filling in my password (after filling in my email), I click on more options and select passkey. Hope this helps.
Problem with longer passwords like a passphase is that some fields in certain sites is restricted to a certain length, which to my understanding is stupid from a security standpoint... that's one point of cracking the site's password much easier...
Max password length is dumb, but you also shouldn't be resusing passwords on different sites.
It's important to note that the spec contains tools for the relying party to RESTRICT where you are allowed to keep your passkey. The relying party can decide which password manager THEY trust, in a way that's technically impossible to bypass on the user side. This has vast potential for abuse, and it's the sole reason I hope the Passkey future never comes.
There's nothing stopping web services from setting up their own proprietary login system today. The reason FIDO2/WebAuthN supports restricting certain authenticators is to help mitigate risks from untrustworthy authenticator manufacturers, and even that functionality would really only be used in corp scenarios. For example, your company probably wouldn't want to allow authentication using a hardware key manufactured in Russia.
The complexity of technology which will make us more and more dependent on it. IT hallucinations didn't start with chat GPT. You will need n*n thingy to be able to authenticate, you will store some stuff on the cloud, some clever dudes will be able to access it ( as we know it is not a mater of if but of when ) and then they will use your identity ( your fancy identity ) and you won't be able to do anything about it.
Nice vid, question that someone might be able to answer this silly question -- how does this work if I login from device A and then login with device B in the same github account? does the server now have two public keys for my single account?
Yep, unless your private key is being synced across devices
Yep, either server has two keys or you share the private key using an app like 1Password. By default it’s the prior
@@SharlosRevenkai Cross Device Authentication is also an option -- effectively sending the authentication request to another device without really syncing the keys. With persistent linking, the other device just becomes another option among others from which you can choose when authenticating.
This isn't cloud syncing since I'm not even signed into my Chrome browser on my laptop. It basically communicates via bluetooth somehow.
That's the one complaint I have about passkeys though that is making it difficult for us to really adopt it more at work. The UX is great if you are all-in on either the Google ecosystem or the Apple ecosystem, but less so if you have a more heterogeneous setup, like a Windows laptop and an iPhone. You can either use the OS level platform authenticator and bind the passkey to that single machine (which probably isn't going to sync anywhere) or use your phone, but since Chrome and iPhones don't support persistent linking between each other, you have to scan a QR code on chrome every time. That was a pretty common scenario that failed our UAT process.
Things like Bitwarden (and 1password, I'm sure) kind of side step that issue at least on desktop. I'm not sure how/if password managers can be used as a passkey source for mobile yet. I sure haven't had much luck with it, although my primary testing ground has primarily been an Android phone running GrapheneOS rather than the standard Goolge suite.
"prime numbers shout out prime" killed me
I always wondered why a public key is called public key and not just public lock...
Btw it's not a "rombus", it's 90deg angled. It's a rounded square rotated 45deg. But then you gotta know basic geometric terms xd
Yep, while watching it I was like wait a minute.... a rhombus is basically a parallelogram like a diamond. heh
Pedantic, but wrong. A square is by definition a special sort of rhombus. The same way a cat is a special sort of animal.
Square extends Rombus {
does it make u happy correcting minuscule mistakes in other's speech xd
Bitwarden also supports passkeys on their free tier.
Where crypto is concerned, the reason such signing all the time was doable, was because all the energy heavy processing was distributed. The environmental impact of bitcoin has been well documented. Maybe remember y'all are standing on the shoulders of PGP. The whole crypto world has only survived this far because the processing and energy costs are being made somebody else's problem and even then has the artificial value it claims to prevent worse than any 'fiat' currency.
No company wants to be providing free services like this unless the cost can be almost zero itself and it's made necessary by the failures of existing systems. Yubikeys are great and very simple but also cost more than most people would be willing to pay. Maybe in 10 years we'll all be moving on to something else.
But what protects the private key from theft? With PGP and SSH you typically have to enter a password in order to unlock the private key, before it can be used.
Same thing with passkeys. They're protected in your systems keychain just like an ssh key
In an ideal setup (which is 90% of devices in 2024), the private key is generated on a separate hardware device like a TMP module or a FIDO2-compliant security key (like a Yubikey). The key never leaves the device, either-all you get are the signatures and encrypted data you ask for. The device can implement their own forms of user verification; for example, when using my Yubikey with Cloudflare, they require me to use a PIN with the key.
There's a bunch of security measures in place that make it effectively impossible to pfhish even a single signature out of a device without direct software access, too. And on mobile, it's locked down by app.
4:45 he just casually generated my database password 😅
This suffers from the exact same issue password managers generally create - lack of portability. What happens when you have to quickly sign into your email on a work computer, at the library, at a friend’s house, etc.? Most people use computer that are not their own sometimes and this would make logging in through said computers virtually impossible meaning you could easily run into major issues if you switch to passkey auth even if you fully know what you are doing.
That's where phone-based passkey auth comes into play. Most modern devices (Macs, Windows 11 [but not 10], Android, and IDK about iOS but Apple's pretty good about this so maybe) support using your phone to scan a QR code, the phone signs the request, and sends it back done and dusted. Lets you use your phone just like a FIDO2 security key. Does not create lasting credentials on the device; only one auth session.
What exactly is the "revolution" with yubikeys? They still require a password, and now I constantly have a flimsy, easily breakable, USB stick taking up one of my ports.
They don’t require a password. If you use them as a passkey, all you need is the yubikey (and possibly a short PIN).
Of course, you can also just use them as a 2nd factor for logins that still require a password, too, but that’s not what this is about. Passkeys go a step further and get rid of the password.
If you are concerned about breaking or loosing the yubikey (or any other hardware key that supports Fido2, for that matter), just get a second one as backup and set up all accounts on both, but only use one for regular usage and have the other one in a safe place.
@@johannesloher2817 I use it at work, and we have to enter in a password every time we use them for authenticating in an application. Maybe my situation is different. Also, setting them up on the computer was a pain in the ass.
@@johannesloher2817 Some services do request that the authenticating device do something called "user verification"; for a standalone FIDO2 security key, this typically means entering a PIN. Not all services request this.
@@johannesloher2817 Getting rid of all additional factors so that only the passkey is necessary will be a monumental blunder of predictable mayhem.
My work requires a min 12+ alphanumeric special character password + yubikey. I actually want to stab out my eyes by the time I get into every application required just to start work. The yubikey is wire chained to the actual PC too so hopefully it's in a port you don't mind sacrificing forever cause it's not moving 😂🫠
Love the simple explanation
“Too-fuh” bruh what
Passkeys aren't the path forward, the biometrics your device (more than likely) already uses is.
Another sponsored read?😐
Ok but it's actually good info, which isn't a clerk specific feature. Passkeys are awesome for UX and security.
To be fair this is a really big issue ATM and we're even talking about this in my work right now. So, it's helpful.
What's the problem 💀
Tbh really liked the video
All the darkweb plays are getting popular in the mainstream
There will be just as many calls for help and time and money spent by help desks. People are dumb and they're also not their computer or phone! At the end of the day a password has to be somewhere and this just adds complexity to that people won't work with well.
I prefer webkeys to passkeys. There's no need to "log in" at all, and I don't need a user account that can be used to track me.
2:40 remind me of bitcoin, the blockchain .
Okay but how do you store and sync the private keys to protect against the case of your computer going haywire?
Your access to services you registered to using the private keys on your now-dead client is gone unless you can recreate the private keys,
in which case we're back to square one: passwords or using a third-party cloud solution, which beats the entire purpose of offline and interaction-less safekeeping.
Biometric? Do you not mean Bioimperial?
Real, data collection in disguise.
Basically kerberos for everyone
Crazy how people bash blockchain but it's literally just doing this and keeping track of things on a public ledger.
Its all good but comparing them with stats like password leaks in social media is not suitable right? I mean, the main adv of choosing a username password approach is cus its ability to be device independent (which is what any social media needs?) unlike crypto which are device dependent?
Yes! Nobody needs to make a new username at any point... just use public keys as usernames and private keys as passwords. Problem solved.
6:30 - this is simply false and it's a common misconception about asymmetrical cryptography. Both public and private keys can lock AND unlock what was locked by the other. By encrypting with the private key and decrypting with the public key (which everyone can do bc it's public) you obviously can't hide sensitive data but you can actually prove it was "signed" by the owner of the private key. And this is how what he wrongly described at 5:40 actually works. The server doesn't lock with the public key, but instead sends you a string, which you encrypt with your private key, send back and they decrypt with your public key to see if it matched with what they sent initially. If it doesn't, obviously you don't have the right private key which means it's not you.
Edit: I arrived at 9:00 - the part where he realizes his ignorance
24:00 that has existed for almost 2 decades, but obviously with AI it's become a lot easier.
could be a nice going over the javascript/client side Apis of passkeys on another video :)
Ill stop using same passwords when companies stop requiring a mandatory change of pass, or require caps non caps numbers and 1 of ONLY 4 specific Special characters and over 8 characters, like at that point just give me an acceptable password i aint thinking of all that
Seems wild to discuss this without mentioning recovery. What happens if my phone breaks? Either it’s possible to access using 1fa or it’s impossible to recover. Has this been solved in some way?
That's the real tradeoff, now isn't it. Even if you have a hundred passkey'd devices, you can lose all hundred of those and lose access. There's a distinction I heard once between different authentication factors. "What you know" would be something like a password or your mother's maiden name. "What you are" would be biometrics (fingerprint or Face ID). "What you have" would be something like, say, a private key stored deep in the depths of your machine's TPM or similar kind of hardware authentication chip. The problem with "are" authenticators is that you only have one set of fingers and one face. Password reuse ensues. Someone pfhishes your biometrics and you're done for. Can't use those. I think we've all seen the problems with "know" factors by now. You forget, it gets leaked, the database gets hacked and it turns out the service only encrypted the password with an encryption key that's RIGHT THERE and now they have the password you used for 100 different sites because password reuse is very common, etc. "Have" factors are the last remaining bastion. But, of course, these are suceptable to losing access. But so are your glasses. So are your car and house keys. So is your phone. So the next best option is to do what you do with your car and house keys. You make copies.
So, the tradeoffs tl;dr:
"know" (passwords, mother's maiden name) is suceptable to leakage, forgetting, and very much so to cracking
"are" (biometrics; fingerprints, FaceID) is so pfhishable it should only ever be used locally
"have" (keys, devices) can be lost relatively easily
Seconded on Google's borked 2FA verification requirements. I hate those extra steps so much...
The thing is, IF the attacker was able to sign into the database/redis cache with the public keys, he could change them to his public key, right?
That will mean that on next login attempt (done by the hacker) he will have a successful login and thus access to the entire account. Am I right?
If a hacker compromised a service, that usually means they have access to the service, yes.
Passkeys are cool, BUT they seem more of a way to vendor-lock authentication to apple, google and microsoft, rather than actual open standard everyone can benefit from.
Passkeys would be great if they worked. All the browsers want me to use a physical security key, which seems risky as a single point of failure but also complete overkill. If all it is is public key cryptography, there's no reason I shouldn't be able to store those keys locally on this computer (I know it's less secure, but my threat model doesn't include anyone accessing my local files so I don't care). I get pushing for that or biometrics by default, that's a great idea, but please, there's no technical reason to *force* me to do that. It's supposed to be a *user* agent, as in, *my* agent, why is it fighting me? When you say it's public key crypto, it sounds so simple, but then I see the mess of a standard and the horrible UX and it's just not simple.
For now, I only see big tech companies having decent implementations, but with no clear way to export keys, so it just looks like vendor lock-in to me. User agents need to standardize on a way to interface with extensions or programs that actually manage the keys, otherwise there's no way for me to actually use it.
BTW, this is one of the reason why Windows 11 will not install without a TPM.
AI that can guess what I type based on sound?
Me with 12 different switches: Yeaaa.... No.
Unless it trains with my specific keyboard, than I am fucked faster.
12 in one keyboard? Wouldn't that make it easier to predict?
@@quinnherden Guess it depends on the AI. If it just predicts the volume of each keystroke, it will not work.
But let it know and hear a few sentences I have written and I am out of luck.
26:13 x86 and windows do have this. ever heard of tpm? the stuff that everyone complains about being a windows 11 requirement? or what about microsoft pluton. its so "secure" that it will not allow you to use any operating system which is not windows. i do not want that. also that has nothing to do with passwords vs passkeys, this is against someone getting physical access to your machine and doing stuff like reading your ram. completely different attack and has nothing to do with anything in this video.
The company i work at, recently started using fido. It's great when it works and the suite that we use has a password auto renewal. The only problem is that sometime when the password auto renew, it dosent sync up with ldap. So we can log into our computer but any software and or web access that requires our ldap log in dont work.
What!!! use a password manager folks!
And not give ALL your keys to a central server for ALL your sites. The best protection is spreading out risk, not consolidating.
@@BillAnt so use a local password manager such as keepass
also vaultwarden
@@JohnFarrellDevever heard of password stealers
@@BillAntI don't think you understand the technology discussed in this video. There is not a central pass key server
I have yet to find a video where someone actually does a good job of explaining passkeys, and unfortunately this video also misses the mark. Judging by the comments it seems tons of people are still confused and don't understand the benefits compared to passwords and other public key cryptography authentication flows.
i always thought that only private key can "encrypt message" and then public key is the one "decrypting it" verifying in the process that "yes it was encrypted by one human, the one holding private key". You said multiple times that it can work in the reverse where anyone can "encrypt with public key" and only i can "decrypt with secret key". We learn everyday i guess
Well, using private key on message actually signs it - verifies that owner of the private key that matches public key associated with an entity is the author of the message. Encrypting is done with public key, because it makes it unreadable for everyone except of the owner of the private key.
Public key is, by definition, "public". If public key was the one responsible for decrypting messages, anybody could decrypt the message. So of course it has to be the "private" key which decrypts the message.
@@Gornius i thought this is how symmetric keys work (done some AES encryption on one project), while public/private i thought are asymmetric, so encryption goes just one way (private encrypts, public decrypts) ....probably just need to read on this
You can infer the public key from the private key but not the other way around.
@@alexsmart2612 hold on, but the point was (i thought) that anyone can read the message but its verified to come from the sender with private key without anyone changing its contents. This whole signing idea is the one way it should work ...the other direction is the news to me. So really the public one can "decrypt" for sure
25:44 I'm sorry but... biometrics, which every time Apple does a new release, is broken within 2 or even 1 week after release with a cheap documented solution to circumvent it.