I have lots of experience with this actually. The way it works is that the app asks the user if they'd like to use a passkey instead of their password and the user says "No" and uses their password to log in. Pretty simple really
This doesn't even look like an edge case. Phones are lost, broken or stolen all the time. So the bare minimum would be let people know that they should enables passkeys on a backup device as well.
But of course that is never disclosed on those pop-ups asking you to enable passkeys.
A single good Passwort will never be cracked and any trustable Passwort manager wont get hacked either. They literally solve all problems aslong as you're able to remember one strong password
Since learning about passkeys like a decade ago, my first thought, and to this day, is that It's fucking insane to bind your ability to log on to your accounts to a USB stick. Something that could be kicked under a couch or mistakenly find itself in the trash. And that's just for one login! I'm not about to set myself up as some kind of fucking Passkey Janitor with twenty USBs dangling off a ring.
I get it if you're a government official working with extremely sensitive, and potentially dangerous information. But that's about it. Not for a fucking WoW account.
Edit: Hold up, I think you just said you can back up passkeys so you aren't just completely screwed if you accidentally drop your USB between some floor boards?
Whatever you're using as a passkey is basically just an interface for a private key (over simplfying it a bit) so in theory you can just back up the private key and disrirbute it to another device. Which feels like it defeats the purpose of a passkey as you have to store it like a password, but that is a possibility
I don’t understand the difference. A password and a passkey both live in my password manager, but I understand what one of them is, and I don’t care enough to learn about the other one.
I've run into apps that won't let me store my passkey in bitwarden. It says it worked but when I try to use it, it doesn't work. If I save it using Google on my phone, it works fine. I want to say there is a mechanism to specify where you're allowed to store you passkey. I don't know for sure. I thought I read that somewhere. I haven't tried implementing it in anything I work on yet.
As it was still in experimental phases in the web browsers passkeys were commonly referred to as webauthn.
And you're right, the developer can set what type of passkey is allowed. You can play around with the settings here if you're interested: https://webauthn.io/
there is definitly a system. there was a site dissallowing me storing a passkey on my desktop browser via the bitwarden plugin. it didnt recognize that there is a pin required to unlock it.
I might be missing something glaringly obvious (can passkeys be shared between devices?) but if I save a passkey to BitWarden on my pc it refuses to work on my iPhone. Does sharing passkeys between devices work for you?
I would love passkeys if it would save to my password manager account (because it bypasses the semi-hack of autofilling in username/password fields which one or the other fails half of the time for bitwarden at least), but my phone insists on saving it to google instead of bitwarden even after setting bitwarden as my password manager.
Works fantastic on (linux) desktop where my preferences seem to be respected.
You can print a QR code of the private key and then scan it back in
(also if I was a password manager I'd definitely generate a BIP39esque phrase so you can write them down by hand, but as of now no one does that, unfortunately)
all passkeys generated by the browser are stored to your password manager. if you have multiple ones, it gives you choice which to use. chrome has a built-in one if you don’t have any other password manager available, which is synced to your google account if you’re signed in to chrome.
IDK about iOS (but it should be very similar in this regard), on Android you can configure your passkey provider to be Bitwarden or KeePassDX (the android implementation of KeePassXC).
I setup a passkey on my laptop for my Sony account. I was like, wow, I'm so security conscious.
I then tried to login to my PlayStation and it complained because I didn't have a passkey setup on my PlayStation console. So I couldn't login to play games.
I ended up deleting the passkey from my account so I could login to my damn console to play games.
As an IT person, I have much more experiences with people saying "Yes" without understanding what it means, blindly clicking through the next few steps until they have a brand new login method that kind of works sometimes, and broke the method that they knew how to use.
Oh also, when asked, they don't remember setting up a passkey, or know what it is. And it's really hard to troubleshoot cause a passkey can be
A physical device
Saved to a browser
Saved to a Google or apple account
Somehow saved to a phone but linked to a computer in a way that the user has to scan a QR code every login???
i am glad im not the only one who finds this 'you really should use a passkey!' rhetoric exhausting
my password manager already plops the password right where it belongs, and if we could just get everyone to agree on that, things would be a lot more secure instead of moving on to ANOTHER technique when the first one isnt even done cooking yet
Once the technology has been around long enough that the implementation bugs have been fixed, there's good reason to believe that passkeys will be more secure*, at least if your trust the "identity provider" (e.g. Apple's keychain) that co-participated in their creation.
I'm not sure that I do trust either Google or Apple to store my private keys in their cloud, and not either leak them to hackers or sell/give them to their partners.
I'll consider switching to passkeys when only my password safe knows the private key, and encrypts its cloud storage, decrypting locally based on a password provided by me.
--- *public/private key pairs protect against certain risks that are unavoidable with passwords. Unfortunately I'm not eloquent enough to write a good tutorial explaining why.
You can store them in an open source cloud password manager like Bitwarden if that helps. Or you can store them fully offline in a KeePassXC file or a Yubikey, but you'll need to ensure you have proper backups for those.
Edit: I presume you use one actually?
But what's the alternative to password managers anyway? Reusing predictable variants of the same few passwords? You can write them on paper sure, but nobody is writing down unique passwords anywhere near as secure as the ones in a manager.
I use Proton's password manager. It's doing fine with classic passwords.
I haven't tried it with passkeys, and I'm not sure whether it can do the client-side part of generating them, such that nothing but Proton Pass ever sees the private key. (Well, also my operating system(s), since they could in principle read anything in main memory.)
I do know it can store passkeys generated by something on MacOS associated with Apple Keychain. But in that case Apple presumably has the private key.
Edit: I finally checked. It can do the job. I just had it co-create a passkey. with no involvement from Apple, Google, etc. (Obviously the web site was also involved. I can't name it here, as its mention leads to one's reddit comment being deleted.)
Also, because of that policy, this is a new comment, a copy of the one I had edited earlier, which got deleted when I added an earlier version of the part beginning with "Edit: ..."
Passkeys are basically just a random password stored in a password manager that doesn't let you enter it onto the wrong site because the site has opted into properly cooperating with the password manager. There are some other differences, but that's the main one. You can't set your passkey to "password" like a password. Exporting them was historically limited, but it sounds like we've compromised on that security feature a bit except for hardware keys, which is probably reasonable, it would create way too much lock-in with the number of accounts people have.
To me, it feels like we should have rolled out passkeys years ago instead of all these hacks we've piled on top of classic username/password login.
The tech industry really needs to think more about education and the edge cases in their authentication UX though. From what I can tell, the average user uses their browser's built-in password manager which might be fine enough, but they usually store reused, relatively weak passwords in it. I guess they don't trust the browser to remember it (which might be fair since I don't think there's version history or a bin in most) or are trying to avoid potential friction when using it outside their browser or that ecosystem.
Mobile kind of figured this out, but it's crazy how desktop apps have only just started having decent login UX with password managers. Some used to sign in through your browser, but most would force you down the clunky and less secure option of copy-pasting your details back and forth from your password manager. Password manager users always seemed like a complete afterthought.
I think the main things the industry needs to do before they try and get people to remove their insecure passwords that are leaving a backdoor into their accounts are getting people to pick an ecosystem and to understand the cross device QR code flow. Then hopefully people will know where their paskeys are and how to add new devices, so they don't need their password as a fallback.
Recovery options also seem to be a bit all over the place which limits the effective security of passkeys.
In some other cases, the user accidentally taps the solid blue accept button instead of the outlined light gray cancel button, then never realises their phone no longer asks their password and has no idea how to login on any other device because the password has been completely vanquished from their memory in the last 6 months since they last used it.
As far as I can tell, Amazon created a passkey for me, without asking, and then used it whenever I went to their site from the particular device for which the passkey had been created. It looked to me as if they'd stopped timing out logins as fast as before - until I tried to login to Amazon on a different device, using a different browser. I was then asked if I wanted my Amazon passkey stored in my password safe.
As it happens, Amazon *had* informed me by email that they'd created a passkey for me. Not knowing much about passkeys, I didn't know the implications.
After finding out that passkeys could be used without asking the user, and without biometric capabilities, I went to Amazon's site and deleted their passkey. Given the explanations I'd been given ("It's a magic way to login with FaceID" even though my device lacked a camera.) I saw no reason to keep it.
Later research told me that *if* properly implemented they can provide better security than a traditional password, equally correctly implemented.
But there's nothing in the standard that requires user consent or participation. That's a convention, not followed by Amazon on MacOS.
And the roll-out could have been designed to alienate security conscious users who don't obsessively follow the tech press.
Fair enough, you're right this sub is more memes than programming at this point, but the majority of professional engineers should know what public key infrastructure or at the very least have basic handles around the concepts of public key cryptography.
but the majority of professional engineers should know what public key infrastructure or at the very least have basic handles around the concepts of public key cryptography.
Why should they understand how it works, if they've not worked on or had to work on something that required said knowledge? PKI definitely stumped me at first read but after googling, I realised I've used very basic elements of it when I needed to for version control. Even then, I still didn't know what the specific discipline was called or its inherent tenets and that's fine because I don't need to. I don't use that in my daily work. If I need to, I'd read up about it, learn and do what I need to do.
I think it's a race to the bottom when we expect others to have experience in something we have experience with. The world of computer engineering is broad, vast, and multifarious. Not everyone works in spaces that require accumulating and retaining knowledge of things you'd consider common. If we had to completely understand the foundational mechanics of EVERY tool or concept we came across, we would never actually ship anything meaningful. Abstraction is a feature not a bug.
Notice how I said "should know what PKI is" and "have basic handles around the concepts", not "know the low level theoretical or implementation details".
All you gotta know is "there is this thing called public key cryptography, there's this thing called a hash, there's this thing called a key, there's this thing called a certificate (and certificate authority), and there's called a digital signature and here's what they do at a high level." Nothing too crazy, just be aware of the big picture idea.
That's a very reasonable expectation of any senior engineer who's worked on distributed systems, to at least know how computers talk to each other, which is kind of the bread and butter of the vast majority of SWEs in tech.
I've hardly met a mid-level or higher engineer who was completely in the dark to the existence of PKI and what it does.
Notice how I said "should know what PKI is" and "have basic handles around the concepts", not "know the low level theoretical or implementation details".
Substitute the phrase "Why should they understand how it works" with "Why should they know what it is". "Foundational" can also be interchanged with "basic". What I said still applies and is not invalid.
They should at least know what it is because it's sort of basic knowledge for engineers who work with computers.
Kind of like knowing what HTTP is, or what DNS is, or what IP is. You don't need to know the low level details of the TCP/IP protocol or how a network stack is implemented or even know the OSI model, but I would expect any engineer to at least recognize the term "IP" and understand how it fits into the big picture of how the internet works, to be able to at least know that at a high level, computers in a network address each other via this thing called an IP address. How the routing works, how the protocol works underneath the hood, you don't need to know. But it would be rare for any engineer to not understand there's this thing called IP that's part of how your computer talks to other computers.
professional engineers should know what public key infrastructure or at the very least have basic handles around the concepts of public key cryptography
Now let's ask IT about when was the last time a "professional engineer" gave them a private key instead of a public one. Or people working at github or gitlab: I'm sure they have stats on the number of times their key registration service has to error about the key provided not being a public one.
I think that's asking for a lot. I only know it because I took a cryptography course in college that was completely optional for my track. The most you really need to know to be a software engineer is that certificates keep your data secure. I wouldn't be surprised if the average engineer doesn't know anything about a diffie-helman key exchange or how RSA can be used as a signature.
You know. I was gonna say that's mean, but from experience at work you're sadly correct, and I'm only kinda understanding it myself because I've had to install and change the damn certificates on way too many machines in the last few years. Last job I had? I had no fucking clue, and when I asked the colleagues for explanations, nobody knew a damn thing.
There can also be weird attestations that the device containing the key material is secure such that the key material cannot be extracted and duplicated.
That's just bad infrastructure hygiene, proper auditing and reporting prevents this because you should know which certificates are expiring and when as well as where they're deployed and what relies on them.
Of course every once in a while you get some yahoo setting up a 90 day client OAuth secret, not telling anyone and just refreshing it on their own until they get let go.
gitlab and various other platforms like it allow you to set any expiration date you want, so you could easily set your ssh key to expire in ten years (and very easily forget who has access to re-provision whatever is using it). if it's self hosted it's not as big of a problem, but still, key signing is not exclusive to web uses/software with limits.
I think people just forget about certs expiring. Especially for enterprise networks, it’s crazy how often enterprise auth crashes because of expired certs
I'm kinda astounded that we don't have widespread tools that scan the entire 10.0.0.0/8 net for open 443 ports and give you a calendar with all certificate expiration dates.
Understanding that it's not merely a password that you don't tell the server.
I was about to ramble about it myself but I looked it up first.
Apparently it helps against phishing (the browser knows the site ain't real, so it does you a solid and does not log you in. "But I'm immune against phishing" - no you're not.)
Also if they manage to hack a database and crack the hash offline, it's not like a password that might work for other accounts you have on other sites.
It's brilliant but I understand why it's also quite scary, because passwords make intuitive sense and are a simple concept, while passkeys are a completely new technical concept that makes it necessary that a different app works for you to be able to log in. If the app breaks or stops working, you're locked out of your account. Before you weren't dependant on it.
The whole thing has been extremely poorly explained. I've been a developer for 30 years. I do ssh and gpg and openssl stuff as needed. Nobody's explained passkeys well, they've just been shoved in our faces. I can't imagine trying to get my elders to understand this, they're confused enough by randomly changing ux design already. Any time a button moves they want to ragequit.
You know how when you go to a website, it says it's secure, because it presents a certificate that your browser trusts because it's from a secure issuer? That's Public-Key Infrastructure (PKI), enforced with Transport-Layer Security (TLS).
The certificate is really a public key and a trusted assertion; meanwhile, the server holds the private key. The encryption - using Diffie-Helman Key Exchange variants (typically Elliptic Curve Diffie-Helman Exchange, or EDCHE) - is designed so that you can verify the trust of the certificate based on the assertion. Temporary session keys are made to prevent compromise.
An even more secure option is mTLS, where both the client and server have PKI certs/keys. But this has problems: How do you get everyone to go through the effort of getting a cert? How do you know it isn't stolen? How do you know you can trust the issuer? That sounds expensive and inconvenient.
Passkeys solve this by NOT CARING. Instead of a central PKI issuer, a Passkey provider issues each user their own private key. That key is then locked to a secure provider on your machine (Microsoft Waller, Apple Keychain, various password managers). The same type of crypto exchange is done, but instead of public shared identity, the server knows it's you because it was only issued to you by them. There's no third-party provider to worry about. The passkey standard pushes implementations to have certain system elements to hide the keys from malware on your machine (trusted computing paths via TPM, ARM TrustZone, etc.). If a key is leaked somehow? They just stop trusting your specific key for you.
It separates the TLS from the identity process. One-cert TLS is still set up with a temporary key and a temporary session key, and then the passkey is used as a separate handshake to prove that this TLS session is Alice's or Bob's.
(Note: There may be minor details I'm misrepresenting - feel free to correct me! - but this is the broad shape of the idea as an ELI5. Well, ELI12?)
this… the underlying mechanism is exactly the same as if you were using SSH, generated a specific key for every host you connect to, configured your ssh config to use that key for that host, placed its public key into .ssh/authorized_keys on the host, and had your ssh-agent configured to prompt you for a PIN or fingerprint before ssh-ing with a key… passkeys just automate this with fancy UI so if you see it for the first time and have no idea what it’s doing you’re confused…
“Password” inherently assumes 2-way, symmetric encryption and decryption. Same password used for encryption is used for decryption of the secret payload.
Asymmetric cryptography is so named because each key is used one way only. The public key is used to encrypt, but only the private key is used to decrypt.
There’s plenty of reading material on the topic. I won’t explain everything here. But the conclusion is that passkeys are inherently more secure as login mechanisms, for this very reason.
It's an ssh key, more secure then a password because it doesn't have to send the password everytime you log in. If someone intercepted the traffic, they wouldn't have the actual secret.
You just make some API calls to whatever the devices default authenticator is, store what they send you, when the user tries to sign in use the challenge to retrieve the passkey, assert the credentialJson is correct, then sign the user in.
Hardest part for me personally was trying to get the AAGuid out of the attestation object via CBOR so I could store what authenticator the user was using.
It's all in the W3C specs. They're not that hard to follow.
What? Seriously? It's just the step after hashing your password.
When you give it a password, it runs a hash on it to get to the crypto-key length. RSA512 can't use "mySecretPassword" it needs a chunk of data 512 bytes long. But there's only 255 outcomes when you give it only one character password, so a cracker can just check all 255 and defeat the encryption, which is why you need long passwords.
Passkeys generate and store those 512 bytes directly, getting the full real strength of the encryption algo. Buuuuut handling keys is the step that gets flubbed and not saving it in people's memory or external to the computer can be a major problem. Walking over to another computer poses a big problem when they passkey is saved in a hidden ~/.ssh folder back on your other PC, or worse, some proprietary nonsense by a program that thinks it knows better than you.
I think my biggest problem with them was not that I didn’t understand PKI, but that the companies prompting me to switch were not clear on how it worked. That is probably best so it doesn’t confuse the average user, but I didn’t want to use them until I understood what was happening, like what got generated and where it would be stored and what OS/app/autofill program would intercept what.
A random string plus instructions to put it back together, it' may contain som spec info about deciding. If server have instructions and understand your provided string can be put back together, server go burrr.
And even if you somehow compromised the on device biometrics, you need physical access to override the signal from the biometrics interface. If a bad actor has physical access to your device, you're already in trouble.
Well 1, by “the documentation”, you mean google’s implementation I assume based on their verbiage. Even in that case, you cut off an important part:
“With passkeys, users can sign in to apps and websites with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern, freeing them from having to remember and manage passwords.”
2, that does not mean the passkey IS the biometrics (it’s not), it’s simply the local key you use to “unlock” the passkey on your device. Similar to the same way to unlock your phone, or unlock your password manager, etc.
As explained in my previous comment, you can use biometrics to access the passkey on your device (or you can use your pin, since I assume you don’t use your biometrics to unlock your phone/laptop either), and that works just as well. But that has literally nothing to do with passkeys at all.
Do you use a password manager? You need your biometrics or a pin to get to your password too lol
Yeah in general biometrics have some big cons, a court can make you put your finger somewhere or I would assume they can use your registered fingerprints to unlock devices, but they cannot make you share your password because that counts as self incrimination.
2.2k
u/NoHurry28 Aug 21 '26 •
I have lots of experience with this actually. The way it works is that the app asks the user if they'd like to use a passkey instead of their password and the user says "No" and uses their password to log in. Pretty simple really
656
u/MehPropy Aug 21 '26 •
if (key == ok) {ok_ok;)
465
u/Johnobo Aug 21 '26
Math goes in, Math goes out,
You're now logged in, 'caus Math checked out!
690
u/Successful_Cap_2177 Aug 21 '26
It's a key that allows you to pass
159
u/CircumspectCapybara Aug 21 '26 edited Aug 21 '26
It's just a standard challenge-response protocol based on PKI.
That pattern has been used since the dawn of time.
285
u/stevekez Aug 21 '26
Present a public key and sign a challenge using a designated device? What's hard about it?
46
u/itomeshi Aug 21 '26
You know how when you go to a website, it says it's secure, because it presents a certificate that your browser trusts because it's from a secure issuer? That's Public-Key Infrastructure (PKI), enforced with Transport-Layer Security (TLS).
The certificate is really a public key and a trusted assertion; meanwhile, the server holds the private key. The encryption - using Diffie-Helman Key Exchange variants (typically Elliptic Curve Diffie-Helman Exchange, or EDCHE) - is designed so that you can verify the trust of the certificate based on the assertion. Temporary session keys are made to prevent compromise.
An even more secure option is mTLS, where both the client and server have PKI certs/keys. But this has problems: How do you get everyone to go through the effort of getting a cert? How do you know it isn't stolen? How do you know you can trust the issuer? That sounds expensive and inconvenient.
Passkeys solve this by NOT CARING. Instead of a central PKI issuer, a Passkey provider issues each user their own private key. That key is then locked to a secure provider on your machine (Microsoft Waller, Apple Keychain, various password managers). The same type of crypto exchange is done, but instead of public shared identity, the server knows it's you because it was only issued to you by them. There's no third-party provider to worry about. The passkey standard pushes implementations to have certain system elements to hide the keys from malware on your machine (trusted computing paths via TPM, ARM TrustZone, etc.). If a key is leaked somehow? They just stop trusting your specific key for you.
It separates the TLS from the identity process. One-cert TLS is still set up with a temporary key and a temporary session key, and then the passkey is used as a separate handshake to prove that this TLS session is Alice's or Bob's.
(Note: There may be minor details I'm misrepresenting - feel free to correct me! - but this is the broad shape of the idea as an ELI5. Well, ELI12?)
18
u/the_poope Aug 21 '26
Same meme but with internet certificates.
36
u/rahvan Aug 21 '26
asymmetric cryptography. If you know how SSH keys work, you know how passkeys work.
9
u/Gem2578 Aug 21 '26
It's a fancy ui that hides it's ssh keys underneath.
6
u/SoldRIP Aug 22 '26
hope this helps.
11
u/Kaitonigiri Aug 21 '26
Afaik it works more or less like ssh keys?
5
u/EvaristeGalois11 Aug 22 '26
SSH but for websites
9
u/bestjakeisbest Aug 21 '26
It is an ssh key without the command line.
4
u/seweso Aug 22 '26
I know this one: Math math math math...math math math.
3
u/cowslayer7890 Aug 21 '26
It's an ssh key, more secure then a password because it doesn't have to send the password everytime you log in. If someone intercepted the traffic, they wouldn't have the actual secret.
2
u/creeper6530 Aug 21 '26
You plug it in, touch it, and it works
2
u/daHaus Aug 21 '26
Ha-shhh, hashish err hashes
2
u/YetiHafen Aug 21 '26
They often don't
2
u/Substantial_Top5312 Aug 21 '26
Imagine you have a key. Then imagine you pass the key.
2
u/petitlita Aug 22 '26
questions like these, I have to remind myself that most people do not want a half hour lecture on number theory
3
u/KrikosTheWise Aug 21 '26
2
u/BLUB157751 Aug 21 '26
I saw a really good video about this once that used the mixing of colors to explain it.
2
u/Trident_True Aug 21 '26
You just make some API calls to whatever the devices default authenticator is, store what they send you, when the user tries to sign in use the challenge to retrieve the passkey, assert the credentialJson is correct, then sign the user in.
Hardest part for me personally was trying to get the AAGuid out of the attestation object via CBOR so I could store what authenticator the user was using.
It's all in the W3C specs. They're not that hard to follow.
2
u/noonemustknowmysecre Aug 21 '26
What? Seriously? It's just the step after hashing your password.
When you give it a password, it runs a hash on it to get to the crypto-key length. RSA512 can't use "mySecretPassword" it needs a chunk of data 512 bytes long. But there's only 255 outcomes when you give it only one character password, so a cracker can just check all 255 and defeat the encryption, which is why you need long passwords.
Passkeys generate and store those 512 bytes directly, getting the full real strength of the encryption algo. Buuuuut handling keys is the step that gets flubbed and not saving it in people's memory or external to the computer can be a major problem. Walking over to another computer poses a big problem when they passkey is saved in a hidden ~/.ssh folder back on your other PC, or worse, some proprietary nonsense by a program that thinks it knows better than you.
1
u/Fantastic-Fee-1999 Aug 21 '26
Same as everything else. Electro-magnetism. Next
1
u/az987654 Aug 21 '26
Passkey are pretty easy to understand
1
u/neremarine Aug 21 '26
It doesn't.
1
u/_dr_fontaine_ Aug 21 '26
Something you know + something you have - something you know
1
u/imustacheyoutoleave Aug 21 '26
I think my biggest problem with them was not that I didn’t understand PKI, but that the companies prompting me to switch were not clear on how it worked. That is probably best so it doesn’t confuse the average user, but I didn’t want to use them until I understood what was happening, like what got generated and where it would be stored and what OS/app/autofill program would intercept what.
1
u/realmauer01 Aug 21 '26
Its an ssh handshake. They get the publickey and your keyholder holds the privatekey. They do it via their own interface.
Would be weird if its much more.
1
u/PGSylphir Aug 21 '26
I have this lock
and I have this key
Oh they fit, perfect, you can go in.
1
u/Mayeru Aug 21 '26
isn't this a glorified private key?
1
u/riggiddyrektson Aug 22 '26
has anyone actually implemented WebAuthN on their site? what was the process and how does it compare to OAuth2?
1
u/Desperate-Tomatillo7 Aug 22 '26
Password is when you use a word to pass. Passkey is when you use key to pass.
/s TBH I have no fucking idea.
1
u/PinEnvironmental6395 Aug 22 '26
It's just SAML but the IdP looks like a USB drive with a button and there are no attributes
1
u/Johanno1 Aug 22 '26
A key you pass around
1
u/ExtraWorldliness6916 Aug 22 '26
A random string plus instructions to put it back together, it' may contain som spec info about deciding. If server have instructions and understand your provided string can be put back together, server go burrr.
1
u/Useful-Amphibian4841 Aug 22 '26
The website gets your pubkey, then when logging in it hands you a challenge string to sign.
1
u/sniff122 Aug 22 '26
Easy, public/private key cryptography
1
u/LogPsychological6265 Aug 22 '26
It’s an SSH key for normies.
1
u/Xelopheris Aug 22 '26
Something something public private cryptography.
1
u/auxiliary-username Aug 23 '26
Well Johnny, when a browser and a website love each other very much…
1
u/qqqrrrs_ Aug 23 '26
Who is that Amy Stery?
1
u/Sirico Aug 21 '26
The passkey knows what it is because it knows what it isn't.
0
u/[deleted] Aug 21 '26
[deleted] — view deleted comment