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.