71–80 of 108 posts
Earlier quoted context omitted.
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...
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 nota…
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.
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.
Earlier quoted context omitted.
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 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.
Earlier quoted context omitted.
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 i…
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.
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.
Earlier quoted context omitted.
Yubikey in a safe deposit box is about as good as we can get, at least for the services that allow it.
The problem with this tactic is the need to go get the Yubikey every time you make a new account.
- 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
Earlier quoted context omitted.
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..
Earlier quoted context omitted.
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...
> 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 solution…
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 pol…
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'…
No offense, OP, but it seems easier to recover the email if you can prove physical identity.