Two-factor authentication
Everything you read in related to identification based on the fact that the requester knows. He knows his email address, knows how to access it (i.e. knows his email password), and knows the answers to security questions.
"Knowledge" is considered one authentication factor; two other common factors are what you have, for example, a physical device, and who you aresuch as fingerprints or the retina of the eye.
In most cases, performing biological identification is not feasible, especially when we are talking about the security of web applications, so with two-factor authentication (two factor authentication, 2FA), the second attribute is usually used - “what you have”. One popular variation on this second factor is a physical token, for example, :
The physical token is often used for authentication in corporate VPNs and financial services. To authenticate to the service, you need to use both a password and a code on a token (which changes often) in combination with a PIN. Theoretically, to identify an attacker, he must know the password, have a token, and also know the PIN of the token. In a password reset scenario, the password itself is apparently unknown, but possession of the token can be used to prove ownership of the account. Of course, as with any security implementation, , but definitely raises the barrier to entry.
One of the main problems of this approach is the cost and logistics of implementation; we're talking about handing over physical devices to each client and teaching them the new process. In addition, users need to have a device with them, which is not always the case with a physical token. Another option is to implement a second factor of authentication using SMS, which in the case of 2FA can serve as confirmation that the person performing the reset process has the account owner's mobile phone. Here's how Google does it:
You also need to enable , but this means that the next time you reset your password, your mobile phone could become a second authentication factor. Let me demonstrate this with my example. iPhone for reasons that will soon become clear:
After identifying the email address of the account, Google determines that 2FA has been enabled and we can reset the account using verification, which is sent via SMS to the account owner's mobile phone:
Now we need to select the start of the reset process:
This action sends an email to the registered address:
This email contains the reset URL:
When accessing the reset URL, an SMS is sent and the website asks for it:
Here is the SMS:
After typing it into the browser, we're back in classic password reset territory:
This probably sounds a little verbose, and it is, but the form confirms that the person performing the reset has access to the account holder's email address and mobile phone. But it can be nine times more secure than resetting your password via email alone. However, there are problems...
The problem is related to smartphones. The device shown below can certify only one factor of authentication - it can receive SMS, but not email:
However, this device can receive SMS и receive password reset emails:
The problem is that we consider email as the first factor of authentication, and SMS (or even a token-generating application) as the second, but today they are combined in one device. Of course, this means that if someone gets to your smartphone, then all this convenience comes down to the fact that we are back to the same channel again; this second factor "what you have" means that you have the first factor as well. And it's all protected by a single four-digit PIN...if the phone has a PIN at all. и he was blocked.
Yes, Google's 2FA feature certainly provides additional protection, but it's not foolproof, and it certainly doesn't depend on two completely autonomous channels.
Reset by username vs reset by email address
Should I only allow reset by email address? Or should the user be able to reset by name as well? The problem with resetting by username is that there is no way to notify the user of an invalid username, without disclosing that someone else might have an account with that name. In the previous section, an email reset ensured that the rightful owner of that email would always receive feedback without publicly disclosing their existence in the system. This cannot be done with just the username.
So the short answer is: email only. If you try to reset with just the username, then there will be cases where the user will wonder what happened, or you will disclose the existence of accounts. Yes, it's just a username, not an email address, and yes, anyone can choose any (available) username, but there's still a good chance you'll be indirectly revealing account owners due to users' tendency to reuse name.
So what happens when someone forgets their username? Assuming that the username is not immediately an email address (which is often the case), then the process is similar to how a password reset begins - enter an email address, and then send a message to this address without disclosing its existence. The only difference is that this time the message contains only the username and not the password reset URL. Either that, or the email will say that there is no account for this address.
Identity Verification and Accuracy of Email Addresses
A key aspect of resetting passwords, and perhaps even the most the key aspect is to verify the identity of the person trying to reset. Is this really the rightful owner of the account, or is someone trying to hack into it or cause inconvenience to the owner?
Obviously, e-mail is the most convenient and most common identity verification channel. It is not foolproof, and there are many cases where simply being able to receive mail at the account owner's address is not enough if a high degree of confidence in identification is required (which is why 2FA is used), but it is almost always the starting point. reset process.
If email is going to play a role in providing confidence, then the first step is to make sure the email address is in fact correct. If someone made a mistake with the symbol, then, obviously, the reset will not start. The process of email verification at the time of registration is a reliable way to verify the correctness of the address. We've all seen it in action: when you sign up, you're sent an email with a unique URL to click on, which confirms that you're the real owner of that email account. Not being able to log in until this process is complete ensures that there is motivation to verify the address.
As is the case with many other aspects of security, this model reduces usability in exchange for providing an increased degree of security relative to confidence in the user's identity. This may be acceptable for a site where the user values registration highly and will gladly add another step in the process (paid services, banking, etc.), but such things can repel the user if he perceives the account as “one-time” and uses , for example, just as a means to comment on a post.
Identification of who initiated the reset process
Clearly, there are reasons to use the reset feature maliciously, and attackers can use it in many different ways. One simple trick we can use to help verify the origin of a request (this trick usually works) is an addition to the letter with a proposal to reset the requester's IP address. It supplies the recipient some information to identify the source of the request.
Here is an example from the reset function that I am currently building into ASafaWeb:
The "find out more" link takes the user to the site , giving information such as the location and organization of the requester of the reset:
Of course, anyone who wants to hide their identity has many ways to obfuscate their real IP address, but this is a convenient way to add partial identification of the requester, and in most In some cases, this will give you a fair idea of who will complete the password reset request.
Email Change Notification
This post is permeated with one theme - communication; tell the account owner as much as possible about what happens at each step of the process, without revealing anything that could be used with malicious intent. The same applies to the situation where the password has actually changed − notify the owner!
The reasons for changing the password can be two sources:
- Password change after login because the user wants a new password
- Reset password without login because user forgot it
While this post is mostly about resetting, notifying the first one reduces the risk of someone changing the password without the knowledge of the rightful owner. How can this happen? A very common scenario is to get the password of the rightful owner (reused password leaked from another source, password obtained by keylogging, easy to guess password, etc.), after which the attacker decides to change it, thus blocking the owner. Without email notification, the real owner will not be aware of the password change.
Of course, in the event of a password reset, the owner should have already initiated the process himself (or bypassed the identification verification tools described above), so changing should not come as a surprise to him, however, email confirmation will be positive feedback and additional verification. In addition, it provides unity with the scenario described above.
Oh, and in case it's not obvious yet - do not send a new password by mail! It might make some people laugh, but :
Logs, logs, logs and some more logs
The password reset feature is attractive to attackers: an attacker either wants to gain access to another person's account, or simply cause inconvenience to the account/system owner. Many of the practices described above reduce the chance of abuse, but do not prevent it, and they certainly won't stop people from trying to use a feature in an unintended way.
For detecting malicious behavior, logging is absolutely invaluable practice, and I mean very detailed logging. Capture failed login attempts, resetting passwords, changing passwords (i.e. when the user is already logged in) and just about anything that can help you understand what's going on; this will be very useful in the future. Fix in the logs even individual of process, for example, a good reset feature should include initiating a reset via a website (capturing the reset request and login attempts with an incorrect username or email), capturing a visit to a website at the reset URL (including attempts to use an incorrect token), and then log the success or failure of the answer to the security question.
When I talk about logging, I mean not only recording the fact that a page has loaded, but also collecting as much information as possible, if it's not confidential. Guys, please do not log passwords! The logs need to register the identity of the authorized user (he will be authorized if he changes existing password or trying to reset someone else's password after logging in), any usernames or email addresses it tries, plus any reset tokens it tries to use. But it's also worth logging things like IP addresses and, if possible, even request headers. This allows you to recreate not only that the user (or attacker) is trying to do, but also who he is such a.
Delegation of responsibility to other performers
If you think that all this represents a huge amount of work, then you are not alone. In fact, building a reliable system for working with accounts is not an easy task. It's not that it's hard technically, it's just that it has a lot of features. It's not just about resetting, there's a whole process of signing up, storing passwords securely, handling multiple bad login attempts, and so on and so forth. Although besides that, much more needs to be done.
Today, there are many third-party vendors that are happy to take the pain out of it and abstract it all into one managed service. These services include OpenID, OAuth, and even Facebook. Some people (OpenID has indeed been very successful on Stack Overflow), but others .
There is no doubt that a service like OpenID solves a lot of developer problems, but it is also certain that it adds new ones. Do they have any role? Yes, but it is clear that we are not seeing massive use of the services of authentication service providers. Banks, airlines, and even stores all implement their own authentication mechanism, and there are obviously very good reasons for this.
Malicious Reset
An important aspect of each of the above examples is that the old password is considered useless only after confirming the identity of the account owner. This is important because if the account could be reset until identity checks, this would provide the opportunity for all sorts of malicious activities.
Here's an example: someone is bidding on an auction site, and towards the end of the bidding process, they block competitors by initiating a reset process, thus removing them from bidding. Obviously, if a poorly designed reset function can be misused, it can lead to serious negative results. It is worth noting that blocking accounts with invalid login attempts is a similar situation, but this is a topic for another post.
As I said above, if you give anonymous users the ability to reset the password of any account just by knowing their email address, then this is a ready-made situation for a denial of service attack. It might not be the one , which we used to talk about, but there is no faster way to block access to an account than with a poorly thought-out password reset function.
Weakest link
From the point of view of protecting a single account, everything written above is great, but you always need to keep in mind the ecosystem that surrounds the account you are protecting. Let me give you an example:
ASafaWeb is hosted on an amazing service provided by AppHarbor. The process of resetting a hosting account is as follows:
Stage 1:
Stage 2:
Stage 3:
Stage 4:
After reading all the previous information, it is already easy to understand which aspects in an ideal world we would implement a little differently. However, what I'm saying here is that if I publish a site like ASafaWeb on AppHarbor, and then come up with great security questions and answers, add a second authentication factor, and do the rest by the rules, that doesn't change the fact that the weakest link in the whole process will be able to break it all. If someone successfully authenticates in AppHarbor using my information, then he will be able to change the password for any ASafaWeb account to the one he needs!
The point is that the strength of a security implementation should be considered holistically: threats should be modeled at every entry point in the system, even if it is a superficial process such as logging into AppHarbor. This should give me a good idea of how much effort I need to put into the ASafaWeb password reset process.
Putting it all together
This post contains a lot of information, so I want to concentrate it in a simple visual scheme:
Remember that you should do the most detailed logging of each of these items. That's it, it's simple!
Conclusion
My post seems to be comprehensive, however there is a lot of additional material that I could include in it, but decided against it for the sake of brevity: the role of a rescue email address, the situation in which you lose access to the email associated with your account (for example, you quit your job), and so on. As I said earlier, the reset function is not that complicated, only there are many different points of view on it.
Even though the reset is not that complicated, it is often implemented incorrectly. Above we saw a couple of examples where the implementation can lead to problems, and there are many more cases where the wrong reset really caused problems. Recently it turned out that . This is a serious negative result!
So be careful with your reset functions, at various points, and when designing a feature, don't take off your black hat because there's a good chance someone else will wear it!
As advertising
VDSina offers inexpensive with a daily payment, each server is connected to an Internet channel of 500 Mbps and is protected from DDoS attacks for free!
Source: habr.com
