Hacker News Reader

Comment by soheil | Hacker News Reader

Github has blocked access to my account with 10s of popular projects because one day they randomly sent me an email to click on a link to enable 2fa auth. I was coerced to enable it. A while later I lost access to the phone where the 2fa auth app was installed not having back up codes since I was pushed to enable 2fa in a rush now I'm completely locked out. I contacted support no fewer than 15 times with them saying I need to create a new account since I did not link my cell phone nor have back up codes. I had that account for over a decade and now I cannot even control the projects I was working on nor access any of my private repos. I have been communicating with them using the email I have on my account, but this is not sufficient for them to restore access to my account.

View on HN

I'm sorry you lost your account (really, that sucks) but I don't understand framing this like Github is doing something wrong. It isn't like they banned you for spamming emojis.

You enabled 2fa, you lost your 2fa, and you did not have any recovery codes. Now you are asking for them to bypass the 2fa, and they are refusing.

Again, that sucks, but when I compare this to what the cell phone companies are doing with sim swapping, it increases my respect for Github.

Humans are humans though, and mistakes are inevitable. In this case, you get an email from the same address used to setup the accounts, and a corresponding complete stop in activity on the repo. Further, I bet OP could even demonstrate ownership of some of the code (whichever private repo's they happen to have checked out). All in all, it adds up, and as a paying customer its reasonable to expect Github to have some measures in place for scenarios like this.

> you get an email from the same address used to setup the accounts...

Isn't one of the biggest selling points of 2fa that if one account gets hacked you don't lose all accounts?

The selling point of 2FA is that if a hacker gets your password (from a DB dump from a compromise of site A that has bad security and no PW hashing) and tries to use it on site B, then site B still won't let them in because they don't have the second factor for site B.

In this case, an email account is the second factor. Your Github password is the first factor.

No, multifactor authentication uses different forms of evidence (i.e., something you have, something you are, something you know), not just multiple accounts. Given password reuse, cookies, etc., e-mail is a terrible second factor.

Same thing happened to me and my wife. The permanence of 2fa failing was something that didn’t exist until just a few years ago. For decades before that you could always get back in as long as you had an email. With that safety net in mind, it’s easy to go on “auto pilot” with using the internet and devices, not worrying at all about anything. And when 2fa came it kind of changed that with very little warning - or at least the warning wasn’t clearly distinct enough from previous-generation auth techniques so we (understandably so) didn’t pay enough heed. Fortunately it was only regarding an iTunes account so all we lost was access to a dozen VeggieTales movies, but it got me wanting to disable 2fa on my own account, but Apple doesn’t allow that anymore. Sigh.

I think most 2FA-supporting websites will let you regain access to your account if you lose your 2FA device but still have your password and email. Similarly to how most 1FA websites will let you regain access to your account if you lose your password but still have access to your email.

If Github is doing something different than most websites, that needs to be very very clearly communicated at setup time, otherwise people will assume Github behaves like other websites.

Wait, what would be the point of 2FA if you could reset access to the account with just 1FA, password and email?

I think it requires you to actually interface with support to prove beyond reasonable doubt that you are you.

Regardless of whether other websites' 2FA is useless, you need to make it clear when you do something different from them.

I think the big red warning is pretty clear.

> Warning: For security reasons, GitHub Support may not be able to restore access to accounts with two-factor authentication enabled if you lose your two-factor authentication credentials or lose access to your account recovery methods.

https://help.github.com/en/github/authenticating-to-github/r...

I just put 2FA on my Github account. During that enrollment flow, there were no red warnings, and nothing said that if you lose your 2FA device and your recovery codes you will be unable to ever access your account. In fact it said

>Treat your recovery codes with the same level of attention as you would your password!

Most people forget passwords all the time and treat that as no big deal because they can just reset the password. If people use that "same level of attention" for the recovery codes, then they will be lost just as easily, except this time people won't be able to recover.

Edit:

After enabling I got an email with a much more cautionary tone:

> Recovery codes are the only way to access your account again.

> GitHub Support will not be able to restore access to your account.

It's interesting they call this out in the email but not during the sign up process.

Let's see what happens when C-suite levels lose access.

GitHub 2fa is the worse implementation than the most I have encountered. They tell you that you can save recovery codes in facebook but guess what? It doesn't work! So you get lulled into having recovery codes safe in your FB account until you need it when they simply through error message that "oops, sorry. something went wrong, contact customer service.". So next, you try to find customer service and guess what? They have the worse setup for that as well! They have enterprise, pro and all kind of variations. You are expected to literally learn about their internal hierarchy of customer support organization and you scratch your head who the hell runs this thing? When you finally actually get through all that you find out pro is not pro and enterprise is not really enterprise and, BTW, whole team if off on some training this entire week so don't expect any response. You see, they don't think you actually have a job or any kind of urgengy. So you wait for response for days and likely you won't get any. There is no phone nuber to talk to human and emails are bounced around in their internal hierarchy. Losing your phone could be pretty bad thing if you have setup github 2fa.

Given how we all have placed GitHub front and center of our lives, there is no excuse for any of this. Even if I'd no recovery codes, I would expect GitHub had some process to get back access back. GitHub account should be looked upon with same reverence as bank account. The idea that you need to forget about money you have in bank account because you lose your phone and recovery code is mind numbing. They could charge you $500, run professional background check on you, get your credit card/bank info and verify it's really you, wait for 30 days, remove private repos and then grant you access again at least for your public repos. That's what I would expect an efficient customer obsessed organization to do.

There has to be a mechanism where you can get your account back if you provide some form of identification. I know that you get into other issues that way, but 2fa without a mechanism to restore account in case of phone/code loss (or inability to access, which is somewhat likely if you don't keep multiple copies of your codes) is pretty stupid.

I'd love to hear of any solutions on this. The solution should, however, be insusceptible to remote attacks, that could put a user's account at risk.

2FA with SMS has the problem that companies offer support by human and don't have a tight system for changing numbers to another phone, as proven again and again, resulting in accounts being compromised.

While the current solution of MFA aren't perfect, it's hard to come up with other solution that would be as safe or safer and prevent most to all mechanisms used to compromise accounts, like phishing, social engineering and other possible remote attacks. Giving you the possibility to save the codes somewhere physical has its downsides, but an important upside is that it allows _you_ to keep in charge your own security in most cases.

The one I've had to use (and find reasonable) is to have "trusted devices". That's how it works, at least with 1Password:

- You log with your 2FA into a device. - You set this device as trusted. - In case you lose your phone or 2FA device, log onto the trusted device and disable 2FA. - Then set up 2FA again with new phone or device.

It's not perfect, but it's workable. For instance, while I won't enable trusted device on my laptop, having my desktop stolen is a way rarer occasion, so I enable the "trust this device" options. It's just a matter of thinking on the threat model and where you can place spots for recovery while loosing as little security as possible.

But that fine because the trusted device is the second factor (what you have).

You can have multiple second factors with Github. I currently have two Yubikeys and one authenticator app enabled. If I lose one I can still log in with another.

If you can talk your way past two factor auth, it is useless.

I can see the argument for being forceful about prompting you to write down backup codes or whatever, but fixing that after-the-fact is something they should absolutely not been doing.

I do think that sites should offer better options for recovery. NearlyFreeSpeech do a really good job of this, offering seven methods of recovery and letting you decide how many you need to fulfil to be given access and which you want to configure. However, things like checking photo ID and more "offline" options are expensive to support, so I get why that is rare.

> If you can talk your way past two factor auth, it is useless.

> However, things like checking photo ID and more "offline" options are expensive to support, so I get why that is rare.

For you to characterize my efforts with Github support as "talking my way past it" is absurd. I was never once asked to provide a photo ID, etc. something I would have gladly complied with.

Unless Github obtained your photo ID or something similar before you enabled 2FA, that's kind of pointless to ask for.

They can re-activate the keys they automatically purged from my account, I still have their associated private keys. My github profile also has detailed information in its bio section including my past employer and links to my various social media/website. They could simply validate my ownership of one of those accounts etc.

Yeah seems simple to ask you to sign message with your key to prove its you!

The social media websites could have been hacked by some attacker, the private keys could have been obtained as well. Or put there by an attacker that is now locked out by 2FA.

The entire point of 2FA is that it's a second factor and no way around it without a second factor that is verifiable without doubt.

Nope. Many 2FA setups have a way to workaround the second factor if it’s missing. Recovery codes, emails to secondary addresses, faxing an ID, etc etc.

If you can social engineer yourself around 2FA it's not a proper 2FA setup.

So they could hack your other social media accounts possibly also with 2fa enabled but not be able to steal your back up codes smfh

What good would a photo ID be, really? It's not like they have an existing copy to compare it to, and a photo-copy quality copy of an average ID would be pretty simple to fake.

Nearly Free Speech is awesome <3 Anyone reading this, if you want a web host with hacker values — not in the blackhat sense, in the old school sense — check 'em out!

They are pretty unique and are good, although they are slow to update the service and it's starting to hit some real issues for me.

The most relevant issue for me being the lack of U2F (now WebAuthn, I guess) support. It is also really annoying you can't have restricted SSH keys to allow for automation that is locked down to single sites.

They have had those issues on their feature voting for years.

You can talk your way past it at AWS. Need a medallion signature guarantee (more intense form of notary) from a bank. It’s not easy but you can do that.

After that experience I switched to Authy, which does an encrypted cloud backup of your TOTP secrets.

> If you can talk your way past two factor auth, it is useless.

No, it just means you use a different 2FA. Here's some examples.

- Gov ID

- Pushing to a private repo

- Checking if IP matches historical records (hell, since they're fingerprinting everyone, why not use that?)

There's problems with 2FA. Mainly that it is on your phone. Phones are pretty valuable devices and it isn't unlikely that they get stolen. Even if Google backed up Authenticator to Drive, how do you get Authenticator back on your new phone?

It isn't hard to come up with a hundred scenarios where things fall apart. This is why there are different levels of security. But my GitHub isn't so sensitive that if I lose access I don't want anyone to ever get access. Yet at the same time it is sensitive enough (and GitHub is attacked enough) that I don't think just a user name and password is sufficient. Where's the middle ground? Even with YubiKeys I have to have multiples (as a backup in case I lose one). There's such a thing as "acceptable security levels."

We're trying to make things easier and safer for humans. But that doesn't mean they aren't still going to be human.

Not if you didn't previously acknowledge using these kinds of documents as 2FA. I set 2FA fully aware that if I lose my recovery codes I'm done. I don't want anyone ever to be able to restore my accounts without the codes. There are so many attack vectors with government documents. Just one service hacked that I had to upload them for verification and that kind of information can become 'public'. Humans and social engineering are one of the biggest attack vectors nowadays because of things like "humans make mistake, let's reset his account because he knew the last digits of the creditcard used and uploaded an ID".

Gandi handles this nicely with a checkbox in the settings that explicitly tells support to never ever restore the account if 2FA is lost

Gov ID would only work if you show it in person. A lot of people have a photocopy of ID. IP address is easy to fake.

The main problem is with targeted attacks. That's why SMS not secure

I think you're missing a key part of my point.

> This is why there are different levels of security. But my GitHub isn't so sensitive that if I lose access I don't want anyone to ever get access. Yet at the same time it is sensitive enough (and GitHub is attacked enough) that I don't think just a user name and password is sufficient.

Yes, there is stuff people would rather have destroyed than get into the wrong hands. But I personally can't think of any. But I do think we all agree that a password alone is not secure enough. What I'm saying is that there shouldn't be two choices. There should be middle grounds. SMS is not a great recovery tool for 2FA because it is trivial to fake. Specifically with my GitHub I'm okay with my security not being invulnerable to nation state actors. But I don't want it to be hacked because of a dictionary attack with some modifications. If someone has a copy of my passport then there's much bigger problems that I have than my GitHub being hacked.

The key part here is that there should be varying levels of security. The two levels we have (no 2FA vs 2FA) is too small.

* as to the IP: I was suggesting that it was being used in combination with other stuff. Not a standalone verification. Just like your phone number should never be a standalone verification. We're talking multifactor.

The thing is, GitHub shouldn't care what you want here.

GitHub is a social site, and the users accessing repositories are just as important as those that own them. You might not care if your account is compromised, but if other people trust your repoisitories and they get attacked through your compromised account, that is a problem.

> Gov ID would only work if you show it in person. A lot of people have a photocopy of ID.

Sounds reasonable. What's important is that you can securely recover the account at all, not that it's cheap.

I have restored access to a lost 2FA github account by presenting support with an artifact signed by my SSH keys I had linked to the account.

If you still have the keys, try:

ssh -i ~/.ssh/your_linked_privkey -T git@github.com verify

Edit: I previously wrote to pass your public key to the ssh client rather than your private key. Of course, that was incorrect.

The keys were removed according to support, I do not recall removing my public key from github.

I found this out the hard way as well, at some point since I last logged in they quietly enacted a policy of deleting keys that aren't used for roughly a year.[1] This meant I couldn't use the not so public method of verifying I still had access to various associated keys.

[1] https://help.github.com/en/github/authenticating-to-github/d...

Now that you mention this I vaguely recall receiving an email from them a long time ago that they were going to purge my keys. Wow so much of this is beginning to make sense. Why would they remove keys that people unknowingly may be relying on as the only way to gain access to their account?

Why should they support holding onto SSH keys forever in case you forgot to write down your backup 2FA codes, especially when they've never advertised that they'll accept SSH key-signed artifacts as proof of identity?

That was the only way I had access to my account completely unbeknownst to me. Had I known keys are the only way I would have remedied the situation.

Why would they purge SSH keys when they don't purge anything else? Why not just purge the whole account after a year of inactivity, if they care so much about space?

It's clearly not about space. Old SSH keys are a security hazard. Even moreso keys you aren't using anymore and therefore may not be particularly careful with.

Heck, even in this very scenario, if I haven't used an SSH key with GitHub in many years, and then GitHub receives an artifact signed with that key saying "I lost my 2FA token and backup codes, please reset account auth so I can log back in", I very much do not want GitHub to trust that artifact. If I haven't used the key in years, that probably means I don't have it anymore and either never got around to removing it from GitHub or forgot it was there.

The public keys on anyone's gh are publicly accessible. Your account doesn't seem to have any: https://github.com/soheil.keys

Of course, someone might still have removed those keys. IDK.

More likely that he didn't use the keys in a year and GitHub removed them for security reasons.

An email suggesting enabling 2FA isn't coercion. You voluntarily enabled 2FA and then choose not to protect the backup codes as they repeatedly warn to do because loss of them along with loss of your 2FA device will result in exactly this situation.

Now instead of accepting the result is the consequence of your own poor choices you are trying to shift the blame to GitHub.

This is why I’d rather have the phone number/email 2fa than a device 2fa even with the risk of sim swap.

If a human can’t give me my account back through tech support I’m not very keen on trusting my account a gadget that can break or get lost.

The risk of losing a phone and the backup codes is probably several orders of magnitude larger than the risk of being the target of a sim swap attack for the vast majority of users.

I would prefer to have u2f devices but be able to trust some tokens from friends and family without having to have them present at every registration, kind of like having a spare key with someone for every lock. I guess I'm not really worried about my relatives socially engineering my GitHub password out of me.

But what if your relative suddenly pass away? Then you'd be pretty screwed, wouldn't you?

I don't understand, if a neighbor moves or a key gets lost, you give a spare key to another neighbor based on your own key.

What difference does it make unless everyone you trust is gone or has lost everything? At that point you have larger problems than logging into online accounts.

But you already can do that. You can register multiple U2F keys and give it to a family member or put it in a safe. You can do the same with recovery keys.

The key problem is this:

>≥ without having to have them present at every registration

For example, I have given a token to a family member in another country, for proper utility I need that token back each time I register on another site..

As someome who lost access to their TOTP 2FA device for ~3 months I can definitely relate to that. But SMS is still insecure and there are better ways of doing this.

For one, no one is forcing you to only have one TOTP device. You can scan that QR code as many times as you want. Have them on multiple devices.

Depending on your threat vectors, putting them into a password manager that supports it (like Bitwarden) might also be smart. Less secure than fully offline, but definitely better than SMS.

As for the backup codes - one big encrypted text file synced to the cloud of your choice should do the trick, but if you prefer the "scary men with guns" kind of security, safety deposit boxes were literally made to store this kind of stuff (bonus points for on-paper encryption).

I discovered recently the QR codes are dumber than I thought; you can even print the QR codes out or store them as screenshots depending on your threat model.

Cite: https://www.eff.org/deeplinks/2017/09/guide-common-types-two...

I do something silly like that. I take the qr codes and convert them into Unicode glyphs and then put them in a gpg encrypted file. I started doing this after my first phone upgrade lost all my google auth entries. Now I can just decrypt in the terminal and directly scan all the codes into google auth should I ever lose them.

Do you mean you use something like grencode to literally draw the QR code using Unicode box characters or do you just decode and save their contents?

As an extra suggestion: if you use an Android phone for OTP, [andOTP](https://github.com/andOTP/andOTP) supports exporting directly into a PGP-encrypted JSON file which can then be either imported back into the app or converted back to QR codes with a script.

Since it allows you to trigger the export using a Broadcast Intent, I have it set up to do that as a part of my weekly backup Tasker script (of course, you could also just use any other sync solution and manually export when you add a new code).

Yeah, literal QR codes made out of unicode box characters. That way it's just scanning a bunch of codes instead of trying to recreate them just to scan them.

It's unfortunate, but I'd consider it a feature that you're not able to sign in without access to the physical devices linked to your 2FA account, i.e. it shouldn't be possible for someone with access to your Email account to be able to "phish" their way passed 2FA access.

Nevertheless the anxiety of losing the physical device with all my 2FA logins is what prevented me from enabling 2FA on most of my accounts until I was referred to Authy (authy.com) where you can sync your 2FA across multiple devices including your PC, which other than being very convenient, the effortless syncing + redundancy gave me confidence to enable 2FA on all my accounts as the redundancy ensures I'll still be able to access my accounts if one of my devices is broken/lost.

They probably have enough tracking info they could spot you just by you blinking. But they don't care.

They clearly have options to unlock my account by doing additional verifications but as you said they clearly don't care.

This happened to me a couple of years ago. Lost my phone, no recovery codes, so no access to github. Contacted support, they told me that they wouldn't be able to restore access even when I was communicating with the email associated with my account.

Luckily I only had public repos, so I created a new account and forked them all. Support had told me that if there isn't any login activity in the blocked account for a period of six months, they would delete the account and release the username. And yes, I had to follow up after six months were up to make that happen.

There's a reason that it's so important to save those recovery codes... that's your opportunity of last resort to recover access.

If github did their 2FA correctly/very securely, it may literally be impossible for them to give you access again.

The entire point of 2FA is to avoid someone taking over your email and then being able to access _anything_ tied to that email.

> If github did their 2FA correctly/very securely, it may literally be impossible for them to give you access again.

This is probably the most popular current dogma in security circles. This is a policy issue not an intractable mathematical problem. In theory maybe it could be as rigorous as math but in practice security is always relative.

Can you describe the architecture that would make this possible?

The entire point of 2FA is to avoid someone taking over your email and then being able to access _anything_ tied to that email.

The same can be said for strong encryption, where losing the keys means you have no chance of recovery. I'm not an advocate of defaulting to things like full-disk-encryption for that reason (and know people who lost a lot due to that.) I guess the underlying problem is "humans are fallible, strong security is not", and that risks "in the other direction" aren't often mentioned; would you rather have the risk of being hacked, or of losing access to your data forever?

So that's what happens if you enable 2fA. I have disabled it after I left a Github org where 2fA was required, and haven't enabled it since. However, Github now regularly sends me e-mails with auth codes, basically forcing mail-based 2fA on me. It's annoying as hell and I can't disable it, nor does Support want to do anything about this. Very sad as I'm using a password manager and my password should be safe.

> I'm using a password manager and my password should be safe.

You may have forgotten that it doesn't matter how you store your password, but the problem is that it is a single factor. Once compromised, one can gain access to anything within that account. You may be compromised by phishing, keylogging or other means. 2FA can help with making these types of attacks more difficult, although not impossible.

If you were "coerced" to enable 2FA, that was a decision made by one of the organizations/teams (company accounts) you were a member of, not GitHub. You had every option to leave it disabled, but, per that team's policies, you would have lost access to their repos.

E-mail newsletters announcing new features or options are not "coercing" you to do anything.

You clicked it, failed to know the ramifications of 2FA (which GitHub does spell out), and didn't secure your backup codes.

Take some responsibility instead of blame shifting.

Luckily it's git and you can just change the remote config of your local copies.

Reply on news.ycombinator.com