Divine authentication approach
I completed a course at the University of Virginia in 1992 on the subject “Computer Science in Simplified Form”. The reason I chose the simplified course was because the usual CS course at the University of Virginia required an engineering school and I was absolutely not ready for such a quantity of mathematics and physics. The beauty of the simplified course was that I could visit all the objects I was interested in, skipping the rest.
One of my favorite subjects, at least he remembered most of all for me, was “Algorithms”. I always tell the people who ask me about this, that this subject influenced my development, as a programmer, the most. I don’t know exactly why, but a few years ago I had a strange presentiment, and for some reason I went to the Randy Pausch page (the author of the book itself ). I was surprised to find that he was recruiting students for his course. The time was perfect: University of Virginia, autumn 1991, CS461 Analysis of algorithms and 50 students on the course. I was one of them.
And without doubt I was impressed with this course. Paush was such a brilliant and charismatic teacher that you understand the meaning of the old adage that you first need to choose a teacher, and then what to teach, if you have to make that choice. It so strongly reflects reality.
')
And so a combination of a great teacher and a theme did their job, because algorithms are one of the most important parts of programming, if not the most. Not that we invent new algorithms, but we had to understand the code of the existing ones, estimate the speed of their execution with various input data and determine the correct algorithm for our task. These were the objectives of our course.
And one of the coolest things that Randy Paush taught us was the need to ask yourself the following question before choosing an algorithm:
It is clear that God would not choose bubble sorting, quick sorting or shell sorting, as we are mortals, when sorting the list. He would just immediately put all the objects in the correct order. In one step. The lower bound of the execution time would be O (1). Not a specific time, but just one step. In one moment. After all, you are God.
Similar thoughts blew my mind at the time.
I always suspected that people become real programmers because they need to play the role of god. Randy Pausch took this concept and clearly showed how to set the boundaries of the task with the help of it and ask yourself difficult questions about what you are doing and why.
That is why, when we made the authentication window for Discourse , I went back to what I was studying in this course and asked myself one question:
And the answer, of course, is obvious - God would not bother with the development of this window. What for? He is God, and once registered in his application, he will always understand who you are.
This is for obvious reasons an impossible task for us, because God is not one of our investors.
But how close can we get to implementing a divine approach to authentication? This is definitely a noble and worthwhile goal.
Didn’t Bill Gates once ask why each programmer writes the same window to select files again and again? This question can be attributed to authentication. What for? I’ve been saying for a long time that the best authentication window is its complete absence and I absolutely support the idea of authentication with the help of your network drivers in any situation where this is possible. Therefore, our team is fully in solidarity with you, if you implement the ability to log into your resource through other services.
But today I would like to focus your attention on the most important way to authenticate: username (further login) and password. This is the main way to hit the site until you have implemented other methods.
The authentication form with two fields, two buttons and a link looks quite simple, right? This is the standard. True, until the user has trouble logging in. Let's think about it.
OpenID's critical error, despite the fact that I really liked the service, as a way to access the site, was that they assumed that users could use the URL as an identifier. This strange and wrong decision was the reason in the long term that OpenID did not become the future standard.
The user ID at the entrance can only be email. Simple and clear. What happens when you forget your password? You use mail to restore it, right? She is your ID. Some people even suggest making it the only authentication method .
Having a unique username is, of course, good, but always let users choose how to access the site: either through email or using a unique name. I tell you this because I can say with 100% probability that when users forget a password, then in any case they will have to use mail to reset or restore it. Mail and password are strongly related concepts that are always used together. Is always!
(And I want to express my fu with those services that do not allow me to use my mail as a unique identifier. I am following you.)
Well, now we know that de facto mail is the identification standard for most people and this is the logical and necessary state of affairs. But which of my many emails should I use on your website?
This caused a lot of discussion on Discourse about whether or not to show personal data of other users when they enter mail in the form of password recovery. On many of the site after entering the mail in the password recovery form you will see the following message:
The key word in this question is if, which completely excludes the possibility of disclosing personal data of resource users .
We take these things seriously when developing Discourse and therefore disclosing your mail data to unauthorized persons does not threaten you. But after many users trying to guess their emails get the notification “Which email do you enter this time?”, We came to the conclusion that in certain cases user-friendly interface is much more important than security.
Therefore, it was decided to show mail in notifications, which does not exist in our service. This solution is both completely safe and user friendly. If you wish, you can prohibit such manipulations with your mail in the settings of our service.
Very many sites show login and registration buttons next to each other. It puzzled me, because the authentication and registration processes are completely different things.
Well, from the user's point of view, this may not be entirely true. The login form on the site of the well-known magazine The Verge shows how close the login and registration forms can be.
We recognize the presence of a certain similarity between these processes and therefore we made both forms available at the same time by implementing them through switches.
Both of these forms are implemented through a pop-up window and can be easily removed from the screen or shown again when you press the login or registration buttons.
This is a big language problem. We have a lot of words for the same things:
Which of these words is the most appropriate? The results of the study of user data and their (user) behavior can also be interpreted incorrectly and lead to further errors.
I prefer to use the shortest words whenever possible, because I am a fan of brevity and brevity. But these things very often depend on circumstances and user preferences .
Sign in (Log in or Log In) is found most often and is more intuitively suitable for our task, although Log in (Authentication) has a historically established and specific meaning inherent in computer systems and therefore this word is also valuable.
Each form of authentication that you create must be compatible and workable with the password managers of popular browsers, such as:
This is a necessary minimum. In a subsequent attempt to authenticate in one of the browsers, you will see the user ID and password fields filled in.
Users rely on these things built into the browser, things and any authentication implementation must respect this fact and be implemented with its account. For example, in the HTML code, the password field should have the following attribute: type = password and a name that identifies this field as a field for entering a password.
There are also a lot of third-party password managers, such as LastPass , but mostly you should focus on working with the embedded managers of popular browsers. If your form works with them, it is most likely that it will work with third-party managers.
Is the user typing his password with Caps Lock? Warn him about it.
Did he enter his mail using name@gmail.co instead of name@gmail.com? Or maybe instead of name@hotmail.com he wrote name@hotmail.cm? You should also correct these errors and warn the user about it.
(I am also a big fan of password peeping function , because with it, the user can make sure he entered the password correctly or not. Only Internet Explorer and I think Safari support this function, but in my opinion, the rest should support it too.)
There are many methods that teach the correctunreliable passwords that are not difficult to pronounce and difficult to use, such as password123, Iloveyou, and so on .
There is a simple method for measuring the reliability of a password while entering it. And we recommend that you apply it.
This is a good idea, but on some sites it looks intrusive. Realization of this also leaves much to be desired, since the service itself determines the criteria for password security. On one site, the password can be secure, but on the other with it they will not even be allowed on the threshold.
Therefore, with Discourse we decided to do otherwise. We have made the minimum password length equal to 8 characters and from its hash we determine whether it is included in the 10,000 most popular passwords in the world .
Users who use the keyboard to interact with the site are dying out, but for those of them who are still alive, it is still necessary to make it possible to navigate through the elements of the form using the keyboard.
And please make sure it works the way it was intended.
You must limit the number of user attempts to perform any possible actions on your site. This is especially true form of authentication.
If someone has forgotten your password and made 3 attempts to log in or recover the password, then this is normal. But if someone did it 1000 times, then this is rather strange. I even venture to suggest that this is not a man.
You can do funny things like temporarily blocking your account or demonstrating captcha if they failed multiple login attempts. But don't get too carried away with things like that, because they can end in tears.
I believe that it is good practice to use standard pauses with a moderately increasing interval for attempts to enter or recover a password from the same IP address. And we did on our website.
I tried to remember everything that we went through when designing our ideal form for a Discourse , but I am sure that we forgot something or did not tell something in sufficient detail. Our project Discourse is 100% open and constantly evolving . You can look at its implementation at any time and test it.
The authentication window just contains a simple form with two fields, a link and two buttons. And yet, after reading all that was written above, I think you will agree that this simplicity is deceptive. Your best solution is not to develop a form of authentication from scratch, but to rely on third-party authentication sources whenever possible.
This article is a translation. The original article can be found at this link.
One of my favorite subjects, at least he remembered most of all for me, was “Algorithms”. I always tell the people who ask me about this, that this subject influenced my development, as a programmer, the most. I don’t know exactly why, but a few years ago I had a strange presentiment, and for some reason I went to the Randy Pausch page (the author of the book itself ). I was surprised to find that he was recruiting students for his course. The time was perfect: University of Virginia, autumn 1991, CS461 Analysis of algorithms and 50 students on the course. I was one of them.
And without doubt I was impressed with this course. Paush was such a brilliant and charismatic teacher that you understand the meaning of the old adage that you first need to choose a teacher, and then what to teach, if you have to make that choice. It so strongly reflects reality.
')
And so a combination of a great teacher and a theme did their job, because algorithms are one of the most important parts of programming, if not the most. Not that we invent new algorithms, but we had to understand the code of the existing ones, estimate the speed of their execution with various input data and determine the correct algorithm for our task. These were the objectives of our course.
And one of the coolest things that Randy Paush taught us was the need to ask yourself the following question before choosing an algorithm:
What algorithm would God choose?
It is clear that God would not choose bubble sorting, quick sorting or shell sorting, as we are mortals, when sorting the list. He would just immediately put all the objects in the correct order. In one step. The lower bound of the execution time would be O (1). Not a specific time, but just one step. In one moment. After all, you are God.
Similar thoughts blew my mind at the time.
I always suspected that people become real programmers because they need to play the role of god. Randy Pausch took this concept and clearly showed how to set the boundaries of the task with the help of it and ask yourself difficult questions about what you are doing and why.
That is why, when we made the authentication window for Discourse , I went back to what I was studying in this course and asked myself one question:
How would God realize this window?
And the answer, of course, is obvious - God would not bother with the development of this window. What for? He is God, and once registered in his application, he will always understand who you are.
This is for obvious reasons an impossible task for us, because God is not one of our investors.
But how close can we get to implementing a divine approach to authentication? This is definitely a noble and worthwhile goal.
Didn’t Bill Gates once ask why each programmer writes the same window to select files again and again? This question can be attributed to authentication. What for? I’ve been saying for a long time that the best authentication window is its complete absence and I absolutely support the idea of authentication with the help of your network drivers in any situation where this is possible. Therefore, our team is fully in solidarity with you, if you implement the ability to log into your resource through other services.
But today I would like to focus your attention on the most important way to authenticate: username (further login) and password. This is the main way to hit the site until you have implemented other methods.
The authentication form with two fields, two buttons and a link looks quite simple, right? This is the standard. True, until the user has trouble logging in. Let's think about it.
Give the user the ability to log in with mail
OpenID's critical error, despite the fact that I really liked the service, as a way to access the site, was that they assumed that users could use the URL as an identifier. This strange and wrong decision was the reason in the long term that OpenID did not become the future standard.
The user ID at the entrance can only be email. Simple and clear. What happens when you forget your password? You use mail to restore it, right? She is your ID. Some people even suggest making it the only authentication method .
Having a unique username is, of course, good, but always let users choose how to access the site: either through email or using a unique name. I tell you this because I can say with 100% probability that when users forget a password, then in any case they will have to use mail to reset or restore it. Mail and password are strongly related concepts that are always used together. Is always!
(And I want to express my fu with those services that do not allow me to use my mail as a unique identifier. I am following you.)
Tell the user about when the account with his mail does not exist
Well, now we know that de facto mail is the identification standard for most people and this is the logical and necessary state of affairs. But which of my many emails should I use on your website?
This caused a lot of discussion on Discourse about whether or not to show personal data of other users when they enter mail in the form of password recovery. On many of the site after entering the mail in the password recovery form you will see the following message:
If an account with this address exists, then instructions for resetting the password have been sent to your email.
The key word in this question is if, which completely excludes the possibility of disclosing personal data of resource users .
We take these things seriously when developing Discourse and therefore disclosing your mail data to unauthorized persons does not threaten you. But after many users trying to guess their emails get the notification “Which email do you enter this time?”, We came to the conclusion that in certain cases user-friendly interface is much more important than security.
Therefore, it was decided to show mail in notifications, which does not exist in our service. This solution is both completely safe and user friendly. If you wish, you can prohibit such manipulations with your mail in the settings of our service.
Allow users to switch between the Login and Register forms at any time they want
Very many sites show login and registration buttons next to each other. It puzzled me, because the authentication and registration processes are completely different things.
Well, from the user's point of view, this may not be entirely true. The login form on the site of the well-known magazine The Verge shows how close the login and registration forms can be.
We recognize the presence of a certain similarity between these processes and therefore we made both forms available at the same time by implementing them through switches.
Both of these forms are implemented through a pop-up window and can be easily removed from the screen or shown again when you press the login or registration buttons.
Choose simple words
This is a big language problem. We have a lot of words for the same things:
- Sign in (Login or Login)
- Log in (Authentication)
- Sign up (Subscribe)
- Register
- Join [site] (Join)
- Create account (Create an account or create an account)
- Get Started (Get Started)
- Subscribe (Subscribe. But in most cases means paid subscription)
Which of these words is the most appropriate? The results of the study of user data and their (user) behavior can also be interpreted incorrectly and lead to further errors.
I prefer to use the shortest words whenever possible, because I am a fan of brevity and brevity. But these things very often depend on circumstances and user preferences .
Sign in (Log in or Log In) is found most often and is more intuitively suitable for our task, although Log in (Authentication) has a historically established and specific meaning inherent in computer systems and therefore this word is also valuable.
A couple of years ago I did a survey of the most popular sites in the United States and Britain about what words they use. I have noticed that the amount of use of Sign in (Log) prevails and is constantly increasing. And this is especially noticeable on popular sites.
Work with password managers of popular browsers.
Each form of authentication that you create must be compatible and workable with the password managers of popular browsers, such as:
This is a necessary minimum. In a subsequent attempt to authenticate in one of the browsers, you will see the user ID and password fields filled in.
Users rely on these things built into the browser, things and any authentication implementation must respect this fact and be implemented with its account. For example, in the HTML code, the password field should have the following attribute: type = password and a name that identifies this field as a field for entering a password.
There are also a lot of third-party password managers, such as LastPass , but mostly you should focus on working with the embedded managers of popular browsers. If your form works with them, it is most likely that it will work with third-party managers.
Handle the most common user errors
Is the user typing his password with Caps Lock? Warn him about it.
Did he enter his mail using name@gmail.co instead of name@gmail.com? Or maybe instead of name@hotmail.com he wrote name@hotmail.cm? You should also correct these errors and warn the user about it.
(I am also a big fan of password peeping function , because with it, the user can make sure he entered the password correctly or not. Only Internet Explorer and I think Safari support this function, but in my opinion, the rest should support it too.)
Help users choose the right password
There are many methods that teach the correct
There is a simple method for measuring the reliability of a password while entering it. And we recommend that you apply it.
This is a good idea, but on some sites it looks intrusive. Realization of this also leaves much to be desired, since the service itself determines the criteria for password security. On one site, the password can be secure, but on the other with it they will not even be allowed on the threshold.
Therefore, with Discourse we decided to do otherwise. We have made the minimum password length equal to 8 characters and from its hash we determine whether it is included in the 10,000 most popular passwords in the world .
Do not forget about the keyboard
Users who use the keyboard to interact with the site are dying out, but for those of them who are still alive, it is still necessary to make it possible to navigate through the elements of the form using the keyboard.
And please make sure it works the way it was intended.
Limit the number of attempts for all possible actions.
You must limit the number of user attempts to perform any possible actions on your site. This is especially true form of authentication.
If someone has forgotten your password and made 3 attempts to log in or recover the password, then this is normal. But if someone did it 1000 times, then this is rather strange. I even venture to suggest that this is not a man.
You can do funny things like temporarily blocking your account or demonstrating captcha if they failed multiple login attempts. But don't get too carried away with things like that, because they can end in tears.
I believe that it is good practice to use standard pauses with a moderately increasing interval for attempts to enter or recover a password from the same IP address. And we did on our website.
Things I forgot to mention
I tried to remember everything that we went through when designing our ideal form for a Discourse , but I am sure that we forgot something or did not tell something in sufficient detail. Our project Discourse is 100% open and constantly evolving . You can look at its implementation at any time and test it.
The authentication window just contains a simple form with two fields, a link and two buttons. And yet, after reading all that was written above, I think you will agree that this simplicity is deceptive. Your best solution is not to develop a form of authentication from scratch, but to rely on third-party authentication sources whenever possible.
This article is a translation. The original article can be found at this link.
Source: https://habr.com/ru/post/248427/
All Articles