> GitHub supported physical security keys using the experimental U2F API for Chrome
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.
> they used user agent sniffing instead of feature detection even though it work fine in Firefox
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.
They're all from an era where javascript couldn't do everything. Those various crud of "like Gecko" were to get servers to deploy HTML that fit the pattern of another browser. There were websites that gave you error pages if you weren't Internet Explorer.
Nowadays it is far less necessary, but there are still browser-specific stuff involved.
>> Yes, and to make it worse, they used user agent sniffing instead of feature detection even though it work fine in Firefox.
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.
Just tried this with my Yubikey Nano and Vanguard Investments, after changing my u2f to "true" in about:config. Does not work at all. Vanguard shows the Yubikey login prompt but it doesn't activate the Yubikey, and pushing the key just spits out a OTP and dumps it to the browser search bar. Oh well.
This is fantastic. I look forward to finally having much easier authentication on the web. Imagine browsers syncing between devices a single encryption key that will authenticate you to all sites, which you can easily back up to a piece of paper.
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.
As discussed before, biometric data (used by WebAuthn) will never be used as the single factor for authentication, due to the fact that you can't revoke your face or fingerprint once that data is hacked or leaked. Also, single encryption key is risky (in the way as using the same password across all websites) as it could be hacked or leaked. Username/Password would still stay as the primary authentication method at least for near future IMO.
> biometric data (used by WebAuthn) will never be used as the single factor for authentication
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).
Of course, not every site will make use of this DRM-like anti-feature, but I can well imagine that a lot of sites/industries will adopt policies that treat non-biometric authenticators as insecure.
There is typically a significant UX impact on identifying the authenticator, some of which is effectively baked into the spec.
This is partially because it serves as a fingerprinting vector for authenticating users, and limits functionality (such as reusing the authenticator to access multiple accounts on the same site). This UX penalty will most likely dissuade people from limiting authenticators in cases where they aren't trying to meet AAL3 or rough equivalent.
Once you have an authenticator attestation, you can tie it to metadata on features, certification, and security incidents.
However, I actually don't suspect that real-world policy will rely on such dynamic metadata. Instead, organizations will limit the allowed authenticators to a static set of models, most likely models they issue to users.
So you'll see things such as banks allowing large money transfers only when you use the bank-issued authenticator, or having government contractors only able to authenticate into systems using the key fob they were issued.
I agree with you that we likely won't see this feature used much in the real world. I always tell Firefox to deny knowing which device model I have if asked. None of your damn business.
For personal accounts at least my experience was that a very large transfer (hundreds of thousands of dollars in a single transaction) required talking to two random employees. The first was a random call center worker who answered my call & the second was randomly chosen by the bank to run the whole process with me again to confirm. The web UI was clear that I would not be able to perform my transaction without talking to a human. Using two at random defuses the risk of internal collusion to defraud a customer. But I did use my good bank, maybe a mediocre bank would accept something a bit less stringent.
WebAuthn typically uses two factors when you are relying on the authenticator for primary authentication. One is possession of the authenticator, the other is biometric or a PIN.
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.
In a somewhat related vein: it would be really fantastic if Github allowed the same SSH key (in my case: a Yubikey-resident SSH key) on multiple accounts; we use separate accounts for different clients, and Github's refusal to allow an SSH key to be used on multiple accounts means I can't use Yubikey SSH keys for those.
Back in 2011 I posted a similar question to Quora. I've since deleted my Quora account, but here's the email notification I got about an answer:
===
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.
That would require the ability to specify the username somehow, would it not, e.g. using tptacek@github.com:… and example@github.com:… instead of git@github.com:…?
Bitbucket allows you to use your SSH key on as many projects as you like, IIRC. I actually really like Bitbucket as a platform, I wish more people would use it.
I guess they need that property so that they can associate a push to a specific account instead of just an ssh key that can be associated to multiple accounts.
GitHub recommends using a single account, according to their website[0]... I get that it could be seen as a security concern, but I don't know if it's crazy. I only accept a physical key as 2FA, and you can revoke SSH keys from your account if your development machine is ever stolen or missing.
Ok so what advantage does that give you? The idea of PKI is that your identification is tied to your machine. Why are you unnecessarily conflating authorization with authentication?
In the thread from the Yubico announcement earlier this week, someone brought up the question about why you can't disable SMS for recovery codes (SMS recovery codes, not SMS 2nd factor), since that undermines the security benefit of having your 2nd factor moved entirely to FIDO or OTP. Are there plans to fix that?
To clarify: you can disable SMS MFA on Github (or never set it up in the first place). Doing so does require setting up TOTP, though you’re able to validate the initial code and then delete your copy of the secret key.
Sorry, I maybe wasn't clear enough. You can disable SMS MFA (I did), but it didn't sound like you could disable SMS recovery codes, which is the other section further down in the UI for configuring your login setup.
Make sure to print out some backup codes. Also I have two Yubikeys authorized for each of my U2F/Webauthn accounts. Fortunately managing multiple hardware keys is much easier with U2F/Webauthn than with TOTP... at least with Google/AWS/Github, you can add a new key at any time, while with TOTP I had to generate a new TOTP secret and update both keys at the same time.
Yeah, that seems like the best bet - either hardware key or TOTP (because, although hardware keys are better for security, not all users will have one - cf. myself), and then store your backup codes in a password manager.
I would assume that GitHub support would be willing to provide some out of band authentication to allow someone to recover an account if all other options had been exhausted.
Time and time again it's been shown that one of the weakest links for account security is customer support. It's pretty trivial to gather enough information to impersonate someone well enough for most support reps to believe it's actually you.
It's also part of the reason why SMS is so insecure, because legally most phone companies can't not allow you to transfer your number, and the ways they can verify you are you is limited.
If they do allow support account recovery, I hope they allow the ability to disable it for those who don't want the extra attack vectors.
I think security when it comes to third-party products is relative to personal value one sees into that product and to personal use case.
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.
> But there’s more—GitHub’s move toward WebAuthn makes it possible to use your laptop or phone as a security key without carrying a separate physical key.
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?
Web Authentication is basically generating and proving ownership of a private key. You have some hardware/software that manages these keys - it will generate a key at registration time, and then prove ownership as part of authentication. The keys are tied to a web domain and the domain is also included on the challenge/response, which breaks active phishing attempts.
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.
I noticed ArsTechnica is providing a free Yubikey with subscription to their "Pro++" yearly subscription ($50/year). This also provides a 20% discount on additional dongles.
Note that the feature set on this is limited. Specifically it is missing GPG (and thus SSH) support. It may be added via a software update if the somu campaign goes very well. But frankly that is a long shot.
Figuring out what sets of unrelated operations it's safe to do with the same private key is a problem. Definitely don't do this without a cryptographer examining all the operations done and telling you it's safe. Generally if asked they'll tell you to just make a new key instead because that's definitely fine.
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.
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.