“Difficult to recover from” was referencing setting all of your accounts back up. I should have also included “lost” and “broken” to make that more obvious. Many hardware (most? all?) passkeys do not allow for backup and restore.

But I do see an issue with stolen hardware passkeys being used for access too if they’re a primary factor. With the mitigations you mentioned hopefully holding up.

They will almost certainly lead to vendor lock in. Why do you think they won’t? Apple’s password manager is definitely an example of vendor lock in. Many others have a simple to use export feature to CSV or something that others can understand

Edit: it could be that you don’t know what the WebAuthn/FIDO2 specification says or we understand it differently? Do you know how the attestation mechanism works? That ties the key to a device or software authenticator (the software authenticator is likely going to tie it to the device somehow, possibly even via a TEE).

There is no full stop there… A password that is sufficiently long will never be cracked no matter the hashing algorithm in use. Passwords are easily transferrable and can be communicated to a third party in the event of an emergency. They also provide tunable security, where you can trade off security for convenience if you want.

Some (not all, I know) passkeys are tied to a device. Stolen device means stolen passkey, and it’s potentially very difficult to recover from that. Passkeys are also locked to a certain standard, passwords have no such restrictions.

Tbh I don’t understand the move for passkeys replacing passwords. They should become the second factor when a user wants additional security. They’re perfect for that niche.

Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I “escape” containers all the time in my job because of configuration issues, poorly considered bind mounts, or the “contained” service itself ends up being designed to manage some things outside of the container.

Might be valid to not consider it with the services you run, but that reasoning is very wrong.