Passkeys are. more similar to TOTP codes than passwords. Everything about passkeys is autogenerated. Browser negotiates with website to generate a key pair that will establish your identity on that site. Every time you “login” they exchange unique autogenerated keys to prove to each other who they are. That’s it. You never have to remember anything again and it’s impervious to many attacks that affect passwords and 2fa codes.
Where they fucked up is allowing big tech to call the shots so now instead of simply having passkeys in your browser you have to go to a higher authority to have them validated. And goes who that is — Google, Microsoft, Apple. So it’s basically gatekeep and you can’t touch them without depending on them.
How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
It’s like the initial authentication, where server and clientnexchange a symmetrical key with their asymmetrical keys. The difference is that in that exchange the server and the client meet for the first time whereas the point of pass keys is that once when you were already authenticated, you validated the device or whatever will hold the private key as a valid source, so then when the authentication code gets exchanged, both ends can verify that the other end is who they tell is, and both can verify the other end as valid, and thus that exchange authenticates you because you, in the past, while authenticated, trusted that device as valid.
Technically, yeah, it’s an asymmetrical key exchange. Iirc the server sends you a signed certificate and you need to unencrypt itnwithbtheir public key and sign it with your private key, so they can the getnit back and ensure that it was you who signed it, using your public key to check the validity of whatever was sent.
I don’t know enough to be 100% corrextbon the details, but the idea is that it’s an interaction between asymmetrical keys.
Soporta like how we use keysbto authenticate through github through SSL, but with an extra level of security where the server validates a key in a single endpoint, not wherever that private key would be held (like with SSL)
Passkeys are. more similar to TOTP codes than passwords. Everything about passkeys is autogenerated. Browser negotiates with website to generate a key pair that will establish your identity on that site. Every time you “login” they exchange unique autogenerated keys to prove to each other who they are. That’s it. You never have to remember anything again and it’s impervious to many attacks that affect passwords and 2fa codes.
Where they fucked up is allowing big tech to call the shots so now instead of simply having passkeys in your browser you have to go to a higher authority to have them validated. And goes who that is — Google, Microsoft, Apple. So it’s basically gatekeep and you can’t touch them without depending on them.
How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
It’s like the initial authentication, where server and clientnexchange a symmetrical key with their asymmetrical keys. The difference is that in that exchange the server and the client meet for the first time whereas the point of pass keys is that once when you were already authenticated, you validated the device or whatever will hold the private key as a valid source, so then when the authentication code gets exchanged, both ends can verify that the other end is who they tell is, and both can verify the other end as valid, and thus that exchange authenticates you because you, in the past, while authenticated, trusted that device as valid.
Technically, yeah, it’s an asymmetrical key exchange. Iirc the server sends you a signed certificate and you need to unencrypt itnwithbtheir public key and sign it with your private key, so they can the getnit back and ensure that it was you who signed it, using your public key to check the validity of whatever was sent.
I don’t know enough to be 100% corrextbon the details, but the idea is that it’s an interaction between asymmetrical keys.
Soporta like how we use keysbto authenticate through github through SSL, but with an extra level of security where the server validates a key in a single endpoint, not wherever that private key would be held (like with SSL)