WebAuthn. So, registration and authentization. I'm not exactly sure if which standard deals with changing PIN, but it worked everywhere I tried it out of the box.
>OMG did you say CHROME??!!!
Yes, how dare I... It was an example. I don't use Chrome either, but not many people do use other stuff, so that's why I mentioned Chrome specifically.
Currently, the support is best in Chrome and some other Chromium-based browsers. I personally tried Brave, which worked flawlessly everywhere. Firefox (which I personally use) works with standard WebAuthn, but some big players (Google) seem to have older implementations predating the standard, so it doesn't work with some clients (Firefox) yet. I've watched a conference some time ago where they said they're working on itβ’.
If you want to know how exactly it stuff works, Mozilla has a nice and easy to comprehend description on their developer site. It's one search away (in your preffered search engine).
>The generating of new keys that still will take an hour?
Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience.
> Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience.
I'm not talking about the CPU time needed to generate the bits...
Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature. I'm guesstimating that at 1 hour of the user clicking through various interfaces.
But anyway, my concern is passkeys are adding too many dependencies on devices/providers. Giving me a list of possible devices/providers does not address my concern.
The keys are authenticator device specific. So if you put it on your keychain you never need to generate anything to check your email on random computers. If you use a software solution, then you need to sync the vault in some way, and again don't need to generate anything here.
If you're worried about making a brand new passkey because you're logging in from scratch, that means you need some other kind of authentication to start the process. And that's solidly outside the scope of passkeys, so it's hard to say how difficult it would be. (But if you have an alternate login method, a good system wouldn't force you to make a temporary passkey, it would just let you check your email and log out.) (Also it shouldn't take more than a minute to do key creation/deletion in any reasonable implementation.)
>Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature
Yes, the keys are device specific. This is a feature and the reason why it's more secure. If it could be backed up (exfiltrated), it would not protect you in case your device is compromised, which is one of the design goals. You could probably work around this by using an emulated key (which is what Apple does I think?), but that would obviously eliminate this key security feature.
> I'm guesstimating that at 1 hour of the user clicking through various interfaces.
I see, sorry, I missunderstood.
Again, it's just like changing a password or a TOTP secret. Unfortunatelly, no standard can fix bad UX design, but I sympathize. Silver lining is that even cheaper hardware keys are built like a tank, and software is... well... software.
> my concern is passkeys are adding too many dependencies on devices/providers.
Which is reasonable. The question is, is the dependency worth the security benefit? It seems many major device makers/service providers think so.
> Giving me a list of possible devices/providers does not address my concern.
Well, I can't do anything about that, can I? Nor can anyone else.
I think this is, again, a question of priority.
TLS is now essentially a dependency for using the web at large, but it wasn't in the 90s. I'm sure that is of concearn to some people, but most agree it's a net benefit.
WebAuthn. So, registration and authentization. I'm not exactly sure if which standard deals with changing PIN, but it worked everywhere I tried it out of the box.
>OMG did you say CHROME??!!!
Yes, how dare I... It was an example. I don't use Chrome either, but not many people do use other stuff, so that's why I mentioned Chrome specifically.
Currently, the support is best in Chrome and some other Chromium-based browsers. I personally tried Brave, which worked flawlessly everywhere. Firefox (which I personally use) works with standard WebAuthn, but some big players (Google) seem to have older implementations predating the standard, so it doesn't work with some clients (Firefox) yet. I've watched a conference some time ago where they said they're working on itβ’.
If you want to know how exactly it stuff works, Mozilla has a nice and easy to comprehend description on their developer site. It's one search away (in your preffered search engine).
>The generating of new keys that still will take an hour?
Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience.
Please just read the Mozilla website.