Password change: 10 steps to a good implementation

Our customer has an Internet portal and users whose data is entered into the domain. Access to your personal account is with a password, and where there is a password, there is also human forgetfulness.

We already had a password change page, but the mechanism was not optimal. This is how it all happened. The user left a request in the domain to change the password. In response, the system, in turn, left a request, which the administrator processed manually. He generated a password in the domain, and then attributed it in the application. The user received an email notification: "Your password has been changed to this."

We were confused by three points:

  1. Sharepoint, from which we leave in those places where it is not needed.
  2. The need for administrator participation. We did not want to distract a qualified specialist to such routine and frequent operations.
  3. We sent the password directly in the letter, which is not very safe. This password can be read from the screen. There are many options how it can leak.

And there was also a psychological moment: the system created such complex passwords that it was difficult to remember them, it remained only to write down somewhere. It is also unsafe. But such a password is very easy to forget. We can assume that this fact also influenced the number of applications for changing the password.

So, it became clear that it was time to change the mechanics of changing the password.

Cases of this type require a balance between informativeness and moderation. The user should not overload the details and paragraphs of the text. At the same time, writing two Input and putting one button is also wrong. Therefore, we brought in a designer and copywriter. We went this way and compiled 10 tips on how to do this in an optimal way both on the front-end and the back-end.

1. Issue a letter and a page with a password change by UI kit
Make a letter and a page with a password change by UI kit, that is, beautifully, in the general style of the site and well localized. (We wrote more about the UI kit here ). This is to make it easier to navigate. Even if a person is distracted from the process, then returning after 10 minutes, he will understand what resource is on and why he is here.

2. Write understandable texts.
Work on texts from which it is extremely clear what is happening now and what is required of the user. It is good that the texts comply with the editorial policy of the customer (communication style) and be compiled taking into account best practices . So beautiful and informative letters are obtained.

3. Indicate who and when reset the password.
We advise you to think about security. To do this, add information in the letter about when the link was requested to change the password and from which device, from which operating system and IP address. If the user did not request a link or sees a device that does not belong to him - this is definitely a reason to think, and possibly to sound an alarm. Lighten this information so that it is visible, but not callous. At the same time, the main link to change the password is drawn with a large bright button - the user sees it immediately.

4. Make a temporary password change
link A temporary password change
link is a worldwide practice. After the user has applied for a password change, he needs to change this password at a certain time: for example, within 5 minutes or 24 hours. It turns out that there is a clearly limited time window in which anyone can change the password for the user. Therefore, for security reasons, this time is limited.

5. Do not use third-party libraries on the password change page.
In our case, the previous password change page had a common master page with the entire project, and a bunch of different third-party libraries were already loaded on it. Do not repeat our mistakes, immediately make it safe. The new page to which the link leads and the password is driven in does not use any third-party libraries.

6. Eliminate technical support from the process (without emergency)
Let the user change the password himself, the operation is simple and easily automated. I requested the password, received the link and updated everything. Easy! Only in extreme cases, the support department is connected to the process - and only if the user himself could not change the password.

Problematic applications are handled by specialists who delve into the technical causes of errors and are able to independently correct them.

7. Make technical support a beautiful UI - they will be pleased
Simplify the work of technical support staff by showing applications for password changes not in Sharepoint, but in a beautiful UI of a special application system. It will be easier to work and more enjoyable too.

8. Write a history of errors
A technical support employee will work faster if he immediately sees in the application what exactly happened when the user was unable to change the password, that is, the entire history of errors that the user received. It’s much easier to understand the reasons given this information.

For example, the user does not understand what special characters are, or does not see a message that the password must contain uppercase letters. They have a lot of ways to find this application: by login, by the time when he left this application, etc.

9. Give technical support the opportunity to change the password.
Give the technical support service the ability to change the password yourself and tell it to the user. Sometimes it is very necessary. It is advisable that this password change also be done in safe mode - the page rises in a separate browser window and is made without third-party libraries. After the user confirms that everything is ready, it will close on its own.

10. Monitor requests and track dynamics.
We set up monitoring using Serilog. In ELK, we reset the event, and then through Grafana we monitor four types of situations when the user requested a password change:

a. Green line - the user was found in the domain,

b. Red line - user login was not found in the domain. For us, the second action is a marker. If this graph creeps up, it exceeds one attempt per day, this may mean that some unscrupulous comrade is trying to collect the base.

We can quickly respond to this by disabling IP. Further, this activity can be automated - for example, automatically disconnect IP after ten requests. But this does not always work, as some companies are surfing the Internet from one IP address, so for now we are just monitoring this chart. He is constantly looked at by a support service. And if he suddenly goes up, in the moment we will decide what to do.

c. Green line - the user has successfully requested a password change and opened the necessary link, respectively, we assume that everything is fine.

d. Red line - the user could not open the page with a password change. The link was with a non-existent ID, deprecated, etc. It is rather strange to assume that some hacker is trying to iterate over unique identifiers in order to catch those who are trying to change the password. But in principle, we can monitor these events - and if we see that this chart has gone up, we can analyze the events and see what happens. For example, it may turn out that the ID is broken, a piece is cut off from it and the link in the email is inserted clumsily.

As a result, we have four schedules and a continuous towel of events, where we can understand what happened. All instructions for setting up Grafana are here .

So we achieved our goals: we automated the password change, freeing up the administrator’s working time for more important tasks, and made the process as safe as possible. We hope this checklist helps you verify yourself in a similar task.