A new trend in account security is spreading: web services like LinkedIn reset passwords automatically when detect attempts of getting access with wrong password or from new locations. Thus, a user has to restore password every time when not using 2-Factor Authentication. The problem is that most support services ignore the rationale below. However, the LinkedIn support, to their credit, escalated the feature request for a setting "don't reset password on failed or suspicious login attempts" to their developing team.

The root reason of password resetting is that web services like Google and LinkedIn began using contacts (mobile phone numbers and emails) as logins. By this way, these services shared logins to everyone and thus made possible brute-force attacks on passwords for many accounts simultaneously. In other words, these company canceled the first secure factor of authentication.

Previously, the user created a login, which is unknown to all by default. This login was the first secure factor for authentication. And this way was secure enough when protected with a strong password. That is why the common way of getting access by an attacker was to find out the email to restore password and hacking an email box. These services must return secure logins to user accounts to stop brute forcing attacks on passwords.

Then, to plug this self-made security hole, these services reinvented 2-Factor Authentication by introducing secure temporary codes sent by another channel to the user. However, the use of mobile phone as a central secure device makes possible to get or lose access to all accounts at once. An attacker can easily steal a mobile device or SIM card. Another case is the impossibility to read a secure temporary code sent by a web service. There are too many reasons for that, beginning from broken display and unavailable mobile service. That is why 2-Factor Authentication has increased the risk of losing access to all accounts at once.

To avoid this risk, many users disabled 2-Factor Authentication, especially after losing access to their accounts because of broken display. Then, web services have invented a new way of irritating users and wasting their time: they began to reset passwords for accounts automatically on failed attempts of logging into or on other unexplained reasons. And now, users have to restore passwords every time because attackers reset passwords by brute-forcing them continuously. Another trivial case is the user's device with old password and the mobile app using it for getting regular updates.

Thus, these services manipulate users to force them using 2-Factor Authentication: to restore password the secure temporary code is sent. But an attacker does not have a chance to brute force strong passwords, which these services require from users. Otherwise such passwords are not considered strong, by definition. And the user location of login into does not matter in such case also.

In short, here's two questions: how to get such services to stop resetting passwords of accounts without user's permission and prompt? How to end this terrible trend of total neglect of user's choice in balance between risks, usability and reliability? It is especially important for IT professionals themselves because they should be able to take care on that.

  • First, I don't share your arguments. Contrary to you I consider the reset a useful second factor since it relies on the user but not the attacker having access to the reset email. And claiming that the user name in login is a first factor is ignoring that users usually share logins on many sites and that the are also often visible on the site itself (forums) or that they can be found in password leaks together with the password. Anyway, it looks for me like you primarily want to complain. And this question will primarily draw opinion based answers, which makes it off-topic. – Steffen Ullrich May 30 at 15:34
  • "How do I force a company to do what I want?" is not a security question, even if it is about passwords. This is a rant, not a question. – schroeder May 30 at 16:43
  • @schroeder, the question is not about what I want. It is based on usage experience and the history of authorization development. While a company wastes users' time and resources for executing their policies, it is a security question. Otherwise, what do policies defend? – Aleksey F. Jun 8 at 18:01

To answer your first question, there is no way to force a particular service to change their security policies. If you are a customer or employee, you may be able to insist on changes, but otherwise, there is no way to force people to implement a policy you want.

As to the second, the reason websites add security measures that affect users and override those individual users' preferences on the balance between risks, usability, and reliability is because the consequences of compromised accounts affect the entire platform and all its users, not just the users with poorer security practices. Spam, phishing, and abuse are problems everywhere, and no company wants their platform to be a cesspit of spam, phishing, and abuse.

To demonstrate an example, GitHub is now requiring or going to require tokens instead of passwords for both the API and for Git access. This prevents attackers from guessing passwords and then exfiltrating data; compromising accounts for spam, phishing, or abuse; uploading malicious code; or using grossly excessive amounts of resources. Large platforms usually have dedicated teams that deal with these problems and therefore may spend millions of dollars a year on dealing with abusive behavior due to bad actors. Adding even small security measures can dramatically reduce the level of abuse and therefore the cost of dealing with it. So, even if you don't care very strongly about the security of your account, other people do.

The risk here would be lower if users uniformly adopted approaches such as password managers with strong, random passwords (e.g, with 128 bits of entropy) and two-factor authentication. There are many ways to build recovery into 2FA: backup codes, restorable TOTP secrets (as with Authy), and multiple hardware tokens. However, many users don't adopt these practices; on the contrary, they tend to reuse the same, relatively weak passwords everywhere. As a consequence, the risk of compromised accounts is much higher.

So, ultimately, we can't let individual people choose what level of risk they'd like to have because oftentimes they will make choices that result in negative consequences to others. This is a widespread societal problem and isn't limited to the Internet.

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