-5

On the dark net we can buy database leaks with nicknames, emails addresses, passwords, questions/answers to prove identity, and other fields. Sometimes the passwords/answers are in clear, sometimes only hashed without unique salt, and we could use rainbow tables to found the password and/or answers.

Most users on the Internet use the same password and answers on many websites. This means if an attacker could obtain an email/password with a db leak, he could connect easily to the user account on multiple websites.

Experts suggest to use 2FA, for example the user can install Google Authenticator on his mobile device, then when the user/attacker try to login from a desktop browser, a confirmation is required on the mobile.

Great, but the problem of this method is the user needs to save somewhere his backup codes on the Internet (if his house burns), and they need to easily access these files without his mobile Google Auth app in case if he lost their phone.

We could imagine that most of users will save their backup codes on a cloud storage or maybe send them to yourself per email. The problem is here, because the attacker can have access to the user services not protected by 2FA. This mean the attacker could check on each cloud storage services with the email/password of the user, and just make a search to find each file that matches "Backup-codes-*.txt"

This is a possible vector of attack. There is a solution to prevent this attack please?

closed as too broad by S.L. Barth, Tobi Nary, ThoriumBR, Steve, Rory Alsop Sep 24 '17 at 14:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    But your question body is very confusing. If your question is how to protect your users from their own mistake of credential re-use, then 2FA is the mechanism that has been created to do this. But you state this. You then switch topics to say that the password recovery mechanism could also share info, which is another topic. 2FA has proper mechanisms for recovery, but there is only so much you can do to protect users from their own actions. – schroeder Sep 22 '17 at 8:44
  • 1
    Yes, the question is how to protect my users from their own mistake of credential re-use. I speak about 2FA just to explain it's not enough as solution because of recovery account solution ("I forgot my device"). I've updated my post, I hope it's more clear. Thanks – lakano Sep 22 '17 at 8:57
  • 3
    Obligatory xkcd: xkcd.com/792 – a CVn Sep 22 '17 at 8:57
  • 1
    You can't save you users from all their own mistakes. – jigfox Sep 22 '17 at 9:08
  • 3
    "the attacker could easily make a research to find the backup codes" If the attacker is persistent enough, they are pretty much guaranteed to get in. However, for the huge majority of people, attackers don't care about you or your account; all the care about is getting access to some account. (Same with burglars; they don't care about you or your stuff, but they do care about stuff. That's why making yourself and your home a little less attractive can be sufficient deterrent.) On the whole, very few people are specifically targetted. – a CVn Sep 22 '17 at 9:48
2

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.