8.1 Developing User Accounts

In this chapter, we will build on the example from Chapters 5 and 6, by introducing HR admins who get to see and add employees and their pay grades. Assume there are admins responsible to do those actions, and the company keeps changing and assigning new admins. In this case, we need our application to support making more admin accounts and authorize them.

Now those actions need authorized people to execute them, so we mainly need three main additions: adding an admin table in our database, allowing admin account creations, and authorizing users with admin accounts to use the rest of the service.

8.1.1 Hashing

To add a new table to the database, we will need to follow a step similar to what was done previously and as shown in Figure 8-1. Notice that we are storing mainly two pieces of information per admin, username and password hash. The hash or a nonguessable representation of the password is stored instead of the password itself. By doing this, we are protecting our users’ privacy and credentials in case of a data breach. As if this happens, the attacker will have to spend billions of years to brute-force all hashes to find a single user’s actual password. So what hashing mainly does is a one-way transformation of data that is not reversible.

After creating the new table, we will need to create a corresponding Python class to make an ORM for SQLAlchemy as shown in Listing 8-1. Hashing a password can be done in multiple ways, a few of which can be MD5, SHA256, SHA512, and others. However, the most commonly used algorithm by modern systems is Bcrypt. Infact Bcrypt is used by default to protect users’ passwords in Linux environments. Before explaining how Bcrypt works, we first need to know what methods are used to make a hash more secure.

As mentioned before, hashing transforms data. So, for instance, the text

Password123

maps to

42f749ade7f9e195bf475f37a44cafcb

using MD5. However, a slight modification to the original plain text would make a bigger difference in the hashed output as such:

MD5(Password1239) -> abd7fdbb048a611ea0a0937265765404

8.2 Verifying User Credentials

Now after we have the needed service and storage support to manage passwords, we can proceed with the backend refactoring to support authentication for every route. This means we need to intercept every request to the server and decide whether it is authenticated or not. In other words, we need to have an independent piece of software to sit between the client’s request and the access controller; this is usually referred to as middleware among backend developers. The authentication process has to be checking for a specific identifier of the request that the server can trust; such identifier is referred to as “authentication token,” or “token” for short. This token shall be issued by the server, and it shall be verified.

Tokens are mainly either of the two: custom session IDs or JWTs. For this example, we will proceed with JWTs as it doesn’t require the server to store it, which makes it stateless. JWTs consist of three main parts encoded in base64 and separated by a period. The first part contains information about the payload signing mechanism, the second holds the raw payload, and lastly the third contains a password-protected signature of the payload using the same hashing mechanisms in the first part. This can be seen in more detail in Figure 8-2 from jwt.io.

Finally, we need to initialize the previously made services and make three more routes for logging in, signing up, and checking login status. We need the last route to allow the frontend to make the decision whether to display the login page or not. So the server’s main file shall look like Listing 8-5. We can notice that secrets and keys are read from an external YAML file and then parsed. One of those secrets is to make sure only who knows it can make new accounts as shown in Figures 8-3 and 8-4 using Postman.

from flask import Flask, request

from DataBase import Connection, Employees, Admins

from Services import JWTService, HashingService

from Middleware import Middleware

from werkzeug import exceptions

import yaml

app = Flask(__name__)

with open("secrets.yaml") as f:

    yaml_dict = yaml.safe_load(f)

    sing_up_key = yaml_dict['sing_up_key']

    jwt_secret = yaml_dict['jwt_secret']

jwt_service = JWTService(jwt_secret)

middleware = Middleware(jwt_service)

hashing_service = HashingService()

app.before_request(lambda: middleware.auth(request))

@app.route('/api/employees')

def get_all_employees():

    with connection.use_session() as session:

        employees = session.query(Employees).all()

        employees = [employee.to_dict() for employee in employees]

        return {"data": employees}

@app.route('/api/employee', methods=["POST"])

def add_employee():

    body = request.json

    with connection.use_session() as session:

        session.add(Employees(**body))

        session.commit()

    return {"message": "New employee added successfully"}

@app.route('/api/auth/login', methods=["POST"])

def log_in():

    username, password = request.json['username'], request.json['password']

    with connection.use_session() as session:

        admin_account = session.query(Admins).filter(

            Admins.username == username).first()

        if admin_account is None:

            # Username doesn't exist. But don't inform the client with that as

            # they can use it to bruteforce valid usernames

            return exceptions.Unauthorized(

                description="Incorrect username/password combination")

        # Checking if such hash can be generated from that password

        is_password_correct = hashing_service.check_bcrypt(

            password.encode("utf8"), admin_account.password_hash.encode("utf8"))

        if not is_password_correct:

            return exceptions.Unauthorized(

                description="Incorrect username/password combination")

        token_payload = {"username": username}

        token = jwt_service.generate(token_payload)

        if token is None:

            return exceptions.InternalServerError(description="Login failed")

        return {"token": token}

@app.route('/api/auth/sing_up', methods=["POST"])

def sign_up():

    username, password = request.json['username'], request.json['password']

    if request.headers.get("sing_up_key") != "sing_up_key":

        exceptions.Unauthorized(description="Incorrect Key")

    with connection.use_session() as session:

        password_hash = hashing_service.hash_bcrypt(

            password.encode("utf-8")).decode("utf-8")

        admin = Admins(username=username, password_hash=password_hash)

        session.add(admin)

        session.commit()

        return {"message": "Admin account created successfully"}

@app.route('/api/auth/is_logged_in')

def is_logged_in():

    # If this controller is reached this means the

    # Auth middleware recognizes the passed token

    return {"message": "Token is valid"}

connection = Connection("postgresql://postgres:[email protected]:5432/CompanyData")

app.run()

Listing 8-5

Flask/flask_main.py

After creating the account, we can manually check the database if the new credentials are present. This can be verified in Figure 8-5, where the username is as supplied and the other column is a valid Bcrypt hash for the supplied password.

Now as we have admin accounts ready, we can test logging in with Postman before moving on to the next steps. By inserting the same username and password used in signing up, in a JSON format to a POST of the responsible route, we get a token back as seen in Figure 8-6.

Having our API adapted to authentication tokens as shown in Listing 8-7, we can take it to the actual frontend side by implementing cookie support to store the authentication tokens and use it wherever needed as shown in Listing 8-8. Whenever the Streamlit renders, it will check the local cookies and look for authentication tokens; if the token is valid, it will display the management portal as shown in Figure 8-8 with a customized welcome message. Otherwise, it will prompt for an obligatory login, which can be seen in Figure 8-7.

import requests

class API:

    def __init__(self, base_url: str, token: str):

        self.base_url = base_url

        self.base_headers = {"token": token}

    def add_employee(self, name, dob, paygrade):

        try:

            data = {

                "name": name,

                "date_of_birth": dob,

                "paygrade_id": paygrade

            }

            response = requests.post(self.base_url + "/employee", json=data, headers=self.base_headers)

            if response.status_code == 200:

                return True

        except:

            return False

    def get_employees(self):

        try:

            response = requests.get(self.base_url + "/employees", headers=self.base_headers)

            return response.json()['data']

        except:

            return None

    def login(self, username, password):

        try:

            response = requests.post(self.base_url + "/auth/login", json={

                "username": username,

                "password": password

            })

            body = response.json()

            token = body.get("token") if type(body) == dict else None

            return token

        except:

            return None

    def is_logged_in(self):

        return requests.get(self.base_url + "/auth/is_logged_in", headers=self.base_headers).status_code == 200

Listing 8-7

Streamlit/API.py

import streamlit as st

from Views import AddEmployee, DisplayEmployees, Login

from API import API

import extra_streamlit_components as stx

import base64, json

cookie_manager = stx.CookieManager()

cookies = cookie_manager.get_all()

authentication_token = cookies.get("token")

    if type(cookies) == dict else cookies

api = API("http://127.0.0.1:5000/api", authentication_token)

def get_username_from_token(auth_token):

    b64 = str(auth_token).split(".")[1]

    b64 = b64 + "=" * (4 - (len(b64) % 4))

    data = base64.b64decode(b64).decode("utf8")

    username = json.loads(data)[’username’]

    return username

    def manage_login(username, password):

        token = api.login(username, password)

        cookie_manager.set("token", token)

        return token is not None

    st.title("Company Management Portal")

    if api.is_logged_in():

        st.subheader(f"_Welcome "

                     f"**{get_username_from_token(authentication_token)}**_")

        st.write("_____")

        AddEmployee(api.add_employee)

        st.write("___")

        DisplayEmployees(api.get_employees)

    else:

        Login(manage_login)

Listing 8-8

Streamlit/streamlit_main.py

8.3 Secrets Management

8.4 Anti-SQL Injection Measures with SQLAlchemy

As a final code implemented protection, we aim to protect the backend’s SQL queries by preventing a nonintended action to happen. First, we need to identify what a SQL injection is. It is mostly when a user-controlled text changes the SQL command behavior. For instance, assume we want to support searching for employees starting with a string of character to be input by the end user; it will result in a final query as such: SELECT * FROM Employees WHERE name = 'input%'. This poses a threat if the input was OR 1=1 -- as it would result in a final query of SELECT * FROM Employees WHERE name = '%' OR 1=1 -- which orders the database to select all employees, instead of treating the input as the search string.

To overcome this problem, we need to use parameterization which is a technique to isolate the original SQL command from the changing variables. So, for the example from before, it would rather look something like SELECT * FROM Employees WHERE name = '@name%' where @name is a SQL variable initialized before submitting the query. As a developer, this might be an overhead toward a more secure SQL. Thus, we use libraries and/or packages to do this on our behalf. For this scenario, we are using SQLAlchemy, which is a library that can connect to many types of databases and change SQL command formats depending on the architecture, origin, and version, all by following an intuitive API that is documented in docs.​sqlalchemy.​org.

8.5 Configuring Gitignore Variables

Having all files tracked with a version control system like Git is a must for big projects, as it adds more simplicity in managing what files are important and their modification history. However, not all files must be tracked, and some will pose security threats if tracked, as the code base can be accessed by anyone if it is public, or broken into if it is private. This makes the secrets managed under threat; hence, it is widely agreed among software developers to not track the secrets file and store the actual secrets in a security vault, which is accessible using multiple methods of authentication.

8.6 Summary

As part of making any web application public, you are required to manage resources served, by verifying each and every user’s authorization level. In this chapter, we have explained how to create and manage user accounts and how to utilize them for authentication. We introduced essential application security mechanisms such as generating JSON Web Tokens, hashing passwords, and embedding secure signatures into cookies. In addition, this chapter showcased techniques to obstruct SQL injection attacks to prevent unauthorized access to databases. Finally, we observed how application keys and secrets can be secured during deployment, and also how they can be excluded from being committed toa version control framework such as Git.