I have deployed FIDO authenticators at a ~2000 employees organization as the second factor. It was great for a while - when early versions of macOS and iOS respected the “platform” claim and created non-exportable private keys backed by Secure Enclave. Windows was never a problem, keys were created in TPM. We mandated 2 FIDO credentials - typically the laptop and either a phone or Yubikey (or both). People were encouraged to use the later but as soon as the keys were not exportable, phones were acceptable.
Then, Chrome got an update and started hijacking the enrolment process from the operating system and created keys synced to Google Account. This resulted worse UX because authentication now required pulling the Android phone (for those unlucky ones who have it) and confirming the login there instead of doing it right on the computer, uninterrupted.
Then, Apple followed with cloud-only key pairs and then so did the password managers (including Bitwarden Enterprise we were using) and everything become a mess.
The only solution would be to use the key attestation and to only allow specific security keys. Both Chrome and Apple have config knobs to simplify enterprise attestation (a strong assurance, which FIDO authenticator has been used), but neither Windows nor macOS support key attestation for hardware-backed keys (and macOS ignores “platform” claim altogether).
If you are going to store passkeys in a password manager, the whole situation is no more secure than just using passwords.
Consider:
1. Password managers tie passwords to sites, so phishing-resistance is achieved.
2. Password managers allow long, complicated, individual password per web site, so compromise blast radius is 1.
I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance.
In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.
Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.
Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.
> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud).
From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.
Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.
> Not true. The original concept was always for them to be cloud synced.
It was not. The original U2F spec was created before that idea was around and it talked about hardware security keys as means to store the primary key pair.
I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.
On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there.
On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in.
Expanded: As long you as the user has the security key fob, you can login. You should have 2.
Or, you use `xargs -0` for null termination instead of white space termination. `find` conveniently supports `-print0` that will use null character as separator.
Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22 to the internet and allow public key authentication only (or, certificate based one, if you prefer fancy)? OpenSSH security track record seems to be better than that of Tailscale.
Rolex and Casio deal with simply when IERS introduces one.
Beats is a new time measurement system, not just a new clock. So if the world (IERS) would stops it, they would have to have new rules for dealing with leap “micro-days” or “mili-beats”.
And second is the fundamental SI constant, quite a bit of stuff is derived from it.
Enterprise PKI is not hard and has many uses besides issuing certificates to web servers. Any company of 1000+ users or endpoints should just set one up.
I did it multiple times, most recently using YubiHSM as root key store for offline enterprise root CA.
Or, just use IPv6 and host Internet services in a routable address. Then, use ACLs at web server / proxy / L7 lb level to allow acme-challenge unauthenticated but everything else authenticated.
It looks like a poorly thought-out marketing project. For example, how to deal with the Earth rotation irregularity and leap seconds? One beat is way too long to correct with, so the correction has to be in centibeats, fractions of beat, inconvenient. Why would this in CET and not in UTC? Aligning start of the day with the existing customs seems beneficial.
But the idea of the universal decimal time is a nice one. I wish we had something like that.
Dostoyevsky was originally published in magazines chapter by chapter, so he would end the December’s on a cliffhanger so that the readers re-subscribed