One of many reasons why you shouldn't build your own security from scratch (sometimes called "roll your own"), is that if you think there's a major problem with a security system and you can fix it as an amateur, usually you're wrong, not the security system. In most cases either your risk assessment is off and you're blowing a vulnerability way out of proportion, or there are well-established ways to mitigate the issue and secure the issue you've found. In some cases you're wrong altogether and it's not really a vulnerability.
We're not resistant to new ideas here, we're resistant to news ideas suggested by people who haven't demonstrated they accurately understand the issues or the advantages of industry standard alternatives.
Such is the case here. For example, you claim most users store backup passcodes on the cloud, when many services suggest you write them down instead:
You've probably heard that you shouldn't write down your password (and
you can't write down regular authentication codes), but these one-use
codes are an exception. You should definitely print them or or write
them down and keep them in a place where you can find them. Ideally,
they would be separate from your phone, perhaps in a fireproof box or
safe with other important paper documents.
-Eric Ravenscraft on Lifehacker, see also GSuite support
Some other existing solutions in industry:
- GitHub has a special deal with Facebook to let you log in to Facebook
as a pre-authorized recovery token.
- Facebook lets you authorize friends to help you recover your account
- Using a recovery email, keeping it simple. It may not be the most secure method, but it's still probably more secure and user-friendly than a non-standard, buggy implementation that you create yourself. GMail has its own 2FA with a security check-up feature, strong protections against brute force, password leaks, and fake password resets. If someone has access to your users' GMail (say a family member stealing an unsecured phone or someone abusing the reset system) they have some serious issues beyond your social network. If that tiny amount of risk is problematic for you, your level of risk aversion probably requires an experienced security team, not a solution put together by someone relatively new to the industry.
- Use a hardware token like Yubikey or a FIDO U2F key, like many banks offer, often free or subsidized. This may seem extreme, but if your level of risk aversion means that GMail isn't secure enough for some users, you need strong, established security methods, not a custom-built solution that hasn't been evaluated by experts for years.
Other systems just rely on admins and tech support to reset your device for you (see for example MTU's support page or Duo FAQ). Account recovery if users lose everything is a concern for most organizations (especially for you if you're suggesting easy-to-lose recovery files), so if you're not relying on external sites like Google for authentication you'd better be prepared to foot the bill for tech support for account recovery, or the bad PR from locked-out users.
Besides your gross mischaracterization of the security issues and lack of alternatives here, your scheme isn't a good alternative. You're basically proposing that instead of using a passcode, then putting that passcode in a file and saving it on the cloud (or writing it down, which is more secure), that the file becomes the key. There's several issues here:
- First, by asking users to hide the recover code or file, you're asking for security through obscurity. As I've said before on other questions of yours, real security is not about confusing an attacker with a few dozen options, it's about making attacks completely infeasible. You don't secure a front door then hide the key under one of the nearby rocks.
- The second issue is that you don't even have a guarantee of security through obscurity because you're depending on the users to hide and protect the file for you. Most users won't do that and will pick an obvious file. Congrats, instead of using a backup_codes.txt file on their Google drive, the average user will now use back_file.jpg on their Google drive.
- Third, your scheme really isn't that different from asking the user to hide their key inside an innocuous looking text file. If the user is already worried about security, they'll hide the backup passcode in a file themselves.
- Finally, the scheme isn't user friendly. How do they know which file to choose? How do they know where to store the file for safety? How would they remember which file it is years later? Some people already have a hard enough time finding their backup codes years later even after writing it down and taking a picture of it. You don't seem to understand how hard it is to protect files yourself since you recommend "the file could be firefox.exe", which is a file that regularly and irreversibly changes.
Note: the questions above are rhetorical questions and I don't intend on getting into an extended discussion of your ideas.