Adding a graphical user interface 2 – Creating a Secure Login and Signup Process for Web Applications

As we know, there is no way to decode a hashing. This means that once we convert the password into a hash, we cannot convert it back again. So, to complete the authentication/login of a user, we must type the password into text_input, convert it into its hashing, and compare the result with the hashing stored in the database. If the two hash codes are the same, this means that the inputted password is correct; otherwise, it is different from the saved one.

Implementing this procedure requires us to make a few modifications to our code:

1. First, we must convert the inputted password into a hashing. This can be done using the make_hashes function we just discussed.
2. Then, we need to compare this hashing with the one saved in the database.

The first code change affects the Login section, as shown in the following figure:

Figure 13.18: The hashing of the inputted password

Here’s what we are doing in the preceding code:

• On line 60, we make a hash of the inputted password.
• On line 61, leveraging the check_hashes function, we compare the hashed password with the one (with the hashing) saved in the database. If they are the same, then the login process is successful.

Let’s write the check_hashes function; the code is very short, as shown in the following figure:

Figure 13.19: The “check_hashes” function

Here’s what we are doing in the preceding code:

• On line 15, we define the new function, which has only two arguments: a password (clear text) and the hashed text (the hashing of the password saved in the database).
• On line 16, we can see that if the hashing of the password (which we get using the make_hashes function) is the same as the one stored in the database, we return the hashed text (the hashed version of the password); otherwise, we return False.

So, moving back to line 61 of the code shown in Figure 13.18, when check_hashes returns the hashed password, the result variable is True and the code enters the success part of the if cycle. Otherwise, when check_hashes returns False, the result variable is False as well, and the code enters in the else part of the if cycle, denying the login.

Now, if we try to log into the web application using the account we saved previously (user1, 12345), we’ll fail and get a warning. The reason is that in our database, we saved the password without introducing the hashing, so the password is stored in clear text.

To complete all the login/signup web application coding, we must change the SignUp section a little bit, making sure that the passwords of the accounts are saved in their own hashing version:

Figure 13.20: The final “SignUp” section