Anyone that uses Github day to day at work and for side projects should have already enabled it.
When I think of what the "most important" account is to me, my Github page is pretty damn close to the top. Mine is currently 2FA with an automated script that will scan my Github and back everything up to GitLab (at least the "important" projects), which is also 2FA'd.
Insane setup to protect data in one account but if I loose access it would be beyond a bad day for me.
I don’t think that’s an insane setup at all. Losing access to GitHub would be bad for a lot of folks on HN I suspect. My GitHub has 2FA with Yubikeys and I am planning to do something similar to yours with backing up to a personal Gitea instance… once I get around to it.
Nit pick, but I wanted to point out that backing up your cloud data (github) to another cloud (gitlab) is increasing (approximately doubling) your attack surface. Good for data retention though.
I just use different accounts for work and private stuff.
For me 2FA is super annoying because I run my browsers in private mode and I restart them multiple times a day, so I have to sign in quite often. It effectively makes it much harder for me to keep my privacy.
Not to mention loosing the freedom to log in to my accounts from everywhere without needing my devices. Things do get stolen/lost/destroyed and that is a more realistic threat for me than getting my password stolen.
And support can help out as long as you can show that you can ssh into a github host using the private key of one of the public ssh keys assigned to your account.
What people should do is have a small SD card with all of their private keys and passwords stored away safely. This SD card should be kept in cold storage (e.g. in a safe where you keep personal belongings), and never be accessed unless in absolute emergency (lost your YubiKey etc and can't get in anywhere, etc.)
Do most people have a "safe where they keep their personal belongings"?
i guess it would presumably be on-premises, because you're going to have to take it out to add recovery codes to it every time you add a new TOTP or whatever (or create a new private key or password) right? If it was, say, a safety deposit box at a bank, odds are it's not gonna wind up with most of your stuff. Even on-premises, the task of making sure "cold storage" stays sync'd with my evolving passwords, private keys, TOTP recovery codes, etc, seems like something I'm unlikely to keep up with.
You can have multiple second factors. I have 2 YubiKeys (one on me, one in a safe place) and then I have the standard TOTP codes on my phone using Authy.
If I manage to lose my phone, live and backup yubikeys then I have recovery codes.
It's going to have to be something pretty drastic to cause me to loose all of that.
Well, I've lost control of accounts and I suspect a few of us have. Fortunately the one I lost wasn't important.
But my response wasn't to turn off 2FA. It was the reverse - to turn on all forms of authentication made available, for all acccouts. If I lost control of it one way, I had another.
By the by, if you read the spec, FIDO expects you to do this in preparation for the day you lose your token. So no you are not the only one - people think about it all the time.
No, we're here with you. I'm also wondering if being responsible for storing and using passwords is THAT BIG OF A DEAL???
Even mathematically, probabilities of two failing points are adding.
I've been locked away from mail, banks and gods know what else just because I didn't have my phone or computer nearby, was in different country, in a place without network coverage, haven't paid for cell in time, etc. etc. etc. and absolutely positive that 2FA (at least that requiring on-line presence) is evil.
The ONLY THING that can really protect and help you - is good HUMAN tech support. Where you can call, explain yourself, prove ownership and regain access to a service. Up to the point of having to go to of video-call office yourself and beyond. Yeah, I'm completely aware that some corporations don't even have humans (hello, Goolag!) employed - and trying to stay clear from them.
I feel like with the recent hackings done by Lapsus, it shows that 2FA can actually make it easier to break into a system. Since they first break into telecom companies, they can then sim swap and reset peoples passwords.
I don't really understand how it can be easier to break into a system if you need the username, the password and an SMS code, than if you just need an username and a password.
Obviously, SMS two-factor authentication is flawed. But one-time codes and WebAuthn are pretty good two-factor authentication methods to secure important credentials.
Using phone numbers as a second factor should be in line with using MD5 for password hashing. It doesn't mean that MFA (or hashing) are a bad idea, just that you need to deploy it properly for it to make a difference.
You’re talking about a completely different thing, SMS for password reset. That’s completely distinct from SMS as a second factor for logging in, which is absolutely fine for almost all people’s threat models, even in places where SIM or telco attacks are feasible, since the SIM alone is insufficient to log in as you.
Sure, it’s common for sites to use your phone number both for 2FA and account recovery (whether single- or multi-factor—and single-factor account recovery is obviously a serious problem in a two-factor authentication environment), but the problem you’re complaining about is nothing to do with 2FA.
They still need your password. The SMS alone is insufficient. Supporting SMS as a second factor (whether primary or backup) is perfectly adequate for almost everyone’s threat model, and generally far superior to not supporting it as regards avoiding account lockout. (That’s Fastmail’s position, which I thoroughly agree with.)
> 2fa is a scam in part to force them to give up more data and in part to try to force people to use a government tracking device. Just remember this is Microsoft behind this.
How is 2FA a scam ?
Nowhere in the article is a phone number mentioned which is the only potential "government tracking device". The second factor can be an authenticator app, or even a FIDO device
> Those old yubikeys [or similar HW device] have a flaw and are weak so we [read: the government] are deprecating them. You can change them here for the next year or use your phone or install our app.
Further in the future after a few cycles of the above
> Too few people use HW tokens so boot up your spy device now to log in.
Maybe it won't be HW flaws maybe it will be software. Maybe they'll mandate use of some chrome only feature. Maybe they bring out the Xbox authentication drink cans.
When we all have Neuralink chips in our brains, they will be able to read the data from our taste buds to check that we are really drinking a genuine can of Doritos™ Mountain Dew™.
Then I have to trust an app (which can have vulnerabilities) or a USB device which can be exchanged for a BAD-USB exploit carrier.
That looks like offloading security issues to the user.
Sounds far fetched? If the code repositories are that valuable, why wouldn't state actors try to mess with the hardware and commit underhanded C or similar?
The repository owners would detect the malicious commit? Well, in that case, why do we need 2FA in the first place?
That is such a strange comment considering that there is nothing that requires you to use specifically phone as your 2fa provider. For example I'm very happy with my self hosted Bitwarden (Vaultwarden).
Usually it ends up being a phone number or an app (on a phone). The first is to link to govt id and the second is that plus all the spying an app does.
Let's just remind ourselves that we're not born with attached cellphones. These things get broken, lost, stolen, etc. Besides, some people do not own one. How will they solve the problem of folks getting locked out? And if anyone says there is a workaround for cases like this, then what problem is it solving?
Authy synchronizes across devices and works on a computer. If you're using Github then you at least have a computer. And using 2FA on your own computer at least guarantees that the access is from your computer.
Sure, someone could hack your computer and get access to your GitHub, but if they're already on your computer, they can just change the code and do a git push too.
We had to buy yubikeys for various things since the whole cellphone thing wasn't going to work. You do have to buy multiple because of breakage or loss.
> github will give you backup codes you can print out and use in case somthing bad happens.
The backup codes have a "nearly never used" issue: since they're nearly never used, it's easy to forget where you put that piece of paper (I vaguely know where mine might be located, but I'd have to lose some time searching for it if I ever needed it).
And there's also the risk that the "something bad" affects both the TOTP device and the backup codes. If your home is flooded, for instance, you might lose to water damage both the piece of paper where the backup codes are and your mobile phone.
I think you bring up a great point. How can people do 2FA well for their situations? This is a practical question and people make many assumptions. A lot of what I know isn't clearly documented.
Clearly communicating a bunch of different options would be helpful for people.
Personally, I have 2 yubikeys, Authy synced to multiple devices, and the backup codes. There a bunch of options with different tradeoffs.
They provide a set of single use recovery codes for that purpose. I keep an encrypted copy of them in cloud storage and in several physical backups, so in the event that I lose or don't have access to neither my main nor backup yubikey, I can very likely still dig up a recovery code (eg by calling up a relative and asking them to read me the code).
You can buy a couple of Yubikeys, and use one as backup.
Probably feasible for most users of HN, but prohibitively expensive for millions around the world. Using a phone for 2FA is not great:
1. You can lose it.
2. If you're backing up 2FA to the cloud, then it's not 2FA any more.
3. If you use a password manager on your phone, then both factors are the same, it's not really 2FA.
i am only using github infrequently. the risk of getting locked out scares me. the likelihood of me forgetting which device i used to enable 2FA and maybe breaking/loosing/reinstalling said device (while forgetting to back up the 2FA to another device, and never mind remembering where i put the backup codes that were created 10 years ago) is much greater than anyone breaking into my account.
the end result will be that i won't be contributing code on github anymore but rather copy the project elsewhere and tell the developers where to pull my patches from.
You go through a review, and somebody asks who this guy xxx123 is that made this change, and somebody vaguely recalls it is some consultant that for some reason still have access to everything but quit two years ago. Love those meetings.
First, there is no requirement by SOC2 that says you "must use SSO for all applications". SOC2 talks about "logical access controls". For a team of 10, you would simply have a policy that states "any time a new developer comes on, they have to use MFA to access GitHub and this is enforced because we check the box in GH, blah blah" and "any time a developer leaves the company, we revoke all access, blah blah".
Also, if you're going to spend $20k+ on SOC2 because your clients require it, then spending the $20k on GitHub shouldn't be a problem because your clients should be paying for it (i.e. your ACV should be high enough to cover these things).
Yes, but SSO makes writing those policies (across all apps) much simpler. I think it's too bad that SSO is so heavily taxed, because it's quite an elegant way to solve account provisioning.
> I think it's too bad that SSO is so heavily taxed
Honestly, most software (especially SaaS) is underpriced for the value it creates. SSO is just an easy way to bump clients into the "real" pricing of the software while still letting them try most/all of the core features.
The only places that want SSO will be larger enterprises who don’t have a problem paying $$$ for an enterprise package. Tying SSO to enterprise plans is a great way to segment your market!
> At GitHub, we believe that our unique position as the home for all developers means that we have both an opportunity and a responsibility to raise the bar for security across the software development ecosystem.
The fact that GitHub assumes to be in this position is alarming. Combined with this enforcement which I do not appreciate, I’m reconsidering my investment and will actively start migrating off of GitHub.
Going to second that your tone is a bit on the snooty side.
I'll go ahead and join OP and "self-select" my way out of the all-encompassing developer community that GitHub represents, leaving you pro coders to it. Enjoy the walls around your garden.
> so if people like you, who don't care about that, select yourselves out - perfect!
This is an ad hominem.
You don’t know anything about security measures they do or do not take — just that they don’t appreciate a vendor mandating their security policy from a position of presumed authority.
That kind of bad faith comment isn’t constructive.
totp on gh doesn't "secure your dependencies" in any meaningful way though. For example npm and rubygems and dockerhub, and pretty much any other library packaging system don't pull code from gh, so the code on gh doesn't need to match the code in the library you are actually installing and running.
git secures itself. You can't "sneak" malicious code into a library if you can log into a dev's gh account. All you can do is add commits. It would be an obvious commit and the dev wouldn't push it to their package host.
How is this a win for you? Now you can blindly trust any github account now that they are 2fa to update their dependencies? That assumption doesn't make sense.
First the dependencies don't have to live on github or they could have been added by a non 2fa before this change
This is going to lock many out causing fewer packages to be updated meaning things are less trustworthy on github
People who use 2fa are not related to the same group who updates their dependencies
> People who use 2fa are not related to the same group who updates their dependencies
This does raise the question though - should they be related? If so, why? If not, why not?
From TFA, it seems github believes that a positive correlation there is worth pursuing and they offer reasons, though I have no idea how their corporate-blog-speak relates to their actual motives here.
I hate those paternalistic ethics. Your responsibility is not to get hacked. My responsibility is to make sure I don’t leak my credentials. Telling people how to live is not your responsibility.
A colleague lost their phone and send an email to GitHub asking for a password and 2FA reset. It was sent from his account email and it was succesful. I found it weird because it means someone got access to his email Github would provide access to their account.
Yes, but the TOTP is only usable once and cannot be reused across unrelated sites ("password stuffing"). And with WebAuthn / U2F the second factor is completely unphishable.
You cannot guarantee "completely unphishable", only that you cannot yet conceive of a way to do it. It's very dangerous to assume that something is completely secure.
WebAuthn binds the credential to the domain. Under the assumption that your web browser and security key is operating according to spec this is unphishable. If your web browser or key contains a bug, or the domain is breached then all bets are off anyway.
If you really must protect the user from themself (which I don't think you should, except in much more extreme circumstances), you can generate the password for them.
Yeah, a phone is an endless source of possibilities: every auth SMS is (not "can be", not "may be", but "by design") intercepted and logged. Every app can be breached remotely. Every interface, especially wireless, is a potential point of entry. Abundance of non-user-trusted components (like most processors, controllers and SIM). Possibilities of covert data exfiltration. Lots of sensors and ways of real human identification. Proprietary platforms and OSes that don't receive patches. A phone is the WORST thing to entrust your auth keys to.
OK, what's wrong with requiring a very strong password and not having any recovery option? If you lost/forgot your password, that's it, kiss your account goodbye. It puts the responsibility on the user, which is good imo.
I've never lost a password. And the only time I lost a somewhat important account (Google) was because of their automated recovery system. If I could select "disable account recovery" the account would've never been highjacked... OK maybe it would've in a few decades when the average PC could bruteforce a 128 bit password in a reasonable amount of time and Google disabled rate limiting for some reason.
Allow me to commit career suicide with my counter argument. My laptop random shuts off at least once a day (the screen goes freeze, then goes pink, it's an M1 mac if that helps). My phone's screen is mostly crunched glass shards, and when I charge it, the correct voltage doesn't go through. I think the problem is the outlets where I'm living?
Anyway, my own devices are the biggest risk in my threat model. Both my laptop (where I'd store the backup codes for GH MFA) and my phone (normal MFA authenticator app) turning into bricks is a WAY higher risk than someone stealing my Github password.
I'm not even a part of any orgs, no maintained packages (not on the account I use now, anyways). So I could store my backup codes on the cloud, but Google is getting fussier every day about 'lack of backup device' or whatever.
I could use a one time pad (and just memorize it), and store the encrypted backup codes on some kind of decentralized, permanent db. So a blockchain. But that costs money, and this is basically a venial irrelevant problem that I'm only complaining about to be a naysayer on this thread. So let's look for a free solution...
Well, what about... free anonymous blogging solutions! I can publish it to a bunch of these. I can use memorable usernames. Now, I just have to remember the platform(s, plural, cause one platform is still risky, could get the account banned or something by doing this, so I'll want to use all the big ones, reddit, twitter, and so on), the usernames (which will all be the same, to accommodate memorization lol), the 2fa backup code one time pad, and of course the password itself. But I could use the password as the one time pad to lighten the load. And the username could be really easily made memorable.
Yes! How easy is that? Okay, I'm going to try it out. If my approach is flawed, feel free to steal my GH account (as you can probably ascertain, it's a throwaway GH account, which is the only reason I'd be annoyed at having to 2FA for it).
I'll report back to this threat and leave a response to myself once I have this set up, in case anyone else is curious.
Since the backups are encrypted with my one time pad, I don't need a ton of trust, just reliability that they'll send me the encrypted codes. I already have them on the subreddit I made in my other comment, buuut, it's always nice to have another layer of redundancy, right?
I mispelled gh as gb, but that makes it more memorable (Great Britain, world war II spies, the cryptonomicon partially taking place in the UK, easy peasy).
Okay, so where was I? Right, the encrypted backup codes! Here is the code
encrypted = []
secret_key = input('secret key: ')
try:
for index, character in enumerate(input('secret to encrypt: ')):
encrypted.append(ord(character) ^ ord(secret_key[index]))
except IndexError:
print('Your key is not big enough to securely encrypt the secret!')
print('Go play cryptopals to see why using XOR that way would be bad')
print(''.join(hex(i) for i in encrypted))
Aaand the secret is live on reddit. For redundancy I need to plaster this everywhere (hiding it in public key exchanges would also be easy!), but this will do for now:
You joke, but device attestation is the next step, and the NSA are publicly pushing for it.[0] It's already impossible to get a burger from McDonald's using their app if you're using an unlocked bootloader.[1]
Are there any downsides to security keys as 2FA? Are they using a single standard that shouldn't accidentally change or be deprecated for some reason? Is it possible to use them on mobile devices? Are there any risks they might break? Any issues with Linux support? Which particular security key would you recommend and why?
Not that I know of, but you should definitely at least enable a second form of 2FA like the recovery codes OR a second security key, then print/write/store the file/key somewhere. If you lose your primary, then you can use that secondary. Never just have 1 form of 2FA without a fallback.
yubikey 5 nano, get two. i use it w/ ssh. took a little googling to integrate the gpg authentications key w/ ssh. instead of using ssh-agent, you'd use gpg-agent to manage the keys.
there are other integrations, for example, i can also unlock my mac w/ the yubikey.
On gnome on fedora at least, I can have my gpg automatically unlock when I login to the desktop.
I already have two steps on GitHub with the authy app but I don't get it. Why is it not good enough to send an email with a code when signing in without a cookie for people who don't want to opt in to two steps?
The way I see it my authy is a vulnerability because if someone were to guess my authy phone number, they could technically grab all of my TOTP.
I don't get this spoon feeding. I mean I would sign up to two steps where I can but something doesn't feel right about the lack of choice.
i hate checking email or looking at my phone for two step auth. either choice requires me to access another system. It requires far fewer steps to just tap the button on the side of the yubikey.
> Okay so which one do I buy and how do I use it with ssh. The documentation is not specific.
Oh crap, I was thinking this doesn't affect me because I already have two factors authentication but yes if I need to fish out my phone every time I need to git something (I use sash, not tokens) that requires authentication, I will definitely minimize what I do on GitHub.
The github.com documentation pages I read on this topic yesterday said the MFA requirement was for web sign-on and https GIT repo URLs. It explicitly said that SSH-based git repo access would not be affected. Has anyone seen contradictory statements published by github?
Edit to add: I mean SSH git access using a keypair registered with your account. (I don't know if there is some legacy option to use SSH with passwords, which I imagine would be discontinued if not already.)
If you're as crazy as I am, it looks like oauthtool+gnupg2 can do TOTP via the command-line on Linux as well. I think it's just another function that my homeserver will take over (or maybe a container). At least I can easily integrate this new info into my backup system, unlike apps on my phone...
For security keys implementing FIDO (which sometimes you can see referred to as WebAuthn, although that is partially inaccurate), there is currently no good way of backing up the key. If you lose it, then you'll need to recover your account with every service you had it registed it with, meaning that you'll need at least an additional factor on each service that's most likely not as secure as a FIDO key, unless you're registering two keys for every service which is very cumbersome and still makes you re register a lost key with each service.
There are proposals to address this either by chaining trust between security keys or by sharing "passkeys" (a webauthn credential). see https://news.ycombinator.com/item?id=31272867 Only apple implements it today as far as I know so there's no good way to recover from a lost or damaged key if you're not exclusively in the apple ecosystem
They do not give a single argument to show why they need to require 2FA, the same way they did not provide an argument for removing git password login. The more they will annoy users the more it will create space for a new service to compete with Github. Thanks Microsoft.
The biggest problem with Github in my opinion, is that personal accounts are usually the same as the one we use in the company we work for. So we are mixing personal and professional security
You don't need to give your phone number to enable 2FA on github. They'll annoy you every few months to give them your phone number as a backup but you don't need to do that. I hope it's never required either.
Don't they already offer a 2FA option now? Why not just let people use it who want to, and leave everyone else alone?
I am an adult. If I want to sacrifice some security in the name of convenience, I should have that option. All this is doing, is pissing me off, and giving me one more reason to move to another platform.
I think a good compromise is to allow organizations to opt to require 2FA in order to access their repositories, and allow individuals to opt to require 2FA for write permissions in their repositories (public or private).
PSA: you should ALWAYS download the recovery codes when you enable 2FA.
Reading a lot of "phone broken; locked out of account" comments here and I don't know whether they understand that local one-time only recovery codes should be downloaded and stored safely (maybe even printed and stored in a safe, I do not know). If you lose access to your 2FA device, use the "recovery code" option and use one of your recovery codes to unlock your account.
In my case it wouldn't anyway. Almost all of my 2FA is tied to my password manager as well. I am sure I am not alone in this. It is kind of scary to think about though.
I do the same but, for me, the threat of my password manager being compromised is much much smaller than the threat me not enabling 2FA out of laziness or the concern I might lose my 2FA codes. I keep my main email codes out of the password vault and that is enough to calm my nerves.
Not everyone has the same risk profile/tolerance, but I just wanted to say that I don't think anyone should feel bad about doing the best they can, even if that stops short of the absolute best.
This is why passwords are still king for many of us.
And that the very same reason people can't be trusted with passwords is the same as why they can't be expected to keep backups of their recovery codes.
Besides, where do you store your 2FA backup codes? At home?? Where they could be stolen without your knowledge? Most people’s homes are less safe than their online life.
Maybe a safe or cameras would be useful for when you're not home.
I sometimes leave my laptop on with motion started: https://motion-project.github.io/
The historic solution is in a safety deposit box at a bank. If you're talking about things like crypto cold wallets which might be extremely valuable, why risk leaving it at home? The cost for small items like documents tends to be reasonable. Good practice for things like ownership deeds and wills.
I don't think the average home thief would know what to do with a printout of your 2FA recovery code especially if it's buried in other paperwork. The real risk is loss from negligence or natural disaster.
With 2FA someone can break into your home, find your 2FA backup codes, defeat your password (e.g. by finding it in a leak) and they're in. If they are targeting you from your online life they need to first find out where you live and travel there.
Without 2FA someone can defeat your password and they're in.
I made this mistake when I enabled 2FA for Uber some years ago. Same old story. Somehow forgot to grab my recovery codes for Uber even though I had for everything else. I got a new phone, manually transferred all my google auth codes from my old phone, somehow missed Uber. And then a few months later after I had already reset my old phone I installed the Uber app and oops, I needed a 2FA code. Couldn't get one. And because Uber is tied to your phone number I couldn't even just create a new account without getting a new phone number. So I emailed their support (which is useless), got a bunch of bot responses about how to reset your password, finally got one real person to respond after several weeks. But they had no idea what I was talking about and clearly had no ability to actually do anything about the 2FA issue. So I gave up and now I'm just permanently locked out of using Uber. Which is fine, cuz fuck 'em. Now I use Lyft exclusively. Which doesn't matter because in my experience every Uber driver is also a Lyft driver.
Disconnect the phone number from that old account and allow him to create a new account using the phone number.
If I cancel my phone service, and someone else later ends up with my phone number, does it make sense that that person can never use Uber with their new phone?
Phone numbers are less transitory than street addresses, but much more so than email addresses. You should expect some amount of re-use, and need to be able to handle that situation.
Most companies offer manual processes to get round failed 2FA - for example, provide copies of ID, a video chat to confirm, security questions about account details (eg last trips you took), etc. I've had to do this for a couple of services where the process was quite onerous, but that's the point.
Doesn't help if you lose the keys and you're the only one that held them. This happened to me with an SSD that I took out of an old laptop, without realising that But locker stored its key on a chip in the laptop. I didn't even know that I had bitlocker enabled.
But Uber shouldn't have your trip details behind end to end encryption, so they should be able to unlock it.
Security questions are often shared between services, so someone who's hacked any of the other services could get the answers to these same security questions and then use them to bypass 2FA.
OK, replace "Uber" with your power company. You can't log into your account to update your expired credit card. Are they going to turn off your electricity because you dumb dumb didn't save your backup codes!
No of course not. They're going to help you out. Because we live in the real world where people make mistakes.
But then where did the 2nd factor go? I mean how is a recovery key meaningfully different from a password, except that it's a random string chosen by the service instead of by me?
Fear is being locked out is exactly why I'm reluctant to enable 2FA. To enable it and then just store the password (err, I mean, recovery key) in my password manager seems to just get me more hassle for exactly no additional security.
But.. is passwords being used a common way for them to leak? I've never heard of this before but I'm no expert. Isn't the threat model either company databases being (badly hashed and) leaked, or password managers being hacked wholesale?
I mean where am I supposed to store the recovery key if not in my password manager? My dropbox surely isn't better encrypted than my bitwarden. I work with the assumption that my password manager is the least insecure piece of data storage I use.
I really don't get it. How isn't 2FA just security theater if we're all supposed to store the recovery keys "somewhere safe"? Can we really expect people to deal with recovery keys in a more responsible way than they do with passwords?
>I mean where am I supposed to store the recovery key if not in my password manager?
My password manager (keepassxc) supports multiple databases. I store all TOTP recovery codes in a separate database (and with a different unlocking password) from the one that has regular passwords and the TOTP secrets.
All my databases are backed up on someone-else's-computer, but I only keep the regular-passwords-and-TOTP-secrets database synced to my devices.
I think "ideally" you print out the codes and physically secure them somewhere, so the risk isn't high. Recovery codes aren't about safety from being hacked, they're about mitigating the risk of you losing your 2FA code device.
In practice, 2FA is just another password anyway. What it really helps with is password reuse.
The best-case ordinary person is going to store them in "<user name>/My Documents/Security Keys/keys.txt".
The average-case person is going to ignore the generated keys because they are deluged with nonsense every day and can't filter out what is important anymore. Lots of people will get locked out of accounts before they learn that there is now yet another unwanted tech bureaucratic layer to take seriously.
I'm guessing in 5 years it will be normal to set up security questions for 2fa recovery keys. Or we'll add another 2fa for 2fa key recovery. The adding of layers will continue until we are all "secure" and we'll all have to ask for our misplaced keys from the NSA.
But what about on the server side? We generally know about passwords being salted and hashed. How are these recovery keys stored, regenerated etc? (I suppose they are also salted and hashed, but they are shorter and potentially easier to crack than good passwords, given a breach, no? Or just one longer, tougher recoveryKeyGenKey need be salted and hashed.)
This is of course implementation dependent, but ideally a recovery key is single use. You should also be notified by email or some other channel that the recovery key was used. Then you are immediately aware if this use was unauthorized and you can take appropriate action. This type of response is not possible for unauthorized password use.
I think there's at least a couple ways these are different:
1. It's easy to start ignoring such notifications if you regularly log in to new devices (or if logins expire). I don't think this is true to the same degree with notifications of recovery code usage.
If this is all though, then couldn't we just use username+password auth but have the server generate the password? Why at the phone to the loop at all?
Are you saying that iPhone-maker Apple and Android-maker Google (and TPM-mandator Microsoft) might not be able to imagine a future where the whole world isn't dependent on them for identity?
No, I am not suggesting that 2FA is a secret ploy by BigCos to make them needlessly important. It's perfectly possible to log into services without using your Google/Apple/Microsoft identity, even if they insist on 2FA. Use the email and SMS, Luke!
I don't believe I have the capacity to reliably preserve, in a secure location, recovery codes from dozens of different services over many years.
I suspect I'm not the only one.
There is pretty much nothing else in my personal life I have to do something like this with. The closest might be my physical SSN card or birth certificate. But that's one thing to keep track of, not a new thing every week or month to add to the stash. And even those, if they get lost, there is SOME way to replace them, usually.
We are asking people to do something that is not a thing they have practice at or otherwise have to do or are any good at or have the capacity for. And then blaming them when they fail to pull it off, where you're constantly getting locked out of things and/or constantly getting hacked, probably both at once.
I understand passwords alone don't work. I don't have a solution. I'm just predicting a very painful digital future for most people.
(My own "solution" is using Authy TOTP, installing it on multiple devices, figuring I will retain working access to at least one of these configured devices, and not bothering with backup codes. I don't know how secure it really is, or TOTP is in general, but it lets me keep using services that require it, without living in fear that I'm going to lose my phone and misplace the backup codes and lose access forever).
If you have a strong password, is that really the biggest security threat? I highly doubt that. 2FA is used to get unique identifiers and data mine people.
It is a breach of confidence that large parts of the open source scene has trusted GitHub and now has to jump through new hoops practically every year.
TOTP doesn’t have any shared identifier, just a shared randomly generated secret. FIDO2 generates unique IDs for each user/site pair, so there’s no mining possible even if a user uses the same hardware token for multiple sites.
I don’t think it’s true for the hardware token. The initial registration sends information about the token to the website (but the website can tell the browser it doesn’t need it, IIRC).
WebAuthn supports sending an attestation certificate during the initial registration. But with an implementation according to the spec this certificate only identifies the model of the security key used and thus is shared across a 5 to 6 digit number of physical keys.
This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).
This is intentional, given that “self-made” keys have plenty of ways to be insecure, and the average user cannot tell the difference between a well made key and one that is either accidentally or intentionally defective in ways that affect their security.
FIDO2 is designed to maximize security for the majority of users, and the majority of users are using Yubikeys or other hardware-backed tokens provided by big players in their space.
This doesn't make sense. As a website author, why would I visibly restrict the security keys to backdoored government keys, when I can simply give the government an invisible backdoor API or direct database access?
The blog post only mentions Mobile Push and WebAuthN. Is Github deprecating TOTP 2FA?
I also can't believe how many people are complaining about requiring 2FA. I have 2FA enabled for every single service that gives you the option. Backup Codes live in my password manager, and I have multiple yubikeys that I enroll whenever it's an option. It's been 10 years since I started doing this, and I've never been locked out.
Free services with 2FA are a recipe for problems. You will eventually have your phone stop working, you will lose your hardware fob, and you will lose your recovery codes that you forgot where you hid. There is no paid support, so you get what you pay for. Trying to get back into your account, if it's even possible, will take a long time and lots of work. If you are abroad and need access, you might be screwed. If it's not hard to get back into your account at that point, their security sucks.
I think we all need to consider the possibility of moving off of GitHub, or at least keeping a mirror of everything on another provider, and making sure any long-lived services that pull from GitHub know the other provider to use. You don't want an account lockout to mean you've lost all your work.
All great points and very common cases, yet services that force 2FA seem completely oblivious to this or just don't care about responsible users. In instances where it must be a phone number it is obviously for data mining.
It is a lazy way to cater to the lowest common denominator of users who will eventually fall for a phishing scam or install some keylogger and have their password end up in a dump.
Having support that is able to resolve 2FA problem creates new issues - how to prevent attacker from social engineering their way around support to gain access to your account. It’s hard to verify the identity online, across borders.
IMHO there’s no good answers on global scale. Identity should be handled on local level. Government already has process for issuing me new tokens even if I would loose all my existing ways of proving my identity. Local organizations know how to verify my identity using those tokens. I already put lots of trust on my own bank on this, so maybe they could also manage my digital identity.
Other providers do recovery by asking for a "secret code" that was only transmitted to you when you first signed up, or you can tell them to put a passphrase on your account. The first is more like a recovery code (but smaller), the latter is a second password you never use for anything else.
Another solution is for users to upload identification documents when they sign up for the service. To recover your account, the service asks you to provide the documents again. This way it doesn't matter what the locality is, and you can provide literally anything (a picture of a duck!). Some providers have asked me to send a copy of my Driver's License before, but I don't think I had provided it to them before recovery, so that wasn't great.
A couple startups are beginning to build "identity" products that I imagine will cover a lot of this space. I expect soon there will be one company that everyone uses for identity, and then rather than be at the mercy of GitHub, we'll be at the mercy of Sauron's Eye.
Had this happen to me in November when Android 12 corrupted my pixel 5 and I didn't have backup codes. Altogether it took 2 months before I was able to access everything again, the last thing I got access back to was my Xbox lol
You would be surprised how many people develop directly from github, either by using github’s web editor or a third party editor. Even if one does not do this, poor backup hygiene is the norm not the exception - for most devs I would would be willing to bet a sizable sum that github is their most reliable and longest lasting repository of code they have.
> I think we all need to consider the possibility of moving off of GitHub,
I've come to that conclusion, too. I moaned and groaned when Microsoft bought GitHub, but did nothing about it. Now I've begun the migration process.
I'd like to spell out some big-picture thoughts on 2FA. Security and convenience are antithetical to each other. Sometimes better solutions come along where you can have a little bit of both. But ultimately, they're trade-offs.
Do you value security, or do you value convenience? And in what proportion?
Furthermore, increasing security also increases fragility. There's more to go wrong. Posters here have been talking about losing their devices, and so forth. These are legitimate concerns. These points have rebuttals, such as recovery procedures, and so forth. OK, and you're sure grandma is up to the task, is she? All these convenience tools: they're easy to use until they aren't.
So not only do you have to think about security vs convenience, you have to consider downside risks on both ends of the spectrum. It's not as easy as saying "moar security" and reading press reports about the advisability of such systems.
> Do you value security, or do you value convenience? And in what proportion?
Or to look at this from the threat analysis side, there are many different threat models and not everyone has the same ones.
This is why it is so wrong for these cloud services to consider only one single threat model and impose it on everyone.
Denial of service is also a consideration in threat modeling and 2FA does increase the risk of loss of access. Whether that's worth it depends entirely on other factors which will vary for each individual and group. It's never a clear cut answer.
Personally I have TOTP enabled on my github account (not on a phone, that's too fragile) but that's because it makes sense for my use case.
There are other provider accounts where I have no desire to ever enable 2FA because I value access from anywhere with only my memory far more.
Cloud providers should not be making threat modeling decisions on behalf of users, each user needs to make their own.
Another reason to self host most things, you can implement your own best policy.
Wonderful news. Supply chain security is a disaster because developers won't opt into any kind of security features in the majority. Mandating 2FA is the obvious solution, and we'll all be radically safer for it.
Glad to see Github pushing this, I hope package repositories follow suit!
This change would certainly have helped against the infamous "Gathering weak npm credentials" research[0] from 2017, but I think that most recent supply chain security issues (in NPM, at least) have been due to: 1) typosquatting, 2) developers deliberately adding malicious (or unwanted) code into their own packages, and 3) deep transitive dependencies on packages that have genuine bugs that lead to vulnerabilities.
It's not clear that this 2FA requirement would fix any of those problems, but it could one day allow package management tools to flag up when one developer has given/sold control of their package over to someone else who has less of a reputation and might be malicious, as was the case with the event-stream package.[1]
Fortunately no one is claiming that it does solve all problems, and I wasn't arguing against that non-claim. My point was, what percentage of supply chain issues (since that 2017 research) would have been mitigated by this policy change?
To be extra clear, I'm not saying "This is a bad policy because it only stops some attacks", I'm just trying to get a sense of scale for how much this will help and how much more work needs to be done.
Do content creators have ask area to manage whatever songs they upload to Spotify? I actually don’t know! But if they do, I could see the need for 2FA on the content creator side.
I wish they'd let me stay logged in longer. I use about 9 machines. On each machine I use 2-3 browsers. On some of those browsers I have several profiles. GitHub logs me out if I haven't used it in about 2 weeks. The result is I have to login with 2FA almost daily. it's super annoying
bank sites do this too.. but they log you out after like 10 minutes of inactivity. The other day I was thinking of installing a plugin for firefox that will refresh a tab periodically. Not sure if that'll help the issue but worth a try.
How do I actually do this? I want to keep using ssh. I don't have and don't want a cellphone. I use FreeBSD. I can't find a simple explanation in the docs.
Why should someone be using a password manager? Generating needlessly complex, unique passwords for each service seems like a good way to lock yourself out of your own accounts in an emergency.
Laptop or phone stolen? No access to your own devices? Oops guess you can't login to anything.
The biggest problem is re-using passwords. Remember when that LinkedIn password database with plaintext/md5 (easily brute-forced) was leaked a few years back? And who knows what's going on with Heroku right now. There's been dozens, hundreds, thousands of leaks like this, from well known sites like LinkedIn to that small independent webshop where you ordered something a few years ago. And for at least some people those credentials that worked on LinkedIn may also work on GitHub.
Having a unique password per service solves that particular issue. But you're right that there's a "price" in that losing access to your passwords would leave you screwed. I'd strongly recommend making sure you at least memorize your email password, as well as backing it up in several places.
That is a scenario that is a lot less likely than some service having losing control over your password. If you are concerned about it, you can always write down the password into a physical notebook.
You can use OATHTOOL [1] on the command line or even roll your own TOTP implementation [2] in just a few lines of code in your favorite programming language.
I don’t believe this 2FA announcement applies to SSH access. The public key you use is already 2FA enabled, in a sense (the key is what you have, the password to unlock it what you know).
This applies to logging in to the GitHub Web application.
312 comments
[ 3.9 ms ] story [ 273 ms ] threadWhen I think of what the "most important" account is to me, my Github page is pretty damn close to the top. Mine is currently 2FA with an automated script that will scan my Github and back everything up to GitLab (at least the "important" projects), which is also 2FA'd.
Insane setup to protect data in one account but if I loose access it would be beyond a bad day for me.
Tiered access would be better here. No commits, repos without 2fa.
> active contributors (for example, those who commit code, open or merge pull requests, use Actions, or publish packages)
So it may not be required to simply file a bug report.
For me 2FA is super annoying because I run my browsers in private mode and I restart them multiple times a day, so I have to sign in quite often. It effectively makes it much harder for me to keep my privacy.
Not to mention loosing the freedom to log in to my accounts from everywhere without needing my devices. Things do get stolen/lost/destroyed and that is a more realistic threat for me than getting my password stolen.
https://docs.github.com/en/authentication/securing-your-acco...
[0] https://www.sdcard.org/consumers/faq
Better search for a neutral source.
https://github.com/alexjh/gpg-backup/blob/master/Makefile
Back then I thought that QR codes were a bit of a gimmick but now I'm way more confident that I'll be able to read them in the future.
https://www.verbatim.com.au/product-category/data-storage/op...
If it's instead just a few short strings of text (eg GH password recovery codes), then you could use physical storage.
eg engrave the codes into something that'll survive extremes (granite?), and keep them in a fire proof safe.
Or something along similar lines. Probably don't engrave into glass though, due to that potentially shattering in some situations.
i guess it would presumably be on-premises, because you're going to have to take it out to add recovery codes to it every time you add a new TOTP or whatever (or create a new private key or password) right? If it was, say, a safety deposit box at a bank, odds are it's not gonna wind up with most of your stuff. Even on-premises, the task of making sure "cold storage" stays sync'd with my evolving passwords, private keys, TOTP recovery codes, etc, seems like something I'm unlikely to keep up with.
If I manage to lose my phone, live and backup yubikeys then I have recovery codes.
It's going to have to be something pretty drastic to cause me to loose all of that.
But my response wasn't to turn off 2FA. It was the reverse - to turn on all forms of authentication made available, for all acccouts. If I lost control of it one way, I had another.
By the by, if you read the spec, FIDO expects you to do this in preparation for the day you lose your token. So no you are not the only one - people think about it all the time.
I don't really understand how it can be easier to break into a system if you need the username, the password and an SMS code, than if you just need an username and a password.
Obviously, SMS two-factor authentication is flawed. But one-time codes and WebAuthn are pretty good two-factor authentication methods to secure important credentials.
It's not good 2fa, but it is 2fa.
Sure, it’s common for sites to use your phone number both for 2FA and account recovery (whether single- or multi-factor—and single-factor account recovery is obviously a serious problem in a two-factor authentication environment), but the problem you’re complaining about is nothing to do with 2FA.
I think Fastmail hits the right balance, and explains it well: https://www.fastmail.help/hc/en-us/articles/360058752374-Usi..., heading “Why do I have to add a recovery phone number to set up two-step verification?”
It's still pretty much the worst form of 2fa there is, and not nearly as secure as people assume.
Clearly it's an extra bar for an attacker, no disagreement there.
How is 2FA a scam ? Nowhere in the article is a phone number mentioned which is the only potential "government tracking device". The second factor can be an authenticator app, or even a FIDO device
> Those old yubikeys [or similar HW device] have a flaw and are weak so we [read: the government] are deprecating them. You can change them here for the next year or use your phone or install our app.
Further in the future after a few cycles of the above
> Too few people use HW tokens so boot up your spy device now to log in.
Maybe it won't be HW flaws maybe it will be software. Maybe they'll mandate use of some chrome only feature. Maybe they bring out the Xbox authentication drink cans.
That looks like offloading security issues to the user.
Sounds far fetched? If the code repositories are that valuable, why wouldn't state actors try to mess with the hardware and commit underhanded C or similar?
The repository owners would detect the malicious commit? Well, in that case, why do we need 2FA in the first place?
Sure, someone could hack your computer and get access to your GitHub, but if they're already on your computer, they can just change the code and do a git push too.
I personally have 2 yubikeys registered as the second factor and it works great. They last years w/o any problem.
The backup codes have a "nearly never used" issue: since they're nearly never used, it's easy to forget where you put that piece of paper (I vaguely know where mine might be located, but I'd have to lose some time searching for it if I ever needed it).
And there's also the risk that the "something bad" affects both the TOTP device and the backup codes. If your home is flooded, for instance, you might lose to water damage both the piece of paper where the backup codes are and your mobile phone.
Clearly communicating a bunch of different options would be helpful for people.
Personally, I have 2 yubikeys, Authy synced to multiple devices, and the backup codes. There a bunch of options with different tradeoffs.
And for people that are unable or refuse to use a secondary device, there's no technical reason you can't run a TOPT app on your desktop.
Probably feasible for most users of HN, but prohibitively expensive for millions around the world. Using a phone for 2FA is not great:
1. You can lose it. 2. If you're backing up 2FA to the cloud, then it's not 2FA any more. 3. If you use a password manager on your phone, then both factors are the same, it's not really 2FA.
And it significantly degrades the user experience by requiring you have both devices available when you create an account to have any kind of backup.
the end result will be that i won't be contributing code on github anymore but rather copy the project elsewhere and tell the developers where to pull my patches from.
2FA doesn't mean only SMS or smartphone app.
It’s dumb but without it trying to tick all the compliance boxes is much more annoying.
Also, if you're going to spend $20k+ on SOC2 because your clients require it, then spending the $20k on GitHub shouldn't be a problem because your clients should be paying for it (i.e. your ACV should be high enough to cover these things).
Interesting site: https://sso.tax/
> I think it's too bad that SSO is so heavily taxed
Honestly, most software (especially SaaS) is underpriced for the value it creates. SSO is just an easy way to bump clients into the "real" pricing of the software while still letting them try most/all of the core features.
The fact that GitHub assumes to be in this position is alarming. Combined with this enforcement which I do not appreciate, I’m reconsidering my investment and will actively start migrating off of GitHub.
it's kind of true, isn't it (for certain programming languages)?
I'll go ahead and join OP and "self-select" my way out of the all-encompassing developer community that GitHub represents, leaving you pro coders to it. Enjoy the walls around your garden.
This is an ad hominem.
You don’t know anything about security measures they do or do not take — just that they don’t appreciate a vendor mandating their security policy from a position of presumed authority.
That kind of bad faith comment isn’t constructive.
The account is with the vendor in question. The vendor is literally the only entity in a position of authority.
https://techcrunch.com/2021/12/02/facebook-two-factor-mandat...
https://www.wsj.com/articles/tech-companies-push-users-to-ad...
https://www.twilio.com/blog/mandatory-2fa-account-login
git secures itself. You can't "sneak" malicious code into a library if you can log into a dev's gh account. All you can do is add commits. It would be an obvious commit and the dev wouldn't push it to their package host.
First the dependencies don't have to live on github or they could have been added by a non 2fa before this change
This is going to lock many out causing fewer packages to be updated meaning things are less trustworthy on github
People who use 2fa are not related to the same group who updates their dependencies
This does raise the question though - should they be related? If so, why? If not, why not?
From TFA, it seems github believes that a positive correlation there is worth pursuing and they offer reasons, though I have no idea how their corporate-blog-speak relates to their actual motives here.
You can put an auth cookie in a browser and achieve 2FA for 99% of use cases without bothering anyone.
But nobody does that when they can use 2FA as an excuse to force people to install their app or hand over more personal information.
No reason 2FA can't be just two passwords.
In the general sense perhaps. As it's commonly implemented, no not really.
Confusing, obviously incorrect.
> No reason 2FA can't be just two passwords.
Maybe somewhat less obviously incorrect, but still incorrect. Passwords can be phished easily, are managed by users, etc.
If you really must protect the user from themself (which I don't think you should, except in much more extreme circumstances), you can generate the password for them.
You know what is less secure than a password? A phone. A phone is a sim swap away from being hacked at anytime.
That's not two factors, that's one factor (something you know) twice, even if it is different passwords.
I've never lost a password. And the only time I lost a somewhat important account (Google) was because of their automated recovery system. If I could select "disable account recovery" the account would've never been highjacked... OK maybe it would've in a few decades when the average PC could bruteforce a 128 bit password in a reasonable amount of time and Google disabled rate limiting for some reason.
Anyway, my own devices are the biggest risk in my threat model. Both my laptop (where I'd store the backup codes for GH MFA) and my phone (normal MFA authenticator app) turning into bricks is a WAY higher risk than someone stealing my Github password.
I'm not even a part of any orgs, no maintained packages (not on the account I use now, anyways). So I could store my backup codes on the cloud, but Google is getting fussier every day about 'lack of backup device' or whatever.
I could use a one time pad (and just memorize it), and store the encrypted backup codes on some kind of decentralized, permanent db. So a blockchain. But that costs money, and this is basically a venial irrelevant problem that I'm only complaining about to be a naysayer on this thread. So let's look for a free solution...
Well, what about... free anonymous blogging solutions! I can publish it to a bunch of these. I can use memorable usernames. Now, I just have to remember the platform(s, plural, cause one platform is still risky, could get the account banned or something by doing this, so I'll want to use all the big ones, reddit, twitter, and so on), the usernames (which will all be the same, to accommodate memorization lol), the 2fa backup code one time pad, and of course the password itself. But I could use the password as the one time pad to lighten the load. And the username could be really easily made memorable.
Yes! How easy is that? Okay, I'm going to try it out. If my approach is flawed, feel free to steal my GH account (as you can probably ascertain, it's a throwaway GH account, which is the only reason I'd be annoyed at having to 2FA for it).
I'll report back to this threat and leave a response to myself once I have this set up, in case anyone else is curious.
2. Don't want my hand to cramp
3. I'm being silly, everyone should use MFA
Hey, what's your email address?
I mispelled gh as gb, but that makes it more memorable (Great Britain, world war II spies, the cryptonomicon partially taking place in the UK, easy peasy).
Okay, so where was I? Right, the encrypted backup codes! Here is the code
Aaand the secret is live on reddit. For redundancy I need to plaster this everywhere (hiding it in public key exchanges would also be easy!), but this will do for now:https://www.reddit.com/r/encrypted_gb_codes/comments/uj1fll/...
When I read this announcement I was happy because this means 2fa is getting even more known,.accepted and used.
[0] https://art.tools.ietf.org/id/draft-fedorkow-rats-network-de...
[1] https://c.mi.com/thread-3882246-1-0.html
https://www.forbes.com/sites/michelinemaynard/2017/03/28/as-...
there are other integrations, for example, i can also unlock my mac w/ the yubikey.
I already have two steps on GitHub with the authy app but I don't get it. Why is it not good enough to send an email with a code when signing in without a cookie for people who don't want to opt in to two steps?
The way I see it my authy is a vulnerability because if someone were to guess my authy phone number, they could technically grab all of my TOTP.
I don't get this spoon feeding. I mean I would sign up to two steps where I can but something doesn't feel right about the lack of choice.
https://forums.freebsd.org/threads/yubikey-5-nfc-not-working...
Oh crap, I was thinking this doesn't affect me because I already have two factors authentication but yes if I need to fish out my phone every time I need to git something (I use sash, not tokens) that requires authentication, I will definitely minimize what I do on GitHub.
Edit to add: I mean SSH git access using a keypair registered with your account. (I don't know if there is some legacy option to use SSH with passwords, which I imagine would be discontinued if not already.)
How secure it is I can't really say. But it will allow you to access services requiring TOTP without a cellphone or usb dongle.
https://authy.com/blog/introducing-authy-for-your-personal-c...
Install experience is not the best , but drivers work well
There are proposals to address this either by chaining trust between security keys or by sharing "passkeys" (a webauthn credential). see https://news.ycombinator.com/item?id=31272867 Only apple implements it today as far as I know so there's no good way to recover from a lost or damaged key if you're not exclusively in the apple ecosystem
The biggest problem with Github in my opinion, is that personal accounts are usually the same as the one we use in the company we work for. So we are mixing personal and professional security
I don’t have a phone number (that I am willing to fork over) so there’s that.
Welcome me, GITLAB!
I am an adult. If I want to sacrifice some security in the name of convenience, I should have that option. All this is doing, is pissing me off, and giving me one more reason to move to another platform.
Reading a lot of "phone broken; locked out of account" comments here and I don't know whether they understand that local one-time only recovery codes should be downloaded and stored safely (maybe even printed and stored in a safe, I do not know). If you lose access to your 2FA device, use the "recovery code" option and use one of your recovery codes to unlock your account.
Then again, people that use password managers at all usually have stronger passwords and less password reuse, so it can be an acceptable tradeoff.
Not everyone has the same risk profile/tolerance, but I just wanted to say that I don't think anyone should feel bad about doing the best they can, even if that stops short of the absolute best.
And that the very same reason people can't be trusted with passwords is the same as why they can't be expected to keep backups of their recovery codes.
Passwords suck. But so does every form of 2FA.
If your house catches on fire while you're asleep, there's decent odds both your phone and any printed codes are gone.
I don't think the average home thief would know what to do with a printout of your 2FA recovery code especially if it's buried in other paperwork. The real risk is loss from negligence or natural disaster.
Without 2FA someone can defeat your password and they're in.
What are they supposed to do to fix your issue without compromising their security model?
What you describe sounds like 2FA working like it's supposed to.
I nearly lost all my passwords with LastPass when something similar happened to me.
Is grandma supposed to file her 128 character recovery code in a safe vault when she just wants to get from the airport?
Stop blaming users for them not adapting to terrible authentication experience.
To me they're all terrible in one way or another.
Or else submitting a passport / drivers license to force unlock.
We have global identity systems. Why not use them?
If I cancel my phone service, and someone else later ends up with my phone number, does it make sense that that person can never use Uber with their new phone?
Phone numbers are less transitory than street addresses, but much more so than email addresses. You should expect some amount of re-use, and need to be able to handle that situation.
Doesn't help if you lose the keys and you're the only one that held them. This happened to me with an SSD that I took out of an old laptop, without realising that But locker stored its key on a chip in the laptop. I didn't even know that I had bitlocker enabled.
But Uber shouldn't have your trip details behind end to end encryption, so they should be able to unlock it.
Security questions are often shared between services, so someone who's hacked any of the other services could get the answers to these same security questions and then use them to bypass 2FA.
No of course not. They're going to help you out. Because we live in the real world where people make mistakes.
Fear is being locked out is exactly why I'm reluctant to enable 2FA. To enable it and then just store the password (err, I mean, recovery key) in my password manager seems to just get me more hassle for exactly no additional security.
What am I missing?
I mean where am I supposed to store the recovery key if not in my password manager? My dropbox surely isn't better encrypted than my bitwarden. I work with the assumption that my password manager is the least insecure piece of data storage I use.
I really don't get it. How isn't 2FA just security theater if we're all supposed to store the recovery keys "somewhere safe"? Can we really expect people to deal with recovery keys in a more responsible way than they do with passwords?
My password manager (keepassxc) supports multiple databases. I store all TOTP recovery codes in a separate database (and with a different unlocking password) from the one that has regular passwords and the TOTP secrets.
All my databases are backed up on someone-else's-computer, but I only keep the regular-passwords-and-TOTP-secrets database synced to my devices.
In practice, 2FA is just another password anyway. What it really helps with is password reuse.
The average-case person is going to ignore the generated keys because they are deluged with nonsense every day and can't filter out what is important anymore. Lots of people will get locked out of accounts before they learn that there is now yet another unwanted tech bureaucratic layer to take seriously.
I'm guessing in 5 years it will be normal to set up security questions for 2fa recovery keys. Or we'll add another 2fa for 2fa key recovery. The adding of layers will continue until we are all "secure" and we'll all have to ask for our misplaced keys from the NSA.
1. It's easy to start ignoring such notifications if you regularly log in to new devices (or if logins expire). I don't think this is true to the same degree with notifications of recovery code usage.
2. Devices can potentially be spoofed.
• there's no temptation for the user to use them on another website, where they could leak
• the server can ensure they are high-entropy (although AFAICS GitHub's recovery codes are only 40-bit…)
Moreover, if someone takes over your e-mail account, they can reset your password; but they can't reset the recovery codes.
Years go by, I need a code, they don’t work. Github could do nothing but tell me to start a new account.
Same old story; Github does not exist for you. It exists to make its workers and owners money. Whether it works or damages you is irrelevant to them.
The future has no obligation to the past. Don’t expect the codes to work if they change something that deprecates the old system they used.
I don't believe I have the capacity to reliably preserve, in a secure location, recovery codes from dozens of different services over many years.
I suspect I'm not the only one.
There is pretty much nothing else in my personal life I have to do something like this with. The closest might be my physical SSN card or birth certificate. But that's one thing to keep track of, not a new thing every week or month to add to the stash. And even those, if they get lost, there is SOME way to replace them, usually.
We are asking people to do something that is not a thing they have practice at or otherwise have to do or are any good at or have the capacity for. And then blaming them when they fail to pull it off, where you're constantly getting locked out of things and/or constantly getting hacked, probably both at once.
I understand passwords alone don't work. I don't have a solution. I'm just predicting a very painful digital future for most people.
(My own "solution" is using Authy TOTP, installing it on multiple devices, figuring I will retain working access to at least one of these configured devices, and not bothering with backup codes. I don't know how secure it really is, or TOTP is in general, but it lets me keep using services that require it, without living in fear that I'm going to lose my phone and misplace the backup codes and lose access forever).
That way it's easy to enroll a new laptop/phone/yubikey.
Once printed out, put in a plastic bottle and bury it in your backyard :)
If you have a strong password, is that really the biggest security threat? I highly doubt that. 2FA is used to get unique identifiers and data mine people.
It is a breach of confidence that large parts of the open source scene has trusted GitHub and now has to jump through new hoops practically every year.
This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).
FIDO2 is designed to maximize security for the majority of users, and the majority of users are using Yubikeys or other hardware-backed tokens provided by big players in their space.
How do they get unique identifiers from TOTP?
I also can't believe how many people are complaining about requiring 2FA. I have 2FA enabled for every single service that gives you the option. Backup Codes live in my password manager, and I have multiple yubikeys that I enroll whenever it's an option. It's been 10 years since I started doing this, and I've never been locked out.
I think we all need to consider the possibility of moving off of GitHub, or at least keeping a mirror of everything on another provider, and making sure any long-lived services that pull from GitHub know the other provider to use. You don't want an account lockout to mean you've lost all your work.
It is a lazy way to cater to the lowest common denominator of users who will eventually fall for a phishing scam or install some keylogger and have their password end up in a dump.
IMHO there’s no good answers on global scale. Identity should be handled on local level. Government already has process for issuing me new tokens even if I would loose all my existing ways of proving my identity. Local organizations know how to verify my identity using those tokens. I already put lots of trust on my own bank on this, so maybe they could also manage my digital identity.
Another solution is for users to upload identification documents when they sign up for the service. To recover your account, the service asks you to provide the documents again. This way it doesn't matter what the locality is, and you can provide literally anything (a picture of a duck!). Some providers have asked me to send a copy of my Driver's License before, but I don't think I had provided it to them before recovery, so that wasn't great.
A couple startups are beginning to build "identity" products that I imagine will cover a lot of this space. I expect soon there will be one company that everyone uses for identity, and then rather than be at the mercy of GitHub, we'll be at the mercy of Sauron's Eye.
GitHub is a remote. This "mirror" is kept on your disk.
I've come to that conclusion, too. I moaned and groaned when Microsoft bought GitHub, but did nothing about it. Now I've begun the migration process.
I'd like to spell out some big-picture thoughts on 2FA. Security and convenience are antithetical to each other. Sometimes better solutions come along where you can have a little bit of both. But ultimately, they're trade-offs.
Do you value security, or do you value convenience? And in what proportion?
Furthermore, increasing security also increases fragility. There's more to go wrong. Posters here have been talking about losing their devices, and so forth. These are legitimate concerns. These points have rebuttals, such as recovery procedures, and so forth. OK, and you're sure grandma is up to the task, is she? All these convenience tools: they're easy to use until they aren't.
So not only do you have to think about security vs convenience, you have to consider downside risks on both ends of the spectrum. It's not as easy as saying "moar security" and reading press reports about the advisability of such systems.
Or to look at this from the threat analysis side, there are many different threat models and not everyone has the same ones.
This is why it is so wrong for these cloud services to consider only one single threat model and impose it on everyone.
Denial of service is also a consideration in threat modeling and 2FA does increase the risk of loss of access. Whether that's worth it depends entirely on other factors which will vary for each individual and group. It's never a clear cut answer.
Personally I have TOTP enabled on my github account (not on a phone, that's too fragile) but that's because it makes sense for my use case.
There are other provider accounts where I have no desire to ever enable 2FA because I value access from anywhere with only my memory far more.
Cloud providers should not be making threat modeling decisions on behalf of users, each user needs to make their own.
Another reason to self host most things, you can implement your own best policy.
Glad to see Github pushing this, I hope package repositories follow suit!
It's not clear that this 2FA requirement would fix any of those problems, but it could one day allow package management tools to flag up when one developer has given/sold control of their package over to someone else who has less of a reputation and might be malicious, as was the case with the event-stream package.[1]
[0] https://github.com/ChALkeR/notes/blob/master/Gathering-weak-...
[1] https://www.eweek.com/security/node.js-event-stream-hack-exp...
To be extra clear, I'm not saying "This is a bad policy because it only stops some attacks", I'm just trying to get a sense of scale for how much this will help and how much more work needs to be done.
Laptop or phone stolen? No access to your own devices? Oops guess you can't login to anything.
Having a unique password per service solves that particular issue. But you're right that there's a "price" in that losing access to your passwords would leave you screwed. I'd strongly recommend making sure you at least memorize your email password, as well as backing it up in several places.
The scenarios in which you are unable to use your password manager are far more likely than you're making it seem.
[1] https://www.nongnu.org/oath-toolkit/oathtool.1.html [2] https://datatracker.ietf.org/doc/html/rfc6238
This applies to logging in to the GitHub Web application.