- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
- Big Tech has implemented passkeys in a way that locks users into their platforms rather than providing universal security
- Passkeys were developed to replace passwords for better account security, but their rollout by Apple and Google has limited their potential
- Proton Pass offers passkeys that are universal, easy to use, and available to everyone for improved online security and privacy.
From my understanding it’s the concept of trust. Basic passwords are complete trust that both ends are who they say they are, on a device that is trusted, and passing the password over the wire is sufficient and nobody else tries to violate that trust. Different types of techniques over time have been designed to reduce that level of trust and at a fundamental level, passkeys are zero trust. This means you don’t even trust your own device (except during the initial setup) and the passkey you use can only be used on that particular device, by a particular user, with a particular provider, for a particular service, on their particular hardware…etc. If at any point trust is broken, authentication fails.
Remember, this is ELI5, the whole thing is more complex. It’s all about trust. HOW this is done and what to do when it fails is way beyond EIL5. Again, this is from my own understanding, and the analogy of hardware passwords isn’t too far off.
so it’s basically what a SSH key is? can I not log in to an account from my laptop if I set it up on my phone then? that seems like a massive hassle if it’s the case
It basically performs the same function as an SSH key (providing public key authentication), yes.
Your issue with logging in on your phone vs laptop can be solved by either syncing them (like the OS/Browser platforms of Google/Apple/Microsoft or a password manager like Proton Pass/Bitwarden do) or by setting up each device separately (like most people should do with SSH keys). Each method comes with trade-offs: syncing means they aren’t device bound and can potentially be stolen, setting it up on each device can be a pain, etc.
The important thing to remember is that passkeys don’t need to be the only authentication methods attached to an account. You can use the convenience of a passkey most of the time when it’s possible and then fall back to another method (like a password/TOTP pair) when that’s not available (such as when setting up a new device). There’s also always the standard account recovery options if all else fails, those don’t necessarily go away.
The other thing to remember is that it’s not trying to be a perfectly secure solution to all authentication everywhere but to replace passwords with something better. Not having to generate and store random passwords with arbitrary complexity requirements, being able to log in with just a tap or a click, and not having anything that needs to be kept secret on the website’s side can be enough of an improvement over passwords to make the change worthwhile.
If a passkey isn’t device bound, what makes different/better than a complex password? Is it just the standardisation that you mention? Enforcing using passkeys becomes exactly the same as enforcing using complex passwords
One key benefit regarding hacking: the data that’s passed back and forth between the user’s browser/app and the website/service is a challenge and a response and is no longer sensitive like a password is and the authentication related data (the public key) that the website stores for a user’s account isn’t useful to an attacker.
One key benefit regarding phishing: passkeys/WebAuthn credentials incorporate the domain name into part of the authentication and it’s enforced by the browser. This means that using a passkey/security key on the wrong site won’t give an attacker anything useful unless they also somehow control the DNS and have a valid TLS certificate to impersonate the site with. This is unlike the situation with a phishing website where a user can be tricked by a fake but convincing looking website into giving over not just a password but a one time code provided through SMS or a TOTP.
One key benefit regarding usability: The user just has to choose which account to log into from their password manager instead of having it need to autofill correctly on the website (I still run into sites that don’t autofill right). They also don’t need to worry about any specific password complexity requirements or changing passwords in response to breaches or password expiration times.
this makes a lot of sense, thanks!
You setup passkeys for all your devices with biometric features. I know I have a Yubikey for my desktop, facial recognition on my phone, and a fingerprint reader on my laptop. So, I setup 3 passkeys using biometric (fingerprint or face). I also kept my password and 2FA for now because it’s all new. I wouldn’t recommend jumping in face first.
I only am using it on a few key sites and partly because I’m a web developer testing it all out. I wouldn’t advise it for the average user at the moment but it’ll mature and many password managers can store passkeys now. As it matures, I’m hopeful it becomes seamless like FaceID and fingerprint readers.
Close, but you are still trusting the device you own. If I were to compromise that device, I could capture that key and use it. Again, this is my limited understanding, but a zero trust solution works in such a way that the actual keys are not stored anywhere. During setup, new temporary keys are generated. A keypass binds to the temporary key for use of authentication. The temporary key can be revoked at any time for any reason, whether it’s due to a breach or routine policies. It can be as aggressive as it needs, and the implication is that if someone else (either you or an attacker) got issued a new temporary key then the other would not receive it. Using an incorrect temporary key would force an initialization again, using the actual keys that aren’t stored anywhere.
The initialization process should be done in a high trust environment, ideally in person with many forms of vetting. But obviously this doesn’t take place online, so there is the risk that your device is not trusted. This is why the process falls back on other established processes, like 2FA, biometrics, or using another trusted device. How this is done is up to the organization and not too important.
But don’t get too hooked on the nuances of passwords, keys, passkeys,etc. The entire purpose is to limit trust, so that if any part of the process is compromised, there is nothing of value to share.
Disclosure: Worked in military and this seems to be a consumer implementation of public/private key systems using vector set algorithms that generate session keys, but without the specialized hardware. It’s obviously different, but has a lot of parallels, the idea in this case is that the hardware binds to the private/public keys and generates temporary session keys to each unique device it communicates with, and all devices can talk with members of it’s own vector set. Capturing a session key is useless as it’s constantly being updated, and the actual keys are stored on a loading device (which is subsequently destroyed afterwards, ensuring the actual key doesn’t exist anywhere and is non recoverable, but that’s another thing altogether). My understanding of passkey systems is solely based on this observation, and I have not actually implemented such a solution myself.