I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
This seems like a key failure point to me and why I've been a tad resistant[0]. If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.
There is a similar problem even in OTPs. I switched phones not too long ago and some OTPs didn't properly transfer. I actually lost some accounts due to this, luckily nothing critical (I checked critical things but it's easy to let other things slip). The problem is that registering a new OTP removes the old ones. In some cases I've used recovery codes and in others the codes failed. IDK if I used the wrong order or what, but I copy-paste them into bitwarden, and I expect this is typical behavior.
99% of the time everything works perfectly fine. But that 1% is a HUGE disruption. With keys, I would even be okay if I had to plug my main key into a dock to sync them. Not as good as a safe, but better than nothing. I feel like we're trying to design software safes like we design physical safes. But if you lose your combo to a physical safe you always have destructive means to get in. With digital, we seem to forget how common locksmiths are. Googling, numbers seem kinda low but I'm not in a big city and there are at least 4 that I pass by through my typical weekly driving. So it seems that this issue is prolific enough we need to better account for actual human behavior.
[0] Don't get me wrong, I love them but I'm not willing to not undermine them via OTP creds because I need some other way in.
Actually it is a feature. The whole point of the Yubikey is that you can't extract the key. Syncing keys would mean extracting them, which would defeat the purpose of the Yubikey.
Now I am not saying that it is a feature you want. That's why there are other kinds of passkeys. My point is that it is not a flaw in Yubikeys, it is by design.
There's a critical flaw in PGP actually. If you reply to any PGP encrypted email with "sorry, I couldn't decrypt" you'll, with high likelihood, get the cleartext version of the email soon after.
The joke is quite old and part of what I'm pointing to. Security doesn't work well if it isn't very usable. At least this is a bit better than secure communication, but it isn't as huge of a difference as it might appear.
The biggest boon in security has come due to making these tools easy to use. That's from decades of experience is realizing you can't get everyone to be technical.
> If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.
As I understand things, passkeys come in a few different varieties.
You can buy a yubikey if you want the credential tied to one specific physical device. Figure out your own backup strategy, such as spare yubikeys or printed recovery codes or whatever.
Or you can use apple/google/microsoft if you want your passkeys backed up to your cloud account. This means passkeys are basically the "Log In With Google" button, but with extra steps.
I feel sorry for you, but I've also experienced bugs in password managers that fail to sync plain old passwords.
I feel like if I must choose between a 99% reliable syncing solution, and a non-existent automatic syncing solution that requires manual syncing, I would still choose the latter for its mental simplicity.
My point is that we need to address and solve these issues. I agree with you, but if we dismiss them then they don't get solved. The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user. Currently they are hard to maintain for technical users!
I don't think solving the syncing problem is as important as giving users clear expectations. The best way to teach passkeys to regular users is to use analogy. Consider the house key: the physical key that unlocks the front door of your house. You can have two keys on separate keychains so that you carry one of them and treat the other as a backup. But if your key is accidentally lost and potentially in the possession of a bad actor, you will want to change the lock on your front door. And if you do that, it is entirely your responsibility to change the keys on your other keychain.
We do do security by obscurity with our house keys; I don't label my house keys with my home address, while I do label my saved passwords with both the URL and my username. /shrug
I disagree. I think this strategy has been tried for awhile. Decades of security training has improved things but I don't think enough. Email encryption didn't resource get mass adoption until it was a seamless integration like in gmail or icloud. Same with text and phone, via Signal, WhatsApp, and iMessage.
My point is that training doesn't seem to be effective to the general population. Frankly most people don't care. As we both probably know a big part is likely not knowing the importance
This strategy has not been tried. Decades of security training has focused on credentials and objects that only exist inside a computer. And because it only exists in a computer, it is too abstract and not tactile enough for regular users to form a mental model. Yubikey is the one chance where we tie digital security to physical security and give people a clear mental model. Earlier you said that
> The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user.
I agree. So get rid of needing to understand algorithms and simply require users to understand passkeys in relation to their house keys.
Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
> understand passkeys in relation to their house keys.
Except they aren't the same thing. For exactly the reasons I was discussing. How often are locksmiths helping people get into their houses? What about their cars? It's a lot more common that you think.
You didn't get my point. It's not the lack of security training, but the issue is that the security training focuses on intangible things like passwords, domain names, links, emails. Yubikey is the opportunity to break this model and focus on tangible and tactile things that exist in the physical world. A passkey synced using iCloud or Google account does not break that model and will continue to be less understandable for real users than Yubikeys.
There are plenty of cases where I know that people have misplaced Yubikeys. They might have a spare Yubikey. Or the equivalent to finding a locksmith is to log in with a non-passkey method. It's fine and in fact better if logging in without a passkey is considered an unusual fallback.
> A passkey synced using iCloud or Google account does not break that model
Yes, yes it does. Have you seen how hard it is to recover these accounts? There's not uncommon HN posts that do get these solved, but only then by high visibility. A method most people do not have available to them.
> Or the equivalent to finding a locksmith is to log in with a non-passkey method
Sure, it is just that the backup methods end up undermining the security key.
You can also simply register all your devices individually as a passkey and login with any one of them. Part of the point of the passkey standard was that you can simply have your laptop/phone/etc. act as a Fido2 backed security key in its own right. So if you have multiple devices it's pretty easy to set them all up as your passkeys.
Eg. My Microsoft desktop, my Google phone, my Apple laptop all have passkeys setup individually that allow login to my various accounts such as my Google account.
So they aren't at all synced. They are all from different vendors but they can all login since i set them all up as passkeys. It's easy to do this too. Setup one site for passkey login via phone, go to that site on your desktop and select "auth via phone passkey" and use the phone passkey and then once logged in on the desktop go to account setup and select "Create a passkey on this device". The end result is you have multiple hardware security keys, namely your phone, desktop and laptop.
The NxM problem is at least better than the other problem where a website or app requires at most one passkey. WeChat (which is basically required if you need to talk to business associates or friends in mainland China) simply does not support multiple passkeys.
For myself it's really only the Google/Apple/MS accounts i'm using with passkeys so far (and third party sign in/chrome password syncing for the smaller sites) so N is small right now.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
It seems like the obvious endgame is most people will use very strong auth between their devices and Google / Microsoft / Apple and then federate to everything else. All other workflows will become niche because it's not in monopoly interests to build features that make anything else convenient or manageable.
This is where the incentives push and is why we're unlikely to see usable or easy passkey sync.
I'm sort of ok with this (it will be a net security improvement) but it saddens me a little to see more of the web come under centralised control.
Most people won't fully understand the implications of this, which will be that the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
Plus lots of secondary effects relating to fed auth providers having increasing leverage over the web in general.
> the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
You are conflating the old model of "log in with Google" and the new model of Google syncing your passkeys in an E2E way. The latter is more resistant to law enforcement misuse (not 100%, see All Writs Act in the San Bernardino shooter case).
Yep, I agree good outcomes are possible and an e2e sync'd passkey should have better privacy properties than a federated login.
It's a nuanced discussion because in practice today, email provider is regarded as ultimate source of truth regarding identity, except for high security domains e.g. where money is involved (banks, crypto) and it's economically viable for recovery to be high touch.
So having access to a user's email is the first "golden key".
Second is OIDC / social logins.
Third would be passkeys / stored passwords / an unlocked device.
My guess about the future is that OIDC / social login will prove to scale and grow better than direct passkeys in most instances. It's a better, more fully developed model for thinking about and managing identity lifecycle, passkeys themselves are a low level primitive by comparison.
Users will understand it (social login) better, providers will support it better (partly because corporates don't have any way to centrally manage passkeys at scale, nor should they) and finally because of the fallback / recovery problem for sites using passkeys.
This scares me because I could get fully locked out if my house burns down or something. I like this property of a password manager. This seems to be in direct conflict with the design goals of passkeys.
Non-passkey based account access still works. As in i can go into my Google/Apple/MS account settings right now and in the security tab there's a ton of different options you can set.
Backup codes, sms phone recovery, alternate recovery email are all there in all of the above.
It's no different to forgetting your password/losing access to your password manager is it? As in i've literally at points lost access with passkeys (i only had 1 at the time) and the way i got back in was very straightforward and no different to losing access to a password manager. I got an email and typed my old password and i got back in and re-setup my passkeys.
If I lose access to my password manager, I'd be substantially boned. But I'm less worried about that. It would require me to forget my password, or 1password to get pwned, go bad, or lose data.
The way I assess risk, that's less likely to happen than I am to lose my passkeys.
If I'm using passkeys but can recover my account with SMS, then why am I using passkeys? That sounds like the weak link of security. I'd rather use passwords, where I can understand what the password consists of rather than passkeys if I'm not getting an increase in security.
Account recovery with the big providers that support passkeys is two factor from what i've experienced, eg. sms+email, email+old password or sms+recovery code etc. so definitely a step up from password login.
Many password managers these days support passkeys and can synchronize them in whatever way you use to also sync your passwords (i.e. a cloud backend, but also a self-hosted Syncthing shared folder etc.)
I can easily export and import my passwords from my password managers and do whatever I want with them. I enjoy having that lever over my subscription.
There are several subscription-free password managers available that support passkeys, e.g. Bitwarden (self-hosted), Strongbox (lifetime version available), or KeepassXC.
It's unfortunately not quite the same level of portability as passwords, as I don't think there's any standardized export/import format yet, but these options are significantly better than Apples's and Google's closed ecosystems.
I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem?
Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk).
You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN.
I have a https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
I don't understand why someone stealing my key and getting in is a big risk. They could steal my house key and get into to my house and do far greater damage: grab all physical documents and grab all computers where their full disk encryption key is in RAM.
Finding a dropped yubikey and immediately having access to someone’s google account is simply reasonably a bridge too far if that ever became commonplace. Someone decided not to allow that footgun to the public.
It’s no inconvenience though since the yubikey with a button to press and a yubikey with a biometric button to press work the same.
> Finding a dropped yubikey and immediately having access to someone’s google account
Is that how it works? A dropped house key essentially has a second factor (the address of the home), but if you have someones Yubikey that can be used for Google, is the Google Username stored in the Yubikey and accessible to the finder?
You should at least need the username but i still totally get the bar being set where it is.
Like you can argue a dropped house key is similar to a dropped yubikey but i'd still give some benefit to the dropped house key involving real world attempts on locks with appropriate social suspicion on that if seen vs a dropped yubikey allowing anonymous attempts.
Curious what the threat model for the cryptographic verification is. It looks like verify_signature_software[1] doesn't actually verify ed25519 signatures, but rather computes a truncated sha512 hash of the data and compares that with the supplied hash.
fn verify_signature_software(&self, data: &[u8], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
let mut h = [0u8; 64];
let data_hash = self.compute_sha512(data);
for i in 0..32 {
h[i] = data_hash[i];
}
self.verify_ed25519_reduced(h, signature)
}
This calls [1] which merely performs a byte equality check on the first 32 bytes of the hash:
fn verify_ed25519_reduced(&self, h: [u8; 64], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
// ...
let mut matches = true;
for i in 0..32 {
if signature[i] != h[i] {
matches = false;
break;
}
}
// ...
matches && key_valid
}
With this design, an adversary who knows data can simply calculate their own hash of the input data and supply it as a "signature", no?
It is difficult to comment on the verification approach when there are no secrets and only hash verification occurs. Do you have documentation on the approach and future plans? At best, this "signature verification" looks like placeholders for future verification.
Thank your question. The OS does have currently some limitations in the signature area, as this is one of those things that is still a work in progress due to trying to focus in many common threats first before expanding on the verification. It does perform hash comparisons, but then again, the proper ED25519 signature verification is still a work in progress.
The threat model is still evolving, but the core goal is to provide verifiable attestation of system operations with these key properties:
1. Non-repudiation of operations
2. Tamper-evidence for operation chains
3. Verifiable boot sequence attestation
You are absolutely right that the cryptographic aspects need significant hardening. I even have some key improvements planned for future versions:
1. Proper ED25519 signature implementation using the ring or ed25519-dalek crates
2. Secure key management for signing operation proofs
3. TPM integration for hardware-backed key storage and verification
4. Formal verification of the proof generation and verification logic
The core verification chain itself (in merkle_tree.rs and hash_chain.rs) provides tamper detection, but it does require significant hardening in the cryptographic area. Now being sincere, I really wanted to emphasize on the VKFS(verified kernel file system based on the Linux Ext2) implementation first as that was a very tough one to make.
Anyways, I really appreciate you diving into the code and highlighting this. ( * ´ ω ｀ * )
Maybe, but I wouldn't hold my breath. It's more about how much data needs to be fetched and how many calls have to be made to fetch it. With Maigt, it sometimes feel like a select-in-loop anti-pattern. I.e. Git only exposes information in certain slices from its database. It's hard to run free-form queries on it. Often, Magit wants to display something that cannot be phrased as a single query, so it needs to do multiple. These queries also cannot be made concurrently, or even if they could be, the concurrency overhead would've been too much.
So, using the library will remove the overhead of exec() and friends, and will definitely make the situation better, but the ultimate solution is either for Git to be more like SQL database, or for Magit to extract information directly from the Git database, rather than go through the API (but the choice of Emacs Lisp for this functionality would be highly questionable).
We're not, and they're still in the process of discussion. It seems a bit early to fork and witch-hunt [0]:
> So clarification here: you asked me about that, but I haven’t been able to respond to you due to my illnesses and I’m just getting back on my feet now. So it’s not that it hasn’t been well received, it’s that I’ve been physically unable to respond to you.
It's not a complete mitigation, but you can pause your video history which may decrease the amount of information Google retains over time from this sort of analytics. I haven't dug into the privacy policy and I'm not sure it mentions if this feature affects backend data collection, however.
There's actually a Slate article covering this topic[0]. First, consent was given for certain homes. However, the article also notes that under "exigent circumstances" warrantless searches are permitted:
> In exigent circumstances, or emergency situations, police can conduct warrantless searches to protect public safety. This exception to the Fourth Amendment’s probable cause requirement normally addresses situations of “hot pursuit,” in which an escaping suspect is tracked to a private home. But it might also apply to the events unfolding in Boston if further harm or injury might be supposed to occur in the time it takes to secure a warrant. A bomber believed to be armed and planning more violence would almost certainly meet such prerequisites.
I think you'll find "distributed decision-making" is no panacea. I joined a company recovering from a distributed governance model, and the big challenge was that nobody had enough decision-making authority for the firm to change quickly and respond to the evolving outside world. Bringing a whole room to consensus is a lot tougher than getting a few people to disagree-but-commit and move on with their day.
Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.
This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
For support matrices, see [1].
[0]: https://myaccount.google.com/security
[1]: https://passkeys.dev/device-support/