
GitHub Supports Web Authentication (WebAuthn) for Security Keys - johns
https://github.blog/2019-08-21-github-supports-webauthn-for-security-keys/
======
sebazzz
> 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.

~~~
outworlder
> 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.

~~~
solarkraft
Why is something like feature checking not used for software dependencies like
libraries as well?

~~~
zaphirplane
Gun configure tried
[https://en.m.wikipedia.org/wiki/GNU_Build_System](https://en.m.wikipedia.org/wiki/GNU_Build_System)

------
StavrosK
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.

~~~
CrendKing
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.

~~~
StavrosK
> 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).

~~~
dane-pgp
> WebAuthn doesn't use biometric data, the authenticator does. You can just as
> easily use a PIN or whatever you want.

Except the standard permits sites to only trust authenticators with specific
features, or rather from a specific whitelist of manufacturers/models:

[https://www.imperialviolet.org/2019/01/01/zkattestation.html](https://www.imperialviolet.org/2019/01/01/zkattestation.html)

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.

~~~
dwaite
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.

~~~
tialaramex
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.

------
tptacek
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.

I get that this is a niche-y concern. :)

~~~
chrismorgan
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:…?

~~~
CameronNemo
Yeah something tells me this is a deep change related to how they manage
identity. GitLab has the same issue.

~~~
DangitBobby
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.

~~~
andrewshadura
They were a great platform, but they aren't any longer.

~~~
DangitBobby
Go on...

------
munchbunny
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?

~~~
bamboozled
Be careful doing this, I’ve had friends who lost their accounts and it was a
pretty big loss for them.

~~~
michaelmior
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.

~~~
Klathmon
I personally hope they dont.

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.

------
user6789675
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.

------
joshca
> 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?

~~~
TheChaplain
Also would like to know how this works for multiple accounts...

~~~
dwaite
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.

------
kmfrk
I've been waiting a million years for another branded sale on YubiKeys like
the last time GitHub did one. Those things are so expensive.

Seems like a cool thing to sponsor, too - as long as it's tied to accounts to
prevent underhanded measures.

~~~
ericseppanen
A Solo key is $20.

[https://solokeys.com/](https://solokeys.com/)

~~~
CameronNemo
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.

[https://www.crowdsupply.com/solokeys/somu](https://www.crowdsupply.com/solokeys/somu)

Of course if you only need WebAuthn then solo keys are a great option.

------
u801e
I wonder if Github has ever considered allowing a 2FA via the use of the
private ssh key that's used for running git push or git fetch/pull?

~~~
tialaramex
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.

------
patrickmcnamara
Great. This means I can log in on my phone again.

------
SEJeff
And multiple security keys at that! This is excellent.

~~~
taeric
The fact that twitter is restricted to a single key is mind boggling to me. Is
that a common restriction elsewhere?

~~~
SEJeff
Yes, there are precious few places that support sensible hw MFA _and_ allow
multiple of them to be registered. It is quite maddening actually.

