> I can't, however, provide any 2FA codes or backup codes because they are printed on paper that has, I assume, been destroyed.
The situation you are in is very unfortunate and I am sympathetic but in GitHub's defence, this is exactly what I hope would happen when I enable 2FA. I would be very perturbed to find out that GitHub would grant access to my account given identity documents. There are some creative solutions (e.g: a countdown to the reset with progressively more aggressive email notifications to ensure the account holder is aware) but even they are problematic. So, this sucks, but it's the price we pay for security.
That's the same stance I have and why I'm torn. The little quirk here—where it makes slightly more sense—is that they received a legal notice at one point (from the US Government) about my account, there are plenty of online articles to corroborate me as me, and I have a fancy prison release ID that can help me identify me. Unfortunately this context is probably lost on the individuals who work their Zendesk.
The policies are rather draconian as others have mentioned. Anyone could be the victim of theft; mine just has an awkward paper trail attached to it.
I think the disconnect between you and GitHub support is that you're positioning this as a problem of proving your identity whereas for GitHub support it is a policy. The GitHub policy is: you lose your 2FA, you lose your account. Verifying your identity is not relevant. GitHub provides extensive tooling to protect your account (multiple methods of 2FA, recovery codes etc.) and so from their perspective, while this is deeply unfortunate, the policy is very clear and allowing you access to the account would be a major security issue (not for your account specifically, but for GitHub as an organization).
These (for good reason) draconian policies are the reason I am still hesitant to embrace 2FA. I understand the significant improvement in your security posture, and I would not want someone not-me to be able to reset my credentials. But the failure mode is just too catastrophic. You lose one thing and you are shit out of luck.
We need something better. I don't know what it would be.
> We need something better. I don't know what it would be.
Choosing a long, very secure password for your account works really, really well. GitHub hates this, however, and nudges toward less secure practices that are more likely to result in the sorts of compromises described in this thread.
I for one would appreciate the option to put an ID on file ahead of time, at least for important stuff like this. I like digital-only accounts for play, but for work stuff with real-world consequence, I’d like to link it to a real-world identity system…
Not unlike the signature cards banks used long ago, I guess.
Sure, maybe somebody motivated could defraud the government into issuing them a replacement ID in my name. But that’s big boy crime, not a casual “bribe a retail employee to SIM swap” kind of undertaking.
Sure, there are issues of access to government ID systems, and I know anything touching government names / “show me your papers” raises hackers’ hackles—I’m not saying require it, just that I’d choose it if it were a MFA option of last resort.
That's how you turn 2fa into single factor authentication ( The ID ).
GitHub is such a large attack vector for the whole planet, that I understand their stance.
GitHub support a "recovery code" more secure than government ID. Print it out, store on USB, store on QR, etc, and stick it in at least one secure safe.
The issue is less about having an ID on file, and more about verifying ID. In a world of excellent real-time deepfakes, how would GitHub verify ID at scale?
A fake ID is pretty easy to create, along with a fake face for a video chat where you can hold up your fake ID.
You don't have to do things "at scale". Github could require a substantial financial transaction to cover all the costs associated with ID verification and account re-instatement, as well as keep backups before that point so if it's proven after the fact that it was fraud, they could restore to the original state.
Like my data center (not US based) has a process where if you lose all of the documentation proving that a server is yours, you can go on site physically with ID, and the police and/or national identity service will verify on the spot that your finger prints match what is on file for the ID. It costs something like $300 and you risk being arrested if you're a criminal.
I think that part is made easier by the fact that I uploaded the ID in the first place under fully trusted conditions.
If I have the same physical piece of ID—as I imagine OP might have, upon release from prison—then they can directly compare it to the copy that I supplied previously. Scuff marks and specific document numbers included. I think that probably even scales.
If I lose access to my main identity document, one advantage of government ID is that I’ll urgently have it reissued. In most of the places I’ve lived, that’s the kind of thing you can validate against either the underlying authority or a sleazy-but-reasonably-accurate data broker. But in either case it’s out-of-band from my relationship with the tech company, in a way they can validate by semi- or fully-automated means, and with reference to an independent authority.
If somebody wants to physically mug me to steal my ID for access to my GitHub, I figure I’m pretty much out of luck—to paraphrase James Mickens [0], Mossad’s gonna Mossad.
An idea might be to require a financially meaningful deposit to pursue an account recovery like this. The deposit would be forfeit if the identity verification failed.
Though now that I write this, it creates a perverse incentive for a company to collect deposits and deny account recovery.
> I for one would appreciate the option to put an ID on file ahead of time, at least for important stuff like this.
I'm at that point of agreement. I don't want to say "national SSO ID" because that can get really Orwellian obviously. Being able to put an ID on file is a reasonable ask.
a passport is orwellian? i don't really get this fear of government issued IDs. if your government is so bad that it will abuse IDs for surveillance, then your government is the problem, and not having a national ID is not going to protect you.
Someone explained this to me the other day in a way that helped me understand the concern better.
Not already having a ton of easy and effective choke points on the whole citizenry (which such a card would eventually grow into due to its usefulness) is a safeguard against wannabe tyrants being confident they can crush dissent easily and thus to them seizing power in the first place. Just like I wouldn’t steal a car with a manual transmission because I know I wouldn’t be able to drive it successfully, and certainly not well enough to outrun the consequences.
If I were a fascist I’d be a lot more brazen if I knew that I could switch off every dissenter’s ability to travel, work, or even buy food, in an instant.
What if you were a fascist who exercised influence over Experian and TransUnion, the airlines, and of course the TSA? The horse has left the barn already.
Part of the problem here is that there is no prior association of an identity with an account. So proving who you are is somewhat irrelevant since even if the account has your name, email, and photo, that's no guarantee that the account was created by you. If identity verification were required ahead of time, then perhaps verifying identity after loss of access could be reasonable recovery method. But of course there are many reasons why requiring such verification is problematic.
Someone high enough in the food chain at GitHub can override that policy at their whim. I have personally had my day saved by that very "loophole" in another "lost access to an online service" situation in the past.
I'd assume that there is simply no "ok, this individual got released from prison and can proof everything" policy in place, and that might be the real issue here. Big organizations begin to tumble once you request something where there are no policies in place.
I find this infuriating. I get absolutely no sense that this is AI, and this bizarre attitude towards em dashes is nonsense. Loads of people use them, especially in less formal writing. Get over it.
I’m not sure that blaming tech support for not understanding context is the best approach here. The other sides of that context, which are understandable from their point of view, is that you were charged with some serious crimes. There’s a large delta between the charges and the conviction, but you’ve got some scary words written about you online. Secondarily, GitHub has policy so whereas you’re coming at it from a position of being correct, they’re in a position where they have to break policy. That’s a big risk.
Your best bet would likely be legal. US Federal law imposes some strict rules on lawyers for identity verification to combat money laundering so attorneys have a legally recognized toolkit to verify identity. Having a third party who works for you in the mix could help. Though again, it would involve breaking their policy so this would be a decision made several layers above Zendesk access.
Otherwise, I think this is doing precisely what 2FA is meant to do. It’s not okay for you and you’ve clearly lost a lot because of this, but with the current threat environment, GitHub has to be very careful especially with 2FA. From their point of view, there likely isn’t that big of a gap between your interactions and interactions with people who are trying to take over accounts. A lawyer may not work, but it sure changes that equation.
If you set up 2FA and then lose your 2FA, then that’s just life. Happens sometimes and you move on. GitHub absolutely doesn’t need to provide an in-person recovery service.
I agree that simply emailing in copies of identity documents after the fact shouldn't be sufficient. However, there should be a verification process that includes verification of identity documents through legal means, including perhaps a processing fee. The fee would preclude many attackers from even trying to break this process.
Maybe this would only work for new accounts as you'd probably need to provide identity information on before losing access.
As a matter of policy, sure. But at the same time, I bet there are some GitHub employees reading this that would be in a position to pull some strings and make an exception. For OP's sake, I hope I'm right!
I'm perpetually worried (and partially prepared) for this sort of scenario, as more of my accounts require 2FA. I dread the day I lose or break my phone, have my items stolen, there's a weather disaster etc. I try to make my hobby repos public and/or backed up in multiple places as a hedge.
I've always wondered how people manage this in practice. Is seems great if you never sign up for anything new, but I end up creating one account per week or something. How do you keep the key in your safe deposit box current?
Actually, this is now a solved problem. Root-of-trust pattern.
- Use Bitwarden or similar
- Set BW to recognize the Yubikey as one (of several, incl. TOTP ('Authenticator') code) second factor.
- On all other sites and services, generate passkeys (which are essentially virtual yubikeys) and save them in BW.
- In BW, save the password and TOTP. BW itself, on another device (or in a separate incarnation - e.g. the desktop app when authenticating the browser extension) is now your everyday means of authenticating to BW.
- BW-stored passkey is now your standard means of authentication for e.g. GitHub, Google, etc
- Put the yubikey in a safety deposit box
- Bravo, you have a very professional trust system
Apologies for asking you to repeat yourself. I'm not following this step.
"In BW, save the password and TOTP. BW itself, on another device (or in a separate incarnation - e.g. the desktop app when authenticating the browser extension) is now your everyday means of authenticating to BW."
Can you rephrase it and be specific which passwords and TOTP you mean?
So Bitwarden can store _the password and TOTP for Bitwarden itself_. (!) I actually keep this in an entry entitled 'How meta!' because I'm cute and silly.
So, let's say you're sitting down in front of a fresh install of Bitwarden. You can go to your phone in your pocket and get the password and TOTP and then set Bitwarden to not require a password for 30 days.
Similarly, let's say you've installed the desktop app for Bitwarden but not yet the browser extension. You can look up the BW password and TOTP in the desktop app and use that to authenticate the browser extension. Or vice versa! T
All my digital life is sorted with a password manager that sync's in a cloud (I know some consider this an anti-feature). I guess OP probably had to disclose information to someone (s)he trusts when going to prison and that trust was abused.
FWIW I had a similar conundrum with Slack. I had set-up my business Slack workspace in college; 4 years after graduation my university changed policies (they used to forward name@edu => name@alumni.edu).
I tried the normal means (support tickets etc) to no avail. The third or fourth time I got someone in account recovery. There was a very formal process for verifying my identity (I'm sure based on the process this happens all the time). Eventually I they helped me recover my account. It probably took a few months on the whole, but once I got the right support rep it was only a week or so.
So my advice would be to submit more tickets. Because they might have a process that not all support agents know about, and some are more helpful than others.
unfortunately, the techniques you are trying in order to get access to a dormant Github account are EXACTLY the same ones that github gets spammed with every day by bad actors attempting supply chain attacks. You don't have anything that proves your identity any more than any rando on the internet in Github's eyes at least. Everything you have presented here may be convincing enough to me, but probably not to GitHub's opsec policies.
Also suppose you Facebook account was compromised, that bad, sad for the person affected. May cause some media attention if the person was famous.
But if the right GitHub account is compromised, we could see massive supply chain issues. Or a big important web service with millions of users affected.
The downside of making a wrong call here is just really really big.
There are real businesses being deployed from GitHub.
No idea, which is why I recommend talking to a lawyer and not random people on the internet. Anecdotally I have heard stories of people successfully recovering web accounts via court order.
- If the most important thing is control of the Ruby gems, reach out to RubyGems.org support
- for your projects, if you have are past collaborators on those repos, they can sometimes open GH tickets referencing the project and vouch for you. Doesn't guarantee success, but adds weight
- GH (being part of MSFT) does have some channels for escalated identity verification. Lawyers or notarized ID may be needed...possibly expensive, but sometimes the only way
GH support is extremely strict on account recovery once 2FA/backup codes are gone. I wish you luck!
I was able to recover my Rubygems account :); unfortunately my projects were all private and solo :(; I am currently looking into lawyers—if anyone has any recommendations here my inbox is open.
I have no experience with any of this but thinking thru the other side, if I'm an IT helpdesk person getting an account reset/unlock request, I have no means to validate any identity paperwork anyone sends in. My response would be a curt email accd to policy and move on to the next IT ticket.
I think the legal path is your best bet unless you know someone higher up. A legal path could bypass all the offshore IT helpdesk staff (making assumptions, MSFT is a giant mega-corp).
I haven't used Rubygems before but doesn't it allow publishing from a new repo? pypi allows updating publishing configs.
A repo fork (and maybe more so the GitHub identify fork) is definitely not ideal but if your users can get updates to their packages, maybe it's best to move forward as well as possible.
Brutal situation—sorry you’re dealing with it. A playbook that’s worked for folks: assemble “hard” proofs that tie you to the account and ask GitHub Support for human identity review, not automated 2FA reset. Think: old phone number ownership, email at a domain you control, past billing receipts (Sponsors/Actions/Marketplace), SSH public key or GPG signature fingerprints from your commits, WHOIS matching your name, and ecosystem attestations (RubyGems maintainers confirming you own those packages). Put all that in one concise ticket and request escalation.
In parallel, talk to RubyGems support about stewarding the gems if GitHub recovery stalls. They can add/transfer ownership with credible verification, so users aren’t stuck. Worst case, spin up a new GitHub, mirror the repos, and note the account transition in README/changelogs—plus a release on RubyGems pointing to the new home. Not ideal, but it keeps your users safe and the project alive while you push on account recovery.
What you might consider doing is try contacting Ruby Central, or whoever it is that runs Ruby Gems. Even if they can't/won't give you access to the account, I'm wondering if they could/would freeze publishing updates to these gems until the account "owner" proves they are who they say they are. That way they don't risk giving control to someone who is hard to verify (you) and they prevent malware from being uploaded by the person who now controls your email until they verify the you are (which obviously they shouldn't be able to do).
Lost access to my phone, then went to Tarrant County jail awaiting trail (innocent until proven guilty but $250,000 bond where no humans or property harmed), and only was able to get a few G-M-@-1-L related accounts reset following a plea bargain to get back my freedom. Lots of corpses in that system. IYKYK.
What can you do? Ask nicely. Hope to escalate. First off though, think of Jack Handey...
If you lost your keys in lava, man, let 'em go, they're gone.
There are alarming statistics about phone snatching in London. Plus, we are NOT OUR PHONES. Doesn't GitHub have a way for people to verify and prove somebody's identity? Given that's a fact, isn't it best to disable 2FA and stop recommending it to people?
Following this post, I have reviewed all my main accounts, created recovery codes, set up backups, and added alternative email addresses, among other tasks. Hope for the best.
You could initiate some kind of legal action to access your data. You'd need a lawyer.
I think it's likely that you wouldn't have legal grounds to force them to give you your data but it's an approach that would most certainly get their attention at a higher level than anything you're able to do from a customer service perspective.
You'd have to have some legal argument as to why they could be obligated to produce the records under subpoena but the standards for that could be quite low.
Why not create a new account and fork your old repositories? You can restart with updating your old projects and overtime you’d build back up that reputation. I’d also add a note that you were the previous author and lost access to the repositories.
I wonder if you can make a creative small claims court claim against them.
Denying access to some repo where you spent x hours on which can be resolved by them paying you y dollars * x hours. And then hoping a lawyer takes pitty on you and restores the account?
I've been thinking about how they could solve this, since they accept payments; wouldn't it be possible to request a payment with a specific reference code to verify the identity? Paired with any other required identification process, documentation, etc.
There is, but it's not a phone number I have access to anymore. I changed it to the said person's phone number before I surrendered so that this exact scenario did not happen. I trusted the wrong person.
This hits me hard. So you went to prison, and the person you trusted the most... turned out not to be trustworthy. Please hang in there and hope you meet (or have met already?) people you can rely on!
I'm very grateful for the many people in my life I can absolutely rely on.
Seems like you could present this evidence to the police for an identity theft charge against the "wrong person." Or you could threaten to do so, and perhaps regain your property.
Except, read the comment again - Josh changed the account so that it referenced the other persons phone number. They did not steal his phone, and it could be framed that he gave them the account.
Accusing somebody of theft? Perhaps the police would side with the non-felon..
There's no dispute that he provided his telephone number, the dispute would be over the ownership of the GitHub account, which is a separate item, and perhaps still registered in his name. Without additional details, we're both guessing.
Maybe, depending on where you are in the world, you could make some kind of GDPR request to get access to your data, even if you don't recover your account?
I haven't any help to offer, but want to say that this post along with reading your site the other day has shown a level of composure and resiliency that i aspire to.
You sound paranoid and schizophrenic you should honestly try explaining your situation to someone you know or a professional. I think you’ll realize that your thinking is a bit delusional. I can’t really understand what you’re saying here.
The profile you responded to "techbro" was made 3 years ago, has 102 karma (i.e. 1 upvote every 10 days, on average), and has never submitted anything - zero submitted articles or profiles. My profile was made 12 years ago and has 3,118 karma (approximately averaging an upvote every 1.4 days) including lots of submissions of stuff I made, for example this Show HN that I was pleased to see make it to the front page with 36 points and lots of positive comments: https://news.ycombinator.com/item?id=43141139 (the resource itself is currently offline as I've temporarily replaced my website with 50 reasons why it's wrong to disrupt communications between a husband and wife. I'll replace my website as soon as this issue is solved.)
Right up your alley, I've actually written a cryptographic case study of some of the dynamics of this, I've just sent you a copy of it (you and I were in touch before - it was very well reviewed by professional cryptographers.) In your reply to this, please acknowledge your receipt of my email, and if you can, print it out as well, as it can become inaccessible later.
Of course, there are a lot of NSA-affiliated people who could come out of the woodworks to support parent's slander that I "sound paranoid and schizophrenic".
The reason they don't? They're witnesses in the FBI case and don't want to go to prison themselves. The FBI has already handwritten over 10,000 affidavits in this case. (They are writing by hand to avoid electronic tampering with evidence.)
I am not making a media story about it yet, which would be the next step, so there are no articles about this yet.
My reason for not doing so is not to bring extra attention to the case, but simply to solve it in a straightforward and expedient manner.
> I can't, however, provide any 2FA codes or backup codes because they are printed on paper that has, I assume, been destroyed.
The situation you are in is very unfortunate and I am sympathetic but in GitHub's defence, this is exactly what I hope would happen when I enable 2FA. I would be very perturbed to find out that GitHub would grant access to my account given identity documents. There are some creative solutions (e.g: a countdown to the reset with progressively more aggressive email notifications to ensure the account holder is aware) but even they are problematic. So, this sucks, but it's the price we pay for security.
That's the same stance I have and why I'm torn. The little quirk here—where it makes slightly more sense—is that they received a legal notice at one point (from the US Government) about my account, there are plenty of online articles to corroborate me as me, and I have a fancy prison release ID that can help me identify me. Unfortunately this context is probably lost on the individuals who work their Zendesk.
The policies are rather draconian as others have mentioned. Anyone could be the victim of theft; mine just has an awkward paper trail attached to it.
I think the disconnect between you and GitHub support is that you're positioning this as a problem of proving your identity whereas for GitHub support it is a policy. The GitHub policy is: you lose your 2FA, you lose your account. Verifying your identity is not relevant. GitHub provides extensive tooling to protect your account (multiple methods of 2FA, recovery codes etc.) and so from their perspective, while this is deeply unfortunate, the policy is very clear and allowing you access to the account would be a major security issue (not for your account specifically, but for GitHub as an organization).
edit: https://docs.github.com/en/site-policy/other-site-policies/g...
These (for good reason) draconian policies are the reason I am still hesitant to embrace 2FA. I understand the significant improvement in your security posture, and I would not want someone not-me to be able to reset my credentials. But the failure mode is just too catastrophic. You lose one thing and you are shit out of luck.
We need something better. I don't know what it would be.
> We need something better. I don't know what it would be.
Choosing a long, very secure password for your account works really, really well. GitHub hates this, however, and nudges toward less secure practices that are more likely to result in the sorts of compromises described in this thread.
I for one would appreciate the option to put an ID on file ahead of time, at least for important stuff like this. I like digital-only accounts for play, but for work stuff with real-world consequence, I’d like to link it to a real-world identity system…
Not unlike the signature cards banks used long ago, I guess.
Sure, maybe somebody motivated could defraud the government into issuing them a replacement ID in my name. But that’s big boy crime, not a casual “bribe a retail employee to SIM swap” kind of undertaking.
Sure, there are issues of access to government ID systems, and I know anything touching government names / “show me your papers” raises hackers’ hackles—I’m not saying require it, just that I’d choose it if it were a MFA option of last resort.
That's how you turn 2fa into single factor authentication ( The ID ).
GitHub is such a large attack vector for the whole planet, that I understand their stance.
GitHub support a "recovery code" more secure than government ID. Print it out, store on USB, store on QR, etc, and stick it in at least one secure safe.
The issue is less about having an ID on file, and more about verifying ID. In a world of excellent real-time deepfakes, how would GitHub verify ID at scale?
A fake ID is pretty easy to create, along with a fake face for a video chat where you can hold up your fake ID.
You don't have to do things "at scale". Github could require a substantial financial transaction to cover all the costs associated with ID verification and account re-instatement, as well as keep backups before that point so if it's proven after the fact that it was fraud, they could restore to the original state.
Like my data center (not US based) has a process where if you lose all of the documentation proving that a server is yours, you can go on site physically with ID, and the police and/or national identity service will verify on the spot that your finger prints match what is on file for the ID. It costs something like $300 and you risk being arrested if you're a criminal.
I think that part is made easier by the fact that I uploaded the ID in the first place under fully trusted conditions.
If I have the same physical piece of ID—as I imagine OP might have, upon release from prison—then they can directly compare it to the copy that I supplied previously. Scuff marks and specific document numbers included. I think that probably even scales.
If I lose access to my main identity document, one advantage of government ID is that I’ll urgently have it reissued. In most of the places I’ve lived, that’s the kind of thing you can validate against either the underlying authority or a sleazy-but-reasonably-accurate data broker. But in either case it’s out-of-band from my relationship with the tech company, in a way they can validate by semi- or fully-automated means, and with reference to an independent authority.
If somebody wants to physically mug me to steal my ID for access to my GitHub, I figure I’m pretty much out of luck—to paraphrase James Mickens [0], Mossad’s gonna Mossad.
[0] https://www.usenix.org/system/files/1401_08-12_mickens.pdf
An idea might be to require a financially meaningful deposit to pursue an account recovery like this. The deposit would be forfeit if the identity verification failed.
Though now that I write this, it creates a perverse incentive for a company to collect deposits and deny account recovery.
> I for one would appreciate the option to put an ID on file ahead of time, at least for important stuff like this.
I'm at that point of agreement. I don't want to say "national SSO ID" because that can get really Orwellian obviously. Being able to put an ID on file is a reasonable ask.
a passport is orwellian? i don't really get this fear of government issued IDs. if your government is so bad that it will abuse IDs for surveillance, then your government is the problem, and not having a national ID is not going to protect you.
Someone explained this to me the other day in a way that helped me understand the concern better.
Not already having a ton of easy and effective choke points on the whole citizenry (which such a card would eventually grow into due to its usefulness) is a safeguard against wannabe tyrants being confident they can crush dissent easily and thus to them seizing power in the first place. Just like I wouldn’t steal a car with a manual transmission because I know I wouldn’t be able to drive it successfully, and certainly not well enough to outrun the consequences.
If I were a fascist I’d be a lot more brazen if I knew that I could switch off every dissenter’s ability to travel, work, or even buy food, in an instant.
What if you were a fascist who exercised influence over Experian and TransUnion, the airlines, and of course the TSA? The horse has left the barn already.
You can use a TOTP authenticator with backup support (I use Aegis on Android, and less critical ones in Bitwarden), and backup your recovery codes.
Part of the problem here is that there is no prior association of an identity with an account. So proving who you are is somewhat irrelevant since even if the account has your name, email, and photo, that's no guarantee that the account was created by you. If identity verification were required ahead of time, then perhaps verifying identity after loss of access could be reasonable recovery method. But of course there are many reasons why requiring such verification is problematic.
Someone high enough in the food chain at GitHub can override that policy at their whim. I have personally had my day saved by that very "loophole" in another "lost access to an online service" situation in the past.
I'd assume that there is simply no "ok, this individual got released from prison and can proof everything" policy in place, and that might be the real issue here. Big organizations begin to tumble once you request something where there are no policies in place.
Why do I feel most of this is ai created text...whoever is posting will probably adjust their prompt, but who uses '-' mid text?
I find this infuriating. I get absolutely no sense that this is AI, and this bizarre attitude towards em dashes is nonsense. Loads of people use them, especially in less formal writing. Get over it.
I do.
I’m not sure that blaming tech support for not understanding context is the best approach here. The other sides of that context, which are understandable from their point of view, is that you were charged with some serious crimes. There’s a large delta between the charges and the conviction, but you’ve got some scary words written about you online. Secondarily, GitHub has policy so whereas you’re coming at it from a position of being correct, they’re in a position where they have to break policy. That’s a big risk.
Your best bet would likely be legal. US Federal law imposes some strict rules on lawyers for identity verification to combat money laundering so attorneys have a legally recognized toolkit to verify identity. Having a third party who works for you in the mix could help. Though again, it would involve breaking their policy so this would be a decision made several layers above Zendesk access.
Otherwise, I think this is doing precisely what 2FA is meant to do. It’s not okay for you and you’ve clearly lost a lot because of this, but with the current threat environment, GitHub has to be very careful especially with 2FA. From their point of view, there likely isn’t that big of a gap between your interactions and interactions with people who are trying to take over accounts. A lawyer may not work, but it sure changes that equation.
The person should be able to walk in the service provider's office and get an in-person help, restoration of access, by presenting ID docs.
If you are not European, I will be amazed.
If you set up 2FA and then lose your 2FA, then that’s just life. Happens sometimes and you move on. GitHub absolutely doesn’t need to provide an in-person recovery service.
I agree that simply emailing in copies of identity documents after the fact shouldn't be sufficient. However, there should be a verification process that includes verification of identity documents through legal means, including perhaps a processing fee. The fee would preclude many attackers from even trying to break this process.
Maybe this would only work for new accounts as you'd probably need to provide identity information on before losing access.
As a matter of policy, sure. But at the same time, I bet there are some GitHub employees reading this that would be in a position to pull some strings and make an exception. For OP's sake, I hope I'm right!
Social engineering attacks are a thing, you know...
Also could be a honeypot.
I'm aware.
I'm perpetually worried (and partially prepared) for this sort of scenario, as more of my accounts require 2FA. I dread the day I lose or break my phone, have my items stolen, there's a weather disaster etc. I try to make my hobby repos public and/or backed up in multiple places as a hedge.
Just do as I do and keep all the 2FA TOTP Codes in your keepass.
Yubikey in a safe deposit box is about as good as we can get, at least for the services that allow it.
I've always wondered how people manage this in practice. Is seems great if you never sign up for anything new, but I end up creating one account per week or something. How do you keep the key in your safe deposit box current?
The problem with this tactic is the need to go get the Yubikey every time you make a new account.
Actually, this is now a solved problem. Root-of-trust pattern.
- Use Bitwarden or similar
- Set BW to recognize the Yubikey as one (of several, incl. TOTP ('Authenticator') code) second factor.
- On all other sites and services, generate passkeys (which are essentially virtual yubikeys) and save them in BW.
- In BW, save the password and TOTP. BW itself, on another device (or in a separate incarnation - e.g. the desktop app when authenticating the browser extension) is now your everyday means of authenticating to BW.
- BW-stored passkey is now your standard means of authentication for e.g. GitHub, Google, etc
- Put the yubikey in a safety deposit box
- Bravo, you have a very professional trust system
Apologies for asking you to repeat yourself. I'm not following this step.
"In BW, save the password and TOTP. BW itself, on another device (or in a separate incarnation - e.g. the desktop app when authenticating the browser extension) is now your everyday means of authenticating to BW."
Can you rephrase it and be specific which passwords and TOTP you mean?
So Bitwarden can store _the password and TOTP for Bitwarden itself_. (!) I actually keep this in an entry entitled 'How meta!' because I'm cute and silly.
So, let's say you're sitting down in front of a fresh install of Bitwarden. You can go to your phone in your pocket and get the password and TOTP and then set Bitwarden to not require a password for 30 days.
Similarly, let's say you've installed the desktop app for Bitwarden but not yet the browser extension. You can look up the BW password and TOTP in the desktop app and use that to authenticate the browser extension. Or vice versa! T
Store only the backup key. It would be crazy to have a single key.
Can we use multiple Yubikeys for a service?
I use 2 yubikeys. I registered both on multiple services. So… yes, it is possible. One key is a backup if the other key stops working.
[dead]
All my digital life is sorted with a password manager that sync's in a cloud (I know some consider this an anti-feature). I guess OP probably had to disclose information to someone (s)he trusts when going to prison and that trust was abused.
Print out 2FA codes and bury them somewhere.
It's not that hard, and you feel like a proper spy doing it ;)
Please don't depend on this. Paper does not like moisture and soil is full of it.
Use an escrow or custodian (lawyer, bank, etc).
Paper inside a plastic bottle will be fine.
Soil is acidic, and soda bottles are meant to keep their seal for a two years, not a decade.
laminate?
Is your laminate rated to be in constant soil contact for however many years you need to hold onto a backup code for?
Don't you have a 2FA Recovery Code?
Far too many of the critical services (banks) still only offer SMS 2FA.
For most of them. It's a tool, but not a silver bullet
FWIW I had a similar conundrum with Slack. I had set-up my business Slack workspace in college; 4 years after graduation my university changed policies (they used to forward name@edu => name@alumni.edu).
I tried the normal means (support tickets etc) to no avail. The third or fourth time I got someone in account recovery. There was a very formal process for verifying my identity (I'm sure based on the process this happens all the time). Eventually I they helped me recover my account. It probably took a few months on the whole, but once I got the right support rep it was only a week or so.
So my advice would be to submit more tickets. Because they might have a process that not all support agents know about, and some are more helpful than others.
unfortunately, the techniques you are trying in order to get access to a dormant Github account are EXACTLY the same ones that github gets spammed with every day by bad actors attempting supply chain attacks. You don't have anything that proves your identity any more than any rando on the internet in Github's eyes at least. Everything you have presented here may be convincing enough to me, but probably not to GitHub's opsec policies.
Also suppose you Facebook account was compromised, that bad, sad for the person affected. May cause some media attention if the person was famous.
But if the right GitHub account is compromised, we could see massive supply chain issues. Or a big important web service with millions of users affected.
The downside of making a wrong call here is just really really big.
There are real businesses being deployed from GitHub.
I'm not even convinced it's the real person. Lost your items, lost your email, changed passwords, criminal records. Sounds like a scam for sure.
No offense, OP, but it seems easier to recover the email if you can prove physical identity.
Get a lawyer and contact GitHub through legal means.
What law do you think is relevant in this situation?
No idea, which is why I recommend talking to a lawyer and not random people on the internet. Anecdotally I have heard stories of people successfully recovering web accounts via court order.
Thoughts of the top of my head:
- If the most important thing is control of the Ruby gems, reach out to RubyGems.org support
- for your projects, if you have are past collaborators on those repos, they can sometimes open GH tickets referencing the project and vouch for you. Doesn't guarantee success, but adds weight
- GH (being part of MSFT) does have some channels for escalated identity verification. Lawyers or notarized ID may be needed...possibly expensive, but sometimes the only way
GH support is extremely strict on account recovery once 2FA/backup codes are gone. I wish you luck!
I was able to recover my Rubygems account :); unfortunately my projects were all private and solo :(; I am currently looking into lawyers—if anyone has any recommendations here my inbox is open.
I have no experience with any of this but thinking thru the other side, if I'm an IT helpdesk person getting an account reset/unlock request, I have no means to validate any identity paperwork anyone sends in. My response would be a curt email accd to policy and move on to the next IT ticket.
I think the legal path is your best bet unless you know someone higher up. A legal path could bypass all the offshore IT helpdesk staff (making assumptions, MSFT is a giant mega-corp).
I haven't used Rubygems before but doesn't it allow publishing from a new repo? pypi allows updating publishing configs.
A repo fork (and maybe more so the GitHub identify fork) is definitely not ideal but if your users can get updates to their packages, maybe it's best to move forward as well as possible.
I also imagine the identity proof for asking GH support to archive the old repo would be lighter than for recovering an account entirely.
> all my personal items were stolen IRL and the same person changed a bunch of my passwords.
Have you filed a police report? Do you know who this person is? Getting your stuff back might be easier than dealing with github support.
Coincidentally, this article was posted on HN yesterday and has been playing on my mind... https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my...
Brutal situation—sorry you’re dealing with it. A playbook that’s worked for folks: assemble “hard” proofs that tie you to the account and ask GitHub Support for human identity review, not automated 2FA reset. Think: old phone number ownership, email at a domain you control, past billing receipts (Sponsors/Actions/Marketplace), SSH public key or GPG signature fingerprints from your commits, WHOIS matching your name, and ecosystem attestations (RubyGems maintainers confirming you own those packages). Put all that in one concise ticket and request escalation.
In parallel, talk to RubyGems support about stewarding the gems if GitHub recovery stalls. They can add/transfer ownership with credible verification, so users aren’t stuck. Worst case, spin up a new GitHub, mirror the repos, and note the account transition in README/changelogs—plus a release on RubyGems pointing to the new home. Not ideal, but it keeps your users safe and the project alive while you push on account recovery.
What you might consider doing is try contacting Ruby Central, or whoever it is that runs Ruby Gems. Even if they can't/won't give you access to the account, I'm wondering if they could/would freeze publishing updates to these gems until the account "owner" proves they are who they say they are. That way they don't risk giving control to someone who is hard to verify (you) and they prevent malware from being uploaded by the person who now controls your email until they verify the you are (which obviously they shouldn't be able to do).
WELCOME TO TANGENTIAL INJUSTICE!
Lost access to my phone, then went to Tarrant County jail awaiting trail (innocent until proven guilty but $250,000 bond where no humans or property harmed), and only was able to get a few G-M-@-1-L related accounts reset following a plea bargain to get back my freedom. Lots of corpses in that system. IYKYK.
What can you do? Ask nicely. Hope to escalate. First off though, think of Jack Handey...
If you lost your keys in lava, man, let 'em go, they're gone.
There are alarming statistics about phone snatching in London. Plus, we are NOT OUR PHONES. Doesn't GitHub have a way for people to verify and prove somebody's identity? Given that's a fact, isn't it best to disable 2FA and stop recommending it to people?
Following this post, I have reviewed all my main accounts, created recovery codes, set up backups, and added alternative email addresses, among other tasks. Hope for the best.
You could initiate some kind of legal action to access your data. You'd need a lawyer.
I think it's likely that you wouldn't have legal grounds to force them to give you your data but it's an approach that would most certainly get their attention at a higher level than anything you're able to do from a customer service perspective.
You'd have to have some legal argument as to why they could be obligated to produce the records under subpoena but the standards for that could be quite low.
Do you personally know the person who stole all of your items and accounts?
I understand if you can't get or won't get in contact with them, but I'm curious as to whether this was a random or someone taking advantage of you.
Edit: Nevermind, I saw your response to someone else.
Why not create a new account and fork your old repositories? You can restart with updating your old projects and overtime you’d build back up that reputation. I’d also add a note that you were the previous author and lost access to the repositories.
They're private.
I wonder if you can make a creative small claims court claim against them.
Denying access to some repo where you spent x hours on which can be resolved by them paying you y dollars * x hours. And then hoping a lawyer takes pitty on you and restores the account?
That's a good idea!
I've been thinking about how they could solve this, since they accept payments; wouldn't it be possible to request a payment with a specific reference code to verify the identity? Paired with any other required identification process, documentation, etc.
IIUC, the issue is not that they can't verify OP. It's that there is a policy decision not to restore access.
So you have to work around the policy issue.
Is there a phone number associated with the account? How does GitHub want you to prove that you're you?
There is, but it's not a phone number I have access to anymore. I changed it to the said person's phone number before I surrendered so that this exact scenario did not happen. I trusted the wrong person.
> I trusted the wrong person.
This hits me hard. So you went to prison, and the person you trusted the most... turned out not to be trustworthy. Please hang in there and hope you meet (or have met already?) people you can rely on!
I'm very grateful for the many people in my life I can absolutely rely on.
Seems like you could present this evidence to the police for an identity theft charge against the "wrong person." Or you could threaten to do so, and perhaps regain your property.
Except, read the comment again - Josh changed the account so that it referenced the other persons phone number. They did not steal his phone, and it could be framed that he gave them the account.
Accusing somebody of theft? Perhaps the police would side with the non-felon..
There's no dispute that he provided his telephone number, the dispute would be over the ownership of the GitHub account, which is a separate item, and perhaps still registered in his name. Without additional details, we're both guessing.
You might want a lawyer's help to get that person to assist. Perhaps through an agreement not to sue for past wrongs, and maybe with a payment.
Maybe, depending on where you are in the world, you could make some kind of GDPR request to get access to your data, even if you don't recover your account?
It sounds like you trusted someone you shouldn't have. This person wouldn't happen to be someone who also has spent some time in prison?
thief changed your github password? why? how did he get get access to your github account ?
Not a thief - someone they trusted.
[dead]
I haven't any help to offer, but want to say that this post along with reading your site the other day has shown a level of composure and resiliency that i aspire to.
Good luck getting your access back.
ez get a new account
what's your gitname?
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
You sound paranoid and schizophrenic you should honestly try explaining your situation to someone you know or a professional. I think you’ll realize that your thinking is a bit delusional. I can’t really understand what you’re saying here.
Don't do this. We don't diagnose people on HN. Just flag the comment and move on, or, if you're worried, mail hn@yc.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
(I'm not a mod, just someone who cares a lot about this particular rule.)
The profile you responded to "techbro" was made 3 years ago, has 102 karma (i.e. 1 upvote every 10 days, on average), and has never submitted anything - zero submitted articles or profiles. My profile was made 12 years ago and has 3,118 karma (approximately averaging an upvote every 1.4 days) including lots of submissions of stuff I made, for example this Show HN that I was pleased to see make it to the front page with 36 points and lots of positive comments: https://news.ycombinator.com/item?id=43141139 (the resource itself is currently offline as I've temporarily replaced my website with 50 reasons why it's wrong to disrupt communications between a husband and wife. I'll replace my website as soon as this issue is solved.)
Right up your alley, I've actually written a cryptographic case study of some of the dynamics of this, I've just sent you a copy of it (you and I were in touch before - it was very well reviewed by professional cryptographers.) In your reply to this, please acknowledge your receipt of my email, and if you can, print it out as well, as it can become inaccessible later.
Of course, there are a lot of NSA-affiliated people who could come out of the woodworks to support parent's slander that I "sound paranoid and schizophrenic".
The reason they don't? They're witnesses in the FBI case and don't want to go to prison themselves. The FBI has already handwritten over 10,000 affidavits in this case. (They are writing by hand to avoid electronic tampering with evidence.)
I am not making a media story about it yet, which would be the next step, so there are no articles about this yet.
My reason for not doing so is not to bring extra attention to the case, but simply to solve it in a straightforward and expedient manner.