Discord Rolled Out Yubikeys for All Employees(discord.com)
discord.com
Discord Rolled Out Yubikeys for All Employees
https://discord.com/blog/how-discord-rolled-out-yubikeys-for-all-employees
90 comments
Yubikey support is coming soon to users and is being internally tested on staff right now.
Also, I'm not sure what's given you the impression that there has been any push-back on the feature?
Also, I'm not sure what's given you the impression that there has been any push-back on the feature?
the aforementioned feedback, that had close to 250 upvotes and stayed active for 3-4 years, actually never got a reply from Discord. It's in the 90 most upvoted stories, and in the 50 most commented stories of all times under Account & Server Management. And overall, only 15 of the 120 most upvoted stories on this board got a reply from Discord (including the 8 that were completed).
(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.
(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.
Not replying to something isn't pushing back. Chances are this one feedback post item got lost in the sea of them. If it's any consolation I'll reply to this feedback post saying it's planned and in progress.
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.
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.
we are getting a lot of problem when we use mnesia and same thing happened with you in the past. just tell me when are you going to open source your replicated ets?
> 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.
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.
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.
You’re mixing up two different models. You’re thinking of the
$55 Yubico YubiKey 5C NFC https://www.yubico.com/product/yubikey-5-series/yubikey-5c-n...
What they chose is the $29 Security Key C NFC by Yubico https://www.yubico.com/us/product/security-key-c-nfc-by-yubi... (note the word YubiKey does not exist in this model name) which does not have that feature.
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.
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.
One problem I have with switching exclusively to Yubikeys(or similar) entirely with no other 2FA option, is the lack of support in embedded browsers.
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’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.
This has improved leaps and bounds over the past year and a half.
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.
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.
You can just turn off the OTP configuration. Alas IIRC they ship with it 'on' out of the box so you get the 'cccjgjgkhcbbirdrfdnlnghhfgrtnnlgedjlftrbdeut' nonsense (with a newline for real fun win chat) whenever you brush against your laptop while reaching for a coffee.
> 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.
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 :)
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 :)
TOTP is also vulnerable to good phishing attackes. You can convince someone to enter their creds and OTP code, which can be used remotely.
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.
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.
Call the phone operator: "I need a new simcard, I recently moved, can you send me one ?
- yes yes no problems."
Considering you have to PIN €0.01 at the door, and the bank account has to match the bank account attached to the provider account, another virtually impossible attack :)
Unless someone has stolen your bank card and knows your PIN, in which case you have bigger problems.
Unless someone has stolen your bank card and knows your PIN, in which case you have bigger problems.
If there is a recovery mechanism that isn’t horribly annoying and secure, the yubikey is worthless.
If your recovery mechanism completely bypasses the benefits of using the YubiKey, that recovery mechanism is what your attackers will use.
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.
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.
> If your recovery mechanism completely bypasses the benefits of using the YubiKey, that recovery mechanism is what your attackers will use.
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.
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.
We’re talking about what happens if you lose your keys. If all I need to do is call and say “this is netheril96” and they’ll give me access, the yubikey is theatre.
They want to have the ease of use AND the benefits - which can’t really happen.
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.
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.
How do you authenticate from a machine that isn't local to you? I don't do any work on my work-issued laptop, I use a powerful remote machine instead.
Newer openssh clients and servers can use FIDO2-augmented private keys (these are the key types like ed25519-sk). Basically you have a normal keypair stored on the client device, plus the server requires a passing a FIDO2 challenge against the yubikey.
Maybe I'm just missing something, let me explain:
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?
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?
I'm not sure you can. If it is possible, it probably requires some open-source tools and a pretty painful process to get the credentials off a hardware token (if that's even possible) and go through the various API calls.
Maybe there's something here?
https://github.com/herrjemand/awesome-webauthn
https://github.com/Yubico/yubikey-manager
Maybe there's something here?
https://github.com/herrjemand/awesome-webauthn
https://github.com/Yubico/yubikey-manager
No, you cannot do a Webauthn authentication with curl. You would need to redirect to a Javascript-capable browser to do the authentication, and then use whatever the service returns as a token with curl (cookie, JWT, ...).
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.
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.
The usual process is for your script to do an OAuth flow on an embedded web server with Okta or whatever, and to port forward that embedded server to your client machine. VS code remote handles this pretty well for example.
This is a bit batty and not sure it would work but I wonder if you could expose /dev/hidraw using sshfs then your work machine would see it as a local yubikey.
In your ssh config:
Host my-trusted-powerful-remote-machine.whatever.com
ForwardAgent yes
Doesn't this only solve the problem for resources I am accessing over SSH? What about if I wanted to access something over HTTP like my web browser does?
That is correct. If you actually use a browser remotely, you would need to use something like RDP with the WebAuthn Virtual Channel enabled, which unfortunately I think is currently only available by Microsoft. Some remote control software like Teamviewer has USB passthrough, but I've no idea if that works with Yubikeys (I doubt it).
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...
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...
Install a HTTPS? proxy on the work-machine, and configure the other host to use that?
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.
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.
But seriously what do you do for that case if the resource requires password authentication via an OIDC redirect or whatever?
If the remote host is trusted, you just forward the gpg-agent over ssh to your remote host.
Sorry, I think I missed something because the article doesn't mention GPG at all. How can you make a webauthn client defer to gpg-agent?
When GPG is your ssh agent, you can use RSA or ed25519 keys stored on a smartcard (like a Yubikey) to authenticate via SSH.
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.
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.
Sure, I understand how to authenticate to my remote machine with a smartcard (and already do use this setup). I'm wondering how to authenticate to resources (over HTTP) from my remote machine while using webauthn.
Just -D 8080 on your SSH connection and use the local SOCKS5 proxy to tunnel all local web traffic via remote machine.
[deleted]
Did exactly this at my previous employer as part of a large plan to become effectively unphishable. With all auth requiring something physical, and no OTP anywhere.
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.
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.
Ok… Thought they would’ve already done this by now.
What happens if a Yubikey breaks?
From the article:
> 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
> 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
In addition, Okta Admins can also recover accounts, so loss of the Yubi doesn't mean the account is locked out forever. You can easily provision a different 2FA method.
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).
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).
Lots of good answers, but the ultimate point is that you can lose work time, and that is an accepted part of the trade off. If I lose my Yubikey(s) my employer will pay me to wait until a replacement arrives because the security is worth that cost.
So first of all: From my experience, Yubikeys are incredibly durable. I have one on a keychain for years now, completely beaten up and it's still working fine.
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.
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.
>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.
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.
I agree, but for some reason the people responsible for the IT budget did not like that solution... (Yes, they are really not that expensive, but somehow it is pretty common that companies like to cheap out on the small stuff).
I've destroyed two yubikeys in a 2017 MBP that would occasionally send excess voltage out of USB (I guess it was a bugged first-generation USB-C chipset), and one from leaving in on my keyring in my pocket in the laundry.
It's possible to break, but it's not trivial.
It's possible to break, but it's not trivial.
Wow I thought I was the only one - fried a Yubikey and a Logitech webcam because I forgot I plugged it into the “cursed” port. Took a bit to convince IT to req me a new laptop.
You use out of band non yubi key mfa and contact your support and they give you a new one. Been using them for a while it’s really not too much of a challenge.
Also you just keep a bucket of non signed up ones at the office. Enrolling them is pretty easy.
Also you just keep a bucket of non signed up ones at the office. Enrolling them is pretty easy.
Same thing that happens if you forget your company login password.
You always issue 2
Do you though?
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.
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.
Google was one of the earliest adopters of Yubikeys, and they used them for EVERYTHING. When I worked there, we always received 2 keys: one of those itty bitty ones that sits in your USB port permanently, and a regular key that fit into our security badge holder, or you could keep at home, or whatever. The switch to security keys reduced account takeovers to 0:
https://krebsonsecurity.com/2018/07/google-security-keys-neu...
https://krebsonsecurity.com/2018/07/google-security-keys-neu...
I have four. One attached to the desktop, one attached to the laptop, and two carried with all my mechanical keys (one of them supports NFC and another supports USB-C).
glutton ;-p
And if you somehow get locked out you can show up at the help desk in person, or VC in with your manager on the call to Id you
But is an engineers time not worth more than an additional key users can do self service with? Seems like a really thin argument given how cheap the keys can be.
At Google the IT desk had a jar of Yubikey. You could just take and enroll however many you wanted.
Your manager holds your backup.
If you're their number two, possibly you hold theirs.
If you're their number two, possibly you hold theirs.
I've never heard of this practice and would throw the book at anyone who implemented it in a shop I worked at.
You keep both your keys, one securely and one at-the-ready.
You keep both your keys, one securely and one at-the-ready.
This is fair, but I have to note, a little out of date for startups which can be 100% remote to the point of founders not having a home city, let alone one stable, secure place to stash a backup.
Yes, safety deposit boxes. Yes, family, yes friends. Yes, attorneys.
But also what I said initially.
Yes, safety deposit boxes. Yes, family, yes friends. Yes, attorneys.
But also what I said initially.
How often do yubikeys break?
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.
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.
On the veeeery bottom of my to-do list has been to get a 2nd yubikey in case mine breaks....
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.
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.
Take care. Github and Yubico revoked some yubikeys in 2019.
https://www.zdnet.com/article/yubico-to-replace-vulnerable-y...
https://www.zdnet.com/article/yubico-to-replace-vulnerable-y...
Same. These things are indestructible. LOSING a key, however, is totally in the cards.
Why not just use Touch-ID? I’m sure all of their employees use Macs anyways.
> Here at Discord, we’ve got a healthy blend of MacOS, Windows, and Linux devices. Some users are on portable laptops; some are permanently docked. Some are even on desktops!
Did you even read the article?
Did you even read the article?
> Here at Discord, we’ve got a healthy blend of ... Linux devices.
Given how long certain core functionality in Discord has been completely broken on Linux, I find this a little hard to believe.
Given how long certain core functionality in Discord has been completely broken on Linux, I find this a little hard to believe.
FWIW, with a Discord install from a .rpm made with RPM Outpost's discord rpm maker[1], Discord works perfectly for me on Fedora. The only issues I've had is when I used the flatpak. Though I do suppose Discord should take some flak for only providing .deb files.
[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.
[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.
FYI
>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".
https://news.ycombinator.com/newsguidelines.html
>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".
https://news.ycombinator.com/newsguidelines.html
Apologies, I have edited my previous comment.
Sorry that was supposed to be sarcasm.
Edit: I literally wrote it, laughed and then forgot to delete it bc I knew it would be read incorrectly.
Edit: I literally wrote it, laughed and then forgot to delete it bc I knew it would be read incorrectly.
A number of MacBook users leave their laptops shut and plugged into external monitors a large fraction of the time, making the sensor awkward to get to.
Employees with MacBooks do primarily use touch id. They get a Yubikey for redundancy.
/sarcasm
> Step 1: get everyone and every app* (it’s never every app) into Okta
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.
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.
Uh, what?
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.
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.
Okta seems super-dubious anyway. Didn’t it come out that they store passwords in plaintext and have internal superusers with access to multiple customers internal systems?
Unaffiliated with Okta.
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.
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.
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)