I get that this is a niche-y concern. :)
===
New answer to "Why can't I add my public SSH key to more than one account on GitHub?"
Andrew Naoum: Because when you push via SSH to "git@github.com", it needs to uniquely identify who you are given the SSH public-key.
If you had the same key associated with multiple accounts, it wouldn't know which user to login as.
===
Perhaps if GitHub changed the SSH user to be something like username-projectname@github.com, then SSH could authenticate you with a single key but preserve the other information needed to b narrow down to a project or organization.
Yes, and to make it worse, they used user agent sniffing instead of feature detection even though it work fine in Firefox. Firefox enabled U2F because many sites which do implement U2F, do not implement WebAuthn yet. Luckily, it appears Github is now on the right track.
This is one of my pet peeves – and which is why the User Agent strings are so asinine (Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A5370a Safari/604.1).
Whitelisting features based on Browser type, version, device type, OS type or version, or any version for that matter is almost always wrong. Like 99% of the time – if you think your case is special, you are most likely wrong too.
Basically it boils down to: "why do I care that this software is running this specific version?" If you are not writing a deployment script and some such and the answer is "because it implements feature X, or displays Y behavior", well, check that.
I've also seen iPhone apps trying to figure out which device it was, to display assets. If you care about screen resolution, that's what you need to check. Your device table will become obsolete.
Features may be backported(like in this case), bugs may be fixed, new weird hardware combinations may be released. Your application is not guaranteed to be in sync when that happens.
Nowadays it is far less necessary, but there are still browser-specific stuff involved.
My bank and my retirement accounts do this too. It's infuriating. I switched to Firefox recently due to failures in Chrome Sync and now I get this as a reward. Wonderful.
EDIT: Unfortunately, it looks like the WebAuthn credential is only used as the second factor, so you can't use it to replace your password yet, let alone your username.
WebAuthn doesn't use biometric data, the authenticator does. You can just as easily use a PIN or whatever you want.
> Also, single encryption key is risky (in the way as using the same password across all websites) as it could be hacked or leaked
The difference is that one compromised site can't leak your encryption key, someone would have to physically get it from your computer or steal your security key (and, probably, need to guess the PIN in three tries).
If someone "steals" your fingerprint or your PIN, they still have to seize your key fob/phone/laptop.
The biometric data or PIN does not leave the authenticator (although the browser/OS may be responsible for capturing the PIN for a key fob with limited input capabilities).
The devices also have security and biometric testing/certification, so users who are concerned about the data being hacked or leaked from that device in your possession can look for a certain certification level.
Yes, it is unlikely that a pure biometric as the sole factor with remote verification would ever be secure enough to be a single, lifetime authentication method. It would require a zero knowledge challenge/response against some biological process, with no false positive/negatives (even in cases of family members/twins with similar features/DNA). There's also legal reasons I'd want to stop being identified as that person (witness protection program being the one that jumps to mind).
It's far more likely we would go from wearables to implanted hardware, which would still be a two factor authenticator.
How does this work? Is an OTP generated on phone with Google Authenticator like app and that OTP needs to be punched into the login form?
Windows Hello is also starting to support this for desktop PCs.
When you are using WebAuthn as a second factor with a hardware key, you are typically using non-resident keys. These are keys that aren't being stored by the authenticator, only by the relying party (in this case GitHub). A "handle" is given at registration, which must be re-supplied at authentication. This is actually how the U2F keys work - the handle has the only copy of the exported, encrypted keys or key material, so the authenticator can't understand a request for authentication without getting that handle.
So, in this case even though it is the same physical hardware authenticator, you have done two registrations, which have generated two separate generated key pair, each with a key handle. Those key handles are saved to different accounts. When I use the authenticator as a second factor, only key handles associated with that account are used for the authentication challenge.
There are wrinkles here because of the diverse ecosystem, of course.
Some software implementations (like Windows Hello) have no premium on storage, so they will still store second factor keys. These still need to behave as above, but Windows will technically know it has been used multiple times on the same site.
Also, when using Web Authentication for primary authentication, you use what is called a resident key. In this case, the key is saved in memory along with metadata on which site it was generated for. The challenge doesn't include handles, but is effectively asking "do you have anything perhaps for GitHub.com?".
In this case, some authenticators simply won't support multiple accounts. Others will, and the browser or operating system will take responsibility for selecting which key is shared, via native UI.
Seems like a cool thing to sponsor, too - as long as it's tied to accounts to prevent underhanded measures.
https://arstechnica.com/store/product/subscriptions/
This may not be the "deal" you were looking for. But if you were considering a subscription anyways you could already be a winner.
https://www.crowdsupply.com/solokeys/somu
Of course if you only need WebAuthn then solo keys are a great option.
Example: If an archaic backup MX mail server with private RSA key P is allowing SSLv3 "for backwards compatibility" then bad guys can use that to impersonate an otherwise unrelated TLS 1.3 web server that shares private RSA key P.
If your GitHub account is really that important as to use your fingerprint each time you access it, sure it is nice GitHub can support that.
But if you do not really mind and are happy with a password, that maybe unlike your finger, you can share with someone in other side of world if you really like to, then why not use a password. I would expect GitHub should not prevent that.
It is sad to see a trend to really "make sure it is you" started by Facebook and Google taking over in all mainstream online services and it is even worse, to have people believe it is the only good for them.
