It looks like you have to configure an application key -- is that right? Did you just hard-code yours? That might be a possible technical hurdle, since other OTP auth doesn't require configuration so we don't have anywhere convenient to store it. Or I might just be misunderstanding how the verification works.

Broadly, I don't think this is out of the question, but I'd like to see more interest before we bring it upstream. At the least, we'd need to order some keys ourselves so we can test/maintain it.

Subjectively, I feel like the MFA barriers stay out of my way pretty well with mobile app auth -- it's not super convenient to dig up the code, but not too bad, and I need it so rarely that it doesn't feel particularly cumbersome. I haven't seen much griping about this from elsewhere that I can recall either, except a little bit around the install barrier hurdles for nontechnical users, but Yubikey is probably at least as complex for nontechnical users as an OTP app.

The way forward for ease-of-use seems most likely to be SMS, although I'm growing increasingly distrustful of SMS for MFA give that, e.g., iMessage seems to unpredictably send my text messages to my laptop nowadays and I've seen several accounts of social engineering to take over/forward phone numbers.

I suppose ease-of-use might be less bad with Yubikey in a physical organization, since you could just hand them out during the Standard Indoctrination Seminars and walk users through how to use them, maybe.

You do need an API key to talk with their servers - but you can get an API key for free with your Yubikey that allows use of their service as you need. So, the administrator just needs to have a registered Yubikey on their service and request an API token, then configure Phabricator to use it (the extension also adds configuration options into /config to do this properly.) Users don't need to configure anything; they just need a registered key (which it comes with out of the box).

Also, for completeness on my implementation, an OTP key generated by the Yubikey always begins with a 12-character string that uniquely identifies the key (the 'UUID'). When you first add the factor, it verifies the OTP code against their API, then stores the 12-character string as the factor secret. Upon request for authorization, you check both the UUID from the OTP token submitted vs the users, and also query the Yubico server to ensure the OTP code is actually valid, which is all you have to do. This is called self-provisioning of Yubikeys, vs associating the user with the UUID at registration time. This makes it act more like self-provisioning of TOTP for users: they get the Yubikey in the mail, plug it in, enable factor automatically.

There is some user setup for a Yubikey if you want to use it for multiple things (like dual Yubico/TOTP/FIDO U2F mode), but this doesn't change that. Also, it's worth mentioning that the Yubicloud approach in my extension means I can also use that same Yubikey (that I just got out of the mail with zero configuration) with any other Yubicloud enabled service - they simply incorporate the UUID of my key into their database and query the remote server for validity. So for some common cases where people integrate, you may not need anything else.

I'll also note that my perspective is probably somewhat skewed, because I sometimes often jump into high security mode because I use things like Passphrase a lot to manage credentials - so cutting down the time from "take out phone and fiddle with application" to "touch my USB port" is a nice win for me. (For mobile apps, I actually prefer Duo Security since it takes it from "fiddling" to "push notification I confirm from lock screen".)

Like I said, if this isn't clear, I'm fine with leaving it out now - I can submit a patch, and/or add a link to an external extension to the community page for everyone. It's pretty easy to use and very low-impact, so I think it should 'age' fine (for reference, my Yubikey is 3 years old and I just rekeyed it, submitted the keys, and wrote the extension in an hour or so). People who need it can just nab it.

I think something like this isn't something people are going to clamor and flock for, but for a personal/private organization, I think I'd give the $20 plastic stick approach is a pretty good consideration because it can be pretty hands off.

I'd also like to voice my support for this. We have Yubikeys here for MFA and I do use Passphrase quite a lot as well. Right now I've set up the Yubikey to be a Mobile TOTP-provider instead so I can just get a standard Mobile TOTP code to input via a keyboard command. This is rather specific to OSX/Linux and Android, though as it requires an Android phone with an NFC reader to read the shared secret up to give you the TOTP codes if you do not have a computer handy and the keyboard shortcut has a high technical skill level requirement because it means you must be able to grab terminal output and put it on your clip board. The native app does not make it much better than a Mobile TOTP, hence the implementation I've deviced for myself.

Actually supporting either Yubico's native OTP and/or the U2F protocol within Phabricator would definitely make MFA easier to adopt for the rest of the organisation. :)

The source code for my extension is available here: https://github.com/thoughtpolice/libphutil-yubikey

It's also worth noting that newer yubi keys have a u2f support that doesn't require third party server integration. Which may be more palatable?

I've an old generation one. The first three generations weren't U2F.

One compromise could be to offer HOTP, so it's compatible AND YubiKey AND other similar devices.

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

In T8787#177689, @siepkes wrote:

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

I don't know about upstream, or other projects, but: I have absolutely zero interest in running some entirely different, hugely complicated piece of software so that my 2FA works, and I probably wouldn't bother with it even if it was documented, honestly (as an aside, the first thing you linked, GLUU, didn't even let me download without signing up -- as it's proprietary, so it's already a non-starter -- and the remaining two when I clicked 'install documentation', I was dumped into multi-hundred page PDFs. Needless to say this doesn't exactly help my concerns of adding lots of complexity I have to maintain.)

If I was working in a company of like hundreds of people it might be worth it, but then I wouldn't even need a guide (because someone else would have done it already, surely), and even if I did implement custom code for Phabricator, I would be able to justify the means to support it. In other words, "Set up KeyCloak" is something I imagine like 95% of installs are never going to do, want to do, or desire it enough to justify any documentation. The 5% of people who decide they do need it can likely handle it. The current, basic MFA tools Phab has are widely appropriate for the vast majority of installs who want to increase user security and auditability at low cost, IMO.

Basically: between running entirely new application servers of hundreds of thousands of lines of software so I can click "Log in with token" and writing 30 lines of PHP to integrate me with an already extremely popular solution, in the way Phabricator already supports natively, that the wide majority of installs will likely be able to take advantage of - the choice is very obvious as far as I'm considered.

Phabricator also does not support OpenID and we specifically declined to support it in T524#35252.

Sorry, meant OAuth support instead of OpenID. The gist of it was delegate authentication to a dedicated system. Be it via OpenID, OAuth, SAML, etc.

For U2F in PHP I can see an implementation by YubiKey which is about 450 lines. Say another 30 lines for integration that makes about 480 lines of additional security sensitive code to incorporate in Phabricator. You will also have to add code for people to manage tokens associated with their account (just like with SSH keys). Just saying you should be careful with bloat in your security core.

Just dropping this here since it's the first hit for "SAML" and makes it easier for me to contextualize things when I quote $50K for it, which I'm starting to think is too low:

http://www.economyofmechanism.com/github-saml.html

Also:

GHE requires 14GB of RAM to even boot
unicorn restart took quite some time with 4GB of RAM

wut

More on SAML:

https://arstechnica.com/security/2017/06/onelogin-data-breach-compromised-decrypted/

@epriestley Onelogin does way more then just SAML. They also do OAuth for example. The screenshot also says to regenerate your Oauth keys. I assume your going to remove all OAuth stuff from Phabricator now?

@siepkes, what are you hoping to get out of making that comment? How do you believe it benefits you?

@epriestley I'm hoping you'll see you shouldn't pass judgement that fast.

Why did you think that a sarcastic, condescending comment was the best way to convince me to reserve judgement?

When other people make snide comments to you, how do you feel? Does it make you want to help them?

@epriestley I can see how that last sentence could be perceived as such. I probably should have put a smiley there since it wasn't intended as harsh as you (seem to) perceive it.

Having said that; If you call out a technology (in snap judgement) you should be able to deal with some criticism on that statement. I have a hard time imagining it is okay to associate a technology with a negative event without basis. Let me ask you how you would feel if someone did the same with Phabricator?

Why do you believe I haven't performed a serious technical evaluation of SAML?

@epriestley I'm not saying you didn't do a serious technical evaluation of SAML. I can't see where I might have even vaguely implied that? For all I know you could be an expert on SAML. I've done multiple SAML implementations and frankly I can't blame you for not wanting to do / maintain one.

All I'm saying is the link you provided and implying SAML is bad because of that breach is baseless. OneLogin is an identity federation provider which supports multiple protocols like SAML, OAuth, Radius, etc. The breach wasn't caused (as far as anyone can tell at this moment) by SAML. People just need to reset their SAML key pairs because they have been compromised in the breach. Just like their OAuth secrets, their Radius secrets, etc. have all been breached and need to be reset.

Personally I do think SAML could be of some (enterprise) value to Phabricator and give it an adoption edge in the enterprise over for example GitLab. Altough OpenID connect could perhaps be used to the same effect since it also has (i believe) some support for single logout. I'm planning to implement one of the two at some point for our internal users and I'm more then happy to share and maintain it if Phabricator is interested in it.

In practice, every paying customer who has ever asked us about SAML has wanted to use OneLogin as a SAML provider. OneLogin's breach does not imply SAML is bad; it implies OneLogin is bad. For paying customers who are interested in understanding our stance on SAML support, criticism of OneLogin is materially relevant because they all want to use OneLogin.

i'd like to remark that this ticket is supposed to be about perhaps u2f or other direct hardware security, not saml, and thus i've had to unsubscribe from the recent back and forth :)

I'd love to see support for U2F keys, as well.

Here's a nice reference impl:
https://github.com/google/u2f-ref-code

Safari:

This browser doesn’t support the FIDO U2F standard yet.

Firefox:

This browser doesn’t support the FIDO U2F standard yet.

So this is one of those "standards" that Google made and only Google supports. I see.

Firefox has a secret about:config for this.

I can install a plugin some guy on GitHub made to get Safari support. Nothing says "secure" to me like some guy on GitHub.

It looks like the Safari Developer Preview Experimental Extra Edgey Beta supports WebAuthn.

Maybe if I leave this alone for three and a half more years browsers will actually support it.

Also the way my USB hub orients the slots makes it super inconvenient to press the contact button.

And I probably should have researched this more carefully before ordering the hardware because I didn't get the NFC one, so if I put a key on my account I can no longer get in from my phone? It looks like you can generate OTP but apparently no one knows how to do this or implements it, and the keys are 44 characters long? I can't wait to type cccjgjgkhcbbirdrfdnlnghhfgrtnnlgedjlftrbdeut on my phone.

"After waiting 15 minutes for the new credential to be updated in the validation service, I make the long-touch gesture of 3 or 4 seconds to activate slot 2."

This is really the state of the art in MFA? Really?

And, of course, mobile Safari doesn't support U2F anyway.

Google's own U2F support appears to require that you enroll two separate keys.

Yubikey does not sell a USB-C + NFC key, so even if I'm okay with using only Chrome, I have to bring a USB hub with me if I take my laptop anywhere.

So this looks like it can only really serve as a convenient alternative to TOTP today (almost 4 years after the request was filed!), not a realistic replacement: you'd just use U2F on your desktop to avoid having to type stuff in, and fall back to TOTP on your phone. And you have to shell out like $90 for two Yubikey 5 + NFC keys and have a USB-C-to-USB-A hub.

Or I guess get one key for each device and just leave them plugged in all the time and then anyone stealing either one gets a hardware factor which doesn't need to be unlocked to work. I can't figure out if you can lock a Yubikey or not, but it isn't required by default even if you can, so I'd guess literally no one does. Great, everything is worse now.

(But even if you do this, good luck enrolling both keys! HA HA HA HA)

See also https://news.ycombinator.com/item?id=16501400, although this isn't terribly damning.

Overall, I'm not especially impressed here and a bit uneasy about upstreaming this given the current state of U2F support. I'd hoped U2F represented an upgrade from TOTP, but it looks more like a step sideways today: greater convenience, but many users will realistically need TOTP as a fallback for situations where they don't have the right combination of NFC, USB-A, USB-C, ports, keys, and browsers, so U2F effectively just increases the attack surface.

I'll look at Duo before figuring out where we're going here. It does look like everyone is generally headed in the direction of sane U2F support, just at a glacially slow pace, and probably via WebAuthn rather than window.u2f. But this currently feels like something we look at again in a couple years when there's broader support for it and everyone's hardware and devices all have standard Universal Magic Nearly Blue Field Bus-D ports or surfaces or antennas or whatever. ubeam's real non-physics-violating technology should be everywhere by then!

The original request focused on OTP, not U2F, but I think the amount of configuration required by OTP and the lack (?) of a pathway on mobile make it a better candidate for third-party integration than first-party integration. If we were supporting OTP in the upstream I'd want to run a first-party verification service so we aren't dependent on Yubikey's service, but the whole thing seems very messy and very bound to the Yubikey stack. It also looks (?) like Yubikey OTP and Yubikey U2F aren't linked to the same key (I think?) so you can't use U2F on one device and then fall back to OTP on mobile, even if you want to type in 44 characters? You have to enroll OTP and U2F separately.

When it actually works, the U2F flow is pretty good and I'd be excited about it if browser and hardware support were in slightly better shape. But it currently looks like something to look forward to, not something that's really ready for general use today.

Agreed that supporting YubiKey OTP is pointless - it's impractical and basically a dead legacy feature at this point. WebAuthn has emerged as the de-facto standard for hardware tokens.

WebAuthn is a lot more secure than any other form of 2FA, since it involves a key exchange between the relying party and the authentication device. This eliminates the credential phishing risk, which still exists with things like TOTP or push-button-to-approve solutions like Duo. It does not require any third party validation servers.

The compatibility situation looks great nowadays:

• The mobile pathway is solved - there's a wide range of bluetooth- and NFC-capable tokens, with support in iOS and Android. I use it all the time and it's seamless. Some Android phones can be used as a token via Bluetooth. There are USB-C and Lightning tokens which you can physically plug into a phone.

• Browser support has improved, with all major browsers supporting WebAuthn, including Edge and Safari: https://caniuse.com/#search=webauthn

• There's about a dozen independent U2F vendors, not just Yubico.

Common choices are YubiKey 5Ci (Lightning + USB-C), YubiKey 5 NFC, or Feitan MultiPass FIDO.

Google recommends the latter plus a cheap YubiKey U2F for their advanced protection program, which targets non-technical users.