4 ms·
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is
by geertj 2y ago
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?
- triblemaster 2y agoA physical device which is not your computer stores some secret information which can authenticate you. This can be passwords, passkeys, GPG keys, your retina etc. The physical device can be password protected. So you have two step authentication: 1. your physical device 2. your password to that device Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob. To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
- vbezhenar 2y agoSafari on macOS uses passkeys without phone. So unless you consider security chip inside macbook a separate device, that's not true, that's just one of modes.
- triblemaster 2y agoSecurity chip inside macbook is a separate device for authentication purposes if it needs to be unlocked and cannot be bypassed by the OS.
- fauigerzigerk 2y agoWhat I find rather confusing is what happens on each device. There appear to be multiple places where passkeys can get stored (iCloud Keychain, Google account, Chrome profile, Bitwarden, ...?) and depending on where it's stored it may or may not get synced to various other devices, browsers and apps. So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently. It's like misplacing my keys has been taken to a whole new level of abstraction :-)
- postalrat 2y agoMany places let you enter and name multiple passkeys. So you as your keychain one and name it "keychain". And also add phone and call it "whatever phone" then use either. Personally I only use devices that don't sync and can't be copied for security reasons.
- marssaxman 2y agoThere's something here I am not following. First you say: > Stealing is not enough because you still need the password. But then: > You don't need to remember stuff anymore, because you can just use your physical keys. How are these statements both true?
- geertj 2y agoThanks! A bit late to the party, but if you still see this, I presume the authentication exchange between the web server and the device is some kind of challenge response? And if so, does the challenge/response depend on the type of credential that's in the device?
- Huppie 2y agoBack when I implemented webauthn for the first time I remember the interactive tutorial webauthn.me provided by Auth0 was very helpful in wrapping my head around the process.
- kriops 2y agoMost important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
- dboreham 2y agoNot true.
- pseudo0 2y agoThe signed assertion includes the clientDataJSON, which contains the origin of the relying party. Assuming the server properly validates that assertion, it should prevent the use of a phished assertion by a third party. https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...