Discord Rolled Out Yubikeys for All Employees
discord.com
discord.com
It's ironic, as users have been requesting that feature for years, and discord has been pushing back the whole time.
https://support.discord.com/hc/en-us/community/posts/3600313...
Instead, they did the infamous qr code, the new font, the new id that's often similar to the old one but without the #, and the like.
The overly popular support page isn't even cited or mentioned in the article !
I can't understand the disconnect between the teams at discord and the users.
For me, the teams are doing this blog post like they had the idea first because they're the best (when they have actually pushed back for so long).
And not even acknowledging users is just disrespectful. It shows that Discord only involves them in the payment process, and ignore their suggestions whether they're good or bad (because they come from the users).
At the same time, for any change, they post they're visionaries. And I'm sure their CVs go on about how they disrupted their workplace. (while they really did push back on this feature)
Also, I'm not sure what's given you the impression that there has been any push-back on the feature?
(the top story is even funnier, as Discord didn't even reply to it, but comments were closed because there were too many.)
When the board about yubikey was the most active, Discord maybe somehow replied to it by doing the opposite. Instead of increasing their security as users asked, they decided they would fancy lowering it and introduced QR codes, because services are no fun if they don't experience of wave of hacks.
And now, they're not referring to anything from the past, but are cluelessly posting generic talk and external links on a blog post.
Also, as throwaway1777 mentioned, hardware tokens for staff is definitely something that had to be done before the second half of the last decade. It's the standard in any company I work with nowadays.
So, IMO, OP's blog post doesn't show how Discord is being innovative, it's just a statement of "sorry, we're catching up on security" and "was this a topic before ?"
Thanks for the reply, anyway.
As for the QR code login, I built that feature. Although it does offer a venue for social engineering, we've done a lot since launch to ensure people understand that they're logging into a new device using it. From day 1, it's always included red text that said roughly "you're logging into a new device using this" and to "not scan codes that random people have sent you." Of course, some people don't really read. That being said, millions of users every week use the QR code login legitimately, and it's a feature that most other chat platforms offer. It's also very very beneficial when you're using a shared device (i.e. you live in South Korea and visit PC bangs often.)
As well, you'd be surprised, webauthn adoption within companies is not nearly as ubiquitous as you'd think. Shipping out yubikeys around the world during a pandemic was a gargantuan task. Either way, any post advocating for more broad adoption of webauthn and also showing success does the industry as a whole good.
Might as well not use a YubiKey at all. This just eliminates the benefits a YubiKey would provide. This reminds me of the banks that offer TOTP with fallback to SMS - just turns the "security improvement" into a waste of time and effort.
> We chose [Yubikey C NFC] for a few reasons: [...] 3. It doesn’t support OTP mode, so there’s no “Yubispam” to deal with
I think it does support OTP mode? Using one of these right now and it definitely supports OTP. You can turn it off, but that's not particular to the C NFC.
An aside: YubiKeys are great, I love them... but they need to have a display to show what, precisely, you're authenticating with, or signing, etc. You can never trust your computer's display - Ledger/Trezor's hardware wallets have the right idea. IMO current standards fall short in not providing this information to the hardware authenticator.
At this point the YubiKeys only provide some measure of convenience. It's disingenuous for the blogpost to paint this as some meaningful security improvement if Okta Verify is the fallback. Feels like such a waste of time and effort to build something worthwhile and then undermine it just like that.
You need to have a reliable and secure backup if you want to deploy yubikeys - or limit accounts that have been recovered until they’re revert fixed.
I don't use any methods other than YubiKey when I do have my keys. So attackers cannot trick me. If I see a choice without Yubikeys I immediately know I'm being phished.
Source: My company started providing these to employees and I was also initially confused by Yubico selling two different products with almost the same name.
I’m not entirely sure what the support for this is like on Windows or some Linux systems, but for example on MacOS, if an application authenticates with SSO or something in an embedded browser window(one example would be like Cisco AnyConnect, but there are plenty of others. zScaler did recently update their MacOS client to authenticate inside a real full browser though so that’s nice), most every application I’ve come across uses the stripped down version of WebKit in these that doesn’t support FIDO2 or security keys at all, so I’m forced to use some other option like an authenticator app.
This is perhaps less of a problem depending on what types of auth your IDP supports, but for example with Microsoft it’s either Phone Call or SMS, their Authenticator app, or FIDO2.
I’ve been rocking FIDO2 with a Yubikey on macOS and iOS and it’s been solid. Support is there in web views. You can even use Yubikey-based PIV certificates now.
Not all of Microsoft’s apps have migrated to support this at the same pace. And anything still using ADAL over MSAL on iOS is going to probably ask for a different authentication path. Some of the older PowerShell modules don’t support FIDO2 or certificate authentication at all, but those are being rapidly deprecated.
Not really. TOTP is mostly there to protect against password leakage, be it through shoulder peeking or digital means.
The SMS fallback still protects against all of these. A shoulder peeker can't read your texts if your phone is on default security, as message contents are not displayed on a lock screen without some form of unlock.
The digital attacker will need to remotely clone your SIM or do a SS7 attack, both which are out of the realm for 99.9% of attackers. And if you are truly at risk for this, you are important enough for the bank to have setup additional measures.
You will now probably bring up auth attacks via fake websites, but a TOTP doesn't protect against these. Only passkeys and physical keys do, and by far most banks don't yet support either :)
Unless someone has stolen your bank card and knows your PIN, in which case you have bigger problems.
The value of the Yubi is that you need it physically, which can't be accomplished via phishing and other remote attacks.
Physical theft is much, much rarer, and if a laptop with Yubi in it is stolen the thief won't have your user/pass (unless it's on a sticky in your bag, etc). It's a very, very targeted attack if they phish your creds, then come steal your laptop, and you need more advanced protections than a yubi.
It's generally preferable to use a `-sk` key type, though, by which the remote server can essentially enforce that you're using a smartcard and not a normal keypair backed by a file.
I've already ssh'd to my work machine. I want to send an HTTP request to my company's internal web API from that machine, but we only use webauthn credentials. I'm going to use curl to send the request to the web API. With basic username/password auth or totp it's easy for me to write a script that prompts me for my password/totp code and marshals in into the expected format. How do I do this with my FIDO2 private key in a way that doesn't completely undermine the whole process?
Maybe there's something here?
I mean, we already have this problem with stuff like OAuth2. Usually, at some point in the process, you will need to enter your credentials in some JS-capable browser.
Host my-trusted-powerful-remote-machine.whatever.com
ForwardAgent yes
So yes, working with what I'd call a "thin client setup" is something where Yubikeys are probably not a good fit, unless the protocol for that setup would support some kind of direct USB forward that actually works with Yubikeys...
All requests would then route via the work-computer.
But honestly? Use the work computer, and if it isn't good enough ask for a better machine and let somebody else take care of it.
We deployed Yubikeys to every employee (5 Nanos), which went into a USB port on their MBPs and were told never to remove them. We rolled out Okta as well (similarly moving from GSuite).
Definitely took some training initially, but after that employees are used to Okta + a Yubikey touch to authenticate to all the systems we used.
Internal SSH as well used certs deployed onto the Yubis, to ensure SSH was physically backed.
With hardware devices all remote managed through MDM, and enforcing access policies, and full disk encryption, along with the Yubis, you can end up with an incredible amount of protection again phishing and other remote attacks. Even lost hardware is protected, and can be remote wiped.
After building all that infra, now I wish I had more Yubi support at home. So few serious services (eg. banking) that I care about support it. I can lock my Github with 2FA supporting Yubi keys,but not my bank, broker, mortgage, etc.
It’s been my understanding that for corporate use, only a single one should be issued because:
1: There’s an establish support team in your org that can always issue a new one (except for a few edge cases, super critical things) 2: You can’t trust users with 2 devices
For private use, nr. 1 would not be true so the recommendation rightly is to issue 2.
If you're their number two, possibly you hold theirs.
You keep both your keys, one securely and one at-the-ready.
Yes, safety deposit boxes. Yes, family, yes friends. Yes, attorneys.
But also what I said initially.
https://krebsonsecurity.com/2018/07/google-security-keys-neu...
I’ve supported users who would eBay the second one, if they were smart enough to do that.
> Nowadays, newly-onboarded Discord corporate users receive a laptop and at least one Yubikey alongside that laptop. IT onboards users to Okta and instructs them to register at least two WebAuthn authenticators; typically, this is their Macbook’s TouchID/Windows Hello sensor and also their Security Key C NFC.
> We also instruct corporate users to set up Okta Verify for use only as a fallback MFA in the event that all their authenticators fail at once. This way, we never have user accounts lacking at least one strong form of multi-factor authentication.
So OS level keys, a yubikey for roaming, and Okta Verify for fallback
When we deployed we banned Verify (didn't want any OTP), but encouraged TouchID, and the Yubi. If someone was locked out we could temporarily enable Verify, or reset their Macbook or Okta access so they could reregister into either.
But,in deploying 1500 or so yubikeys over a 5+ year period we never saw one actually break. Employees would often say they'd broken, but troubleshooting normally was user error.
The worst we saw were a few cases where Yubis needed unplugging and replugging (sometimes being left out for an hour or so).
I’ve got one of the original ones (15 years old?) the must have been through the wash a dozen times and it still works.
9 years later I'm still procrastinating and after reading these comments I'm convinced I'm good for another couple years LOL
I did have a nano though, it broke on me, but it was my company's key. I don't think the same holds for those ones.
https://www.zdnet.com/article/yubico-to-replace-vulnerable-y...
If a Yubikey gets lost: on all our internal systems, an administrator will remove that Yubikey from the user's account and a new Yubikey is deployed. For a remote employee, we can usually switch to OTP until the new key arrives. For external systems, it is the responsibility of the employees to securely store their recovery keys. If these are gone, well then it depends on the service how tedious it will be to reset the 2FA for that account... it usually (and hopefully) involves some kind of manual identity verification process.
Some people in critical positions simply get two Yubikeys.
That really seems like the way to go for everyone, because of course when you lose access to the yubikey, it's suddenly far more challenging to get support via systems you may no longer be able to access. Google insists on two hardware MFA tokens for their elevated account protection program, most likely for this reason.
It's possible to break, but it's not trivial.
Also you just keep a bucket of non signed up ones at the office. Enrolling them is pretty easy.
Did you even read the article?
Given how long certain core functionality in Discord has been completely broken on Linux, I find this a little hard to believe.
[1] https://github.com/RPM-Outpost/discord
P.S. I run a repo that provides Discord, ArmCord, th-ch/youtube-music, and appimagelauncher for Fedora: https://askiiart.net/repos/fedora/x86_64/askiiart.repo
Well, it provides whatever I feel like adding. I'm a pretty bad maintainer, but Discord is always up-to-date, at least.
>Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
Edit: I literally wrote it, laughed and then forgot to delete it bc I knew it would be read incorrectly.
You don't need to spend millions of dollars tethering your organization to a security identity provider to accomplish no more than what you already are doing without them. WebAuthn is not curing cancer. It's just another marketing scheme for authentication.
As I recall, they had some internal support people that had access to some extraordinary privileges given their role at Okta.
I understood through the grapevine that could potentially negotiate it so their support teams didn’t have any kind of standing access or non-US-based access over your Okta deployment, but only if you paid enough money.
1. There are pretty damned good reasons to use a single sign on (SSO) authentication across all company resources. Managing multiple accounts for every employee across every service is a prohibitively burdensome and messy affair, error-prone, inconsistent in policy enforcement and quality of security, features that would difficult to roll out on your own, the list goes on. SSO is an absolute must in any modern organization.
2. WebAuthn just a marketing scheme? It's a pretty big jump forward in authentication security, protocol, user experience, etc. It eliminates passwords, the cornerstone of authentication for as long as computers have even had authentication, and the #1 cause for security breaches by far. It does away with the need for 2FA. It allows users to use a range of devices to easily authenticate themselves without the need to juggle credentials for every account they have. It uses public/private key cryptography, a robust standard for security for years, uniquely for each site, attested to prevent fake hosts from registering keys, and all automatically managed behind the scenes so nobody has to go through the painful song and dance of creating and managing their own keys anymore. And it does all of this with a universal and open protocol that is currently already baked into most browsers. Seems like a pretty big deal to me, and certainly a big enough deal for huge companies and services like Google, Github, Microsoft, etc. to have prioritized its development and rollout.