20 ways to test the login function

1) Correct combination of username and password
The most basic test is a correct combination of username and password, everybody knows the expected result. But once it will happen that even a good combination doesn’t work. Possibly caused by a miss configuration of the application.

2) Incorrect combination of username en password
For example a correct username and a wrong password. Or use a password that exists in the database but is linked to another user. If the combination is wrong, most of the times you don’t have access to the application behind the login function/page and you get an error message.

3) Correct username and empty password
Most of the applications are coded in a way that you don’t have access to the application with this test case. But in some situations“something unexpected went wrong please check the error log”

4) Correct password and empty username
In this case you could expect the same result as in the test case before. And this is true most the time and where a lot of (functional) testers will stop. Because the application fulfills the expectations that are given by the functional design and/or requirements. But there is much more. There are more risks and more opportunities to enter the application; even without logging in.

5) Check the meaning and information in the error
Information and information leakage is food for hackers. Specific error and stack traces are full of information that can be misused by hacker. There are three possibilities of errors that can occur if you have an incorrect login.

• Incorrect combination of username and password
• Incorrect username
• Incorrect password

Only the first one is correct. The second and third are useful from the usability perspective but gives an evil one too much information. Because if you get the messagepassword is incorrectyou know already half the access code.

8 ) Correct login, logout and go back with the browser button
If a session isn’t closed at the servers end and you go back with the <BACK> browser button, sometimes you can go on with the session you created earlier in the process. This means the logout function isn’t functioning correctly. What can happen?

For example in an internet café: if people start directly after somebody is ready and they go back they can access your personal data. Think about email functions that are on social network sites. If they change your password in a password you don’t know they can do what ever they want. They can see which registration emails from other companies thyere are in your inbox and ask for a new password

Tip: if you’re using internet at a public computer be sure what you’re doing and always close the browser after surfing on the internet.

9) Go directly to a page without use of the login function
Maybe this test case is a little bit strange but it will work many times. What to do: Login with a correct combination of username and password. Go to a specific page behind the login functions that requires the login. Copy and paste the URL and logout. Now you start the test and you paste the address in the URL field (without using the login page). If you go directly to this page without logging in, the owner of the application has a big problem and also all the users that have an account. Everybody that knows the direct URL can have access.

10) Check the sustainability of the session
What time is needed to do business in an online shop? 2 hours without any actions at a site? 2 days? 2 months? I know some webmail clients whereby the session is valid for many years. This is not an issue people can misuse directly, but in combination with other vulnerabilities they can misuse it easily. Therefore log in with a valid account, go away drink a coffee, a beer and have a sleep. If you come back and the session is still valid (when you can use it without a new login) you have an issue!

Tip: In my opinion  more than 20 minutes without any actions at a specific site should lead to a new session.
<added later: this 20 minutes is based on experience. For a better theory see the comment below of Danil>

11) Check if the login function is already HTTPS
The ‘S’ from HTTPS stands for Secure. This means the message is encrypted during transport. If the login page is HTTP and the conversation after login is HTTPS the first step is unsecure. Because the message is in plain text the first request to the server.

The login page (before you fill the fields with your credentials) must be HTTPS.

12) Change the ID into an ID of another account
If you’re browsing through an application and you see in the header or in the URL an ID that is directly related to your bank ID, personal ID username or anything else, try to change is in someone else. This is also possible a lot. A couple of months back a colleague of mine tested a banking application where this happened. If he wanted he could use every account that client had for transferring money and much more. To test this login a couple of times and check of if the ID is static (each time the same) if this happens you can try this test case and maybe it works fine (thus wrong)!

13) Copy the ID and past this in another browser
If you can go on with the session in a new browser you have also a big problem. People that steal you session can go on with this doing a lot of things you don’t like. With another browser I mean really on another browser and not only on other tab in your current browser. The best way to test this is sending it to another computer and go on with this session (don’t shut down the session in the first browser before the second one is open).

14) Delete the ID and continue browsing
Does they ID in the cookie or URL really has value in the conversation between your client and the server? Delete step by step all ID`s and continue browsing. Check which ID has really value. Hopefully this is not you account number of banking number. Because if this is true you can execute another test, changing the number.

15) Check the possibility of SQL-Injection
Sometimes everything works fine and all requirements are in place. But what is SQL-injection is possible and you can enter the application using a statement to login? Try in the application under test a single quote or1’ or ‘1’=’1.If this becomes code instead of simple data at the background and the database execute this it happen sometimes you can login in. There are a lot more SQL-Injection possibilities. Search at the web for more differences.

16) Multiple times incorrect password
Locking accounts after 3 or 10 times a incorrect combination isn`t true or false. What more important is, is the requirement described in the functional or technical design? Because the choice of an account lock after 3 incorrect attempts isn`t true or false. But you have to know the consequences.

An application where a lock of account doesn’t occur  is capable for a brute force attack. This is an attack where hackers try to guess your username or password. They use a tool that systematically try all options.

In case an account lock another problem  occurs. This is a lockout. If a account isn`t available after three times a incorrect login you can`t use it anymore until you call the helpdesk, or start the procedure to get a new password. With this lockout you can make complete companies unavailable.

Locking account or not isn`t true or false but make the choice between them bases on the risk and mitigation you can take.

18) Login in two different browsers with the same account
Have you ever tried this in your application under test? Sometimes it happens that the conversation with the first one is broken, ore that action executed in the first are displayed in the second. This means most of the time you have one session (the same) at the server instead of two. Because you set up to different connections.
Most of the time does this mean that the procedure to set up a connection doesn’t work correct.

*****

Password policy