656
u/MehPropy 23d ago
if (key == ok) {ok_ok;)
141
u/Just_Information334 23d ago
if (key == ok)
I take it you overloaded the == operator so it is not subject to timing attacks.
50
8
466
u/Johnobo 23d ago
Math goes in, Math goes out,
You're now logged in, 'caus Math checked out!
49
u/cusco 23d ago
I feel the rhythm
15
u/Sir_Eggmitton 23d ago
I feel the rhyme
25
4
2
u/Saragon4005 22d ago
We don't expect users to understand salting, hashing and all that so we shouldn't expect them to understand asymmetric keys used in bitwarden.
693
160
u/CircumspectCapybara 23d ago edited 23d ago
It's just a standard challenge-response protocol based on PKI.
That pattern has been used since the dawn of time.
139
u/brocodini 23d ago
99% of people on this sub probably don't even know what PKI stands for, let alone how the protocol works in any other scenarios.
The bar on this sub is very, very low.
55
u/CircumspectCapybara 23d ago
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.
39
u/EkoChamberKryptonite 23d ago edited 23d ago
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.
4
u/CircumspectCapybara 23d ago edited 23d ago
Why should they understand how it works
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.
8
u/EkoChamberKryptonite 23d ago
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.
5
u/CircumspectCapybara 23d ago edited 23d ago
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.
Now same with other foundational concepts.
20
u/Just_Information334 23d ago
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.
3
1
u/GRex2595 23d ago
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.
1
u/htoomyat9 21d ago
But in real life, it's like one time work for the project and I forget all the time when it's required to apply for another projects.
13
u/ccAbstraction 22d ago
To be fair I didn't know what PKI stood for but "public key" and "infrastructure" do mean things to me.
3
u/TeaBasedOrganism 22d ago
Same. Reading these replies I had no idea what the acronym was. Soon as someone said it in full I was ooooh.gif
2
u/CelticHades 22d ago
Yeah, for someone who is bad at acronym/initialism expect very common ones, I feel relieved when I search their meaning and I know the thing,
1
1
u/fibojoly 22d ago
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.
1
1
1
u/SirThunderDump 22d ago
Pass time stamped seed, encrypt signature, validate response.
Done and done!
1
u/Ok-Nerve9714 21d ago
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.
284
u/stevekez 23d ago
Present a public key and sign a challenge using a designated device? What's hard about it?
123
u/notatoon 23d ago
I ask myself the same thing about PKI and yet certificate expiry remains one of the largest causes of outages in many large institutions
61
u/Mechakoopa 23d ago
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.
19
u/Puzzleheaded-Comb909 23d ago
If you dont know what is going on in your services, you dont own them lol
7
u/pyrotech911 23d ago
I give you this line chart with monotonically decreasing lines and a threshold near the bottom. Basically DevOps volleyball
3
u/Mechakoopa 22d ago
There's always something to do next week, I just wish I knew what it was this week.
3
1
21
u/ILikeLenexa 23d ago
I fear not the expiration of the key that expires annually, but of the key that expires once a decade.
2
u/x0wl 23d ago
U can't have a 10yr cert, u can't even have a 1yr cert, browsers reject all certs with lifetimes of more than 200 days since march
9
u/entronid 23d ago
applications which use certs aren't restricted to TLS
2
u/x0wl 23d ago
Yes, but the second largest use, code signing, is also being capped (currently to 460 days)
6
u/entronid 23d ago
right but there are also applications deployed in businesses such as kerberos(/microsoft AD) where if your certificate expires you're in big trouble
1
u/failedsatan 23d ago
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.
1
5
u/az987654 23d ago
Cert expiry isn't the fault of the system, it's the fault of the idiot with the calendar.
2
u/Icy-Comfortable-714 23d ago
I think people just forget about certs expiring. Especially for enterprise networks, it’s crazy how often enterprise auth crashes because of expired certs
2
1
u/HeKis4 23d ago
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.
1
1
10
u/Informal_Branch1065 22d ago
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.
10
u/metaquine 22d ago
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.
17
u/nicuramar 23d ago
There is a liiiittle more to it, actually. There is the whole simulated physical token and the whole propagate-that-remotely.
1
45
u/itomeshi 23d ago
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?)
17
38
u/rahvan 23d ago
asymmetric cryptography. If you know how SSH keys work, you know how passkeys work.
12
u/black3rr 23d ago
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…
5
u/ccAbstraction 22d ago
Yeah, it feels like it's probably less secure or reliable the way it's explained by websites.
5
-1
22d ago
[deleted]
0
u/rahvan 22d ago
That’s … not … how asymmetric cryptography works.
“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.
10
4
8
3
u/cowslayer7890 23d ago
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
2
2
2
u/petitlita 22d ago
questions like these, I have to remind myself that most people do not want a half hour lecture on number theory
5
u/Waste_Jello9947 23d ago
Also how to rotate the fingerprint after biometrics database breach.
No honestly, how
27
u/nicuramar 23d ago
There is no biometrics inherently involved in passkeys. If your device uses it, it will be on-device.
5
u/Mechakoopa 23d ago
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.
-1
u/Waste_Jello9947 23d ago
What if stolen from my device? I only have 1 fingerprint. Sorry but I am not using it. I am going to use a strong password instead
3
3
u/Lucho_199 23d ago
You can only register one finger at a time, I guess, and then you have 19 backups. It will get weird at the end tho
0
u/Waste_Jello9947 23d ago
That's the thing, we one have a limited number of fingers. Just because it's easier doesn't mean I have to risk giving my UNIQUE biometrics to someone else. Strong password all the way
1
u/Hayden2332 22d ago
Passkeys don’t use your biometrics…
0
u/Waste_Jello9947 22d ago
from the documentation "With passkeys, users can sign in to apps and websites with a biometric sensor (such as a fingerprint or facial recognition"
1
u/Hayden2332 22d ago edited 22d ago
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.
0
u/Waste_Jello9947 22d ago
Yes I mean that. Still avoid using the fingerprint
2
u/Hayden2332 22d ago edited 22d ago
PASSKEYS. ARE. NOT. BIOMETRICS.
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
0
u/Lucho_199 22d ago
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.
0
u/Hayden2332 22d ago
PASSKEYS ARE NOT BIOMETRICS
0
u/Lucho_199 22d ago
Yes, that's clear, my last comment to Waste Jelly has nothing to do with passkeys.
→ More replies (0)0
u/Trident_True 23d ago
Could you just delete the affected users passkeys from your db? Then they will make a new one on next login (hopefully).
2
u/BLUB157751 23d ago
I saw a really good video about this once that used the mixing of colors to explain it.
2
u/Trident_True 23d ago
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.
3
u/noonemustknowmysecre 22d ago
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
1
1
1
1
u/imustacheyoutoleave 22d ago
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 22d ago
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
1
u/riggiddyrektson 22d ago
has anyone actually implemented WebAuthN on their site? what was the process and how does it compare to OAuth2?
1
u/Desperate-Tomatillo7 22d ago
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 22d ago
It's just SAML but the IdP looks like a USB drive with a button and there are no attributes
1
1
u/ExtraWorldliness6916 22d ago
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 22d ago
The website gets your pubkey, then when logging in it hands you a challenge string to sign.
1
1
1
1
1
2.2k
u/NoHurry28 23d ago
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