pass manager is needed and that is one of the key differences
it is good but also a challenge for some people, especially if the 3 bigs cannot sync because normal people without pass manager begin to use Apple, Google, Microsoft pass management... if they have all 3 devices, all of them...
what I do not understand, what the heck is the goal, one passkey per service and total sync or a domain (server) has to create and manage 4 passkeys for 4 operating system providers if user does not use a total syncing pass manager?
that is the problem since those who use pass managers are normally ok but those who dont, and wont register/trust/pay for one, begin to use A/G/M/L pass managers and 4 pass manager accounts must be secured?
and then you begin creating 4 passkeys for each website?
isnt public key a bad wording suggesting it should or can be public?
I would call it verification key and keep it secret on the server
only thing it need not to be hashed, it is already "hashed" meaning if it leaks it has 128 bit security or so
if I get it well, the private key can be guessed from the public key from huge alien resources so it is actualyl like an already computer intensive hashed 128 random password from a 2^128 domain?
I do not think the public key is to be posted on twitter or should not be guarded at all... it is just not the signing key and it is 128 bit strong away from it
It is 100% fine to have adversaries know your public key. Asymmetric key crypto is not the same as "already hashed private keys." You can happily use a 4096 bit RSA key if 112 bits of effective security isn't enough for you.
i compare password hashing on server with passkeys where you store the public key on the server... we are told to hash computer intensive preparing for the worst that the server is breached and an attacker has the stored hashed (salted, peppered) password... then with brute force if you hashed computer intensive and the password was not weak, it can be i dont know 60,80,120 bit strong?
well you can actually get the password from the hash but if everything ok, infeasible... i guess it is the same with getting the private key from the public key, it is possible but with ecdsa256 i read 128 bit strong or so
i dont want more security i just find it interesting that nobody says the hashes are not a secret... ok it is more problematic since weak passwords remain much weaker hashed or not
i would still say if possible keep your verification key to yourself... and if it leaks, no problem
i would call them secret key (private) and verification key (public)
but i dont know much about this and i guess by digital signatures they are really public? but hey may be even stronger
> I'm old. What's the difference between a pass word and a pass key ?
Password: You have to choose a good one using your brain or a password manager of your choice, and you have to remember it using your brain or a password manager of your choice.
Passkey: Your device generates it for you, whether or not it is sufficiently random, and long enough is not up to you. You don't even have to worry about it. Your device stores it for you. You don't have to remember it in your brain, you don't have a choice if you want to use a password manager or not. The passkey is stored in something which is functionally equivalent to a password manager.
> how exactly is "this button" authenticated ?
What are you asking? How is it authenticated between the server and the client? Or how is it authenticated that the person pressing the button is the right person on the client side?
you start a process by pressing the button and authenticate via having the device and using your os account biometrics/passcode
then your pass manager signs a challenge with the passkey proving that you come from a trusted device (you are logged in to your pass manager) where you are the os account owner