Except in this case it’s really important to learn how the implementation works because it has meaningful differences:
If you login to Google.com with a password, the remote server knows your password and if you are phished the attacker can use your password to access Google.
If you login to Google.com using a passkey secured by Windows Hello, your PIN or biometric check is between you and your computer, and the passkey is used for a public key exchange with Google’s servers. They do not know your PIN and you cannot be phished. That’s a transformative change.
A bicycle and a semi-truck are both machines with rubber tires to move people and things a faster speed than walking. The rest is implementation details.
X and Y are both Z. The rest is implementation details. Except sometimes "implementation details" makes the two pretty radically different in usage.
Incorrect. The PIN does not grant access to the service.
If all you have is the PIN, you don't get access to the service. Therefore, its not the PIN that grants the access.
If you know my keepass database passphrase, but don't have the actual database file, do you have access to the services contained within?
And as acdha mentioned, the entire login workflow is radically different with security keys / passkeys. Its a radically different implementation of authentication with different guarantees.
Do you leave SSH open on port 22 with only password authentication? It's just the same as using SSH keys, just a difference in implementation.
> If all you have is the PIN, you don't get access to the service.
That depends what the service is. If the "service" is a session on my desktop PC, then it absolutely does grant access. You'll have to take my word that if I type my PIN into it, it will start an interactive session.
My kid wants to play minecraft, but he can't because he doesn't have the PIN. If he did have the PIN, he could play minecraft.
I am willing to believe that the implementation of the PIN is totally different from passwords, but in this use case, the user experience is identical. The "attacker" does NOT need the password.
It is still not the PIN in the same way the password to the password vault isn't the password to an account. If you had a physical TPM that got removed, your pin wouldn't do anything. If the TPM got reset in the BIOS, the PIN wouldn't work. It's a step in the authentication workflow, but the PIN itself is not the credential. If a person tried to RDP to that computer with the PIN, they wouldn't be able to access it.
If your kid fails the PIN too many times, the PIN gets disabled. No more PIN retries until the real password gets used. If they tried the password a bunch of times, they'd get a timeout but could come back in a few minutes and try again.
If you login to Google.com with a password, the remote server knows your password and if you are phished the attacker can use your password to access Google.
If you login to Google.com using a passkey secured by Windows Hello, your PIN or biometric check is between you and your computer, and the passkey is used for a public key exchange with Google’s servers. They do not know your PIN and you cannot be phished. That’s a transformative change.