Home page Wiki Blog Code Projects

Docker playground

Creating a general docker based web application with a mixed technology stack

Authentication: the OWASPP cheatsheet

Content is a work in progress

The aim of this article is to check the implementation of the authserver against the best practices of the OWAPS Authentication cheat sheet

We will examine each of the sections one by one, the section headers contain links to the entry on the OWASP page.

User IDs

We use email addresses as user names and we make sure that all email addresses are converted to lowercase before any processing takes place. This lowercasing uses Python's lower() function which is unicode aware. Also on the database level email addresses are stored with 'nocase' collation.

Authentication Solution and Sensitive Accounts

We have a "superuser" account that can access an overview of user data and sessions. This user cannot change this data however and the database user is a different entity. But because this does have access to user data, better access control should probably applied to this super user. Two factor authentication or a client certificate are worth considering here.

Implement Proper Password Strength Controls

We force passwords to be between 8 and 64 characters long and have enough complexity: there should be at least 1 character from each of these categories: lower case, upper case, digits, special. We also do not restrict any character to be used in a password.

Implement Secure Password Recovery Mechanism

We allow users to reset their password if they forgot it and it uses one time cryptographically secure tokens that are expired and send via a side channel (email) but we need to scrutinize this a bit more.

Store Passwords in a Secure Fashion

Passwords are caclulated with pbkdf2_hmac, using a sha256 hash, a 16 byte salt generated with urandom() and 100000 iterations.

Compare Password Hashes Using Safe Functions

Passwords, or rather their hashes are compared using the hmac.compare_digest() function. The limit denial of service by very long passwords the input of POST requests are always explicitely checked against a preset length. This is true for all parameters.

Transmit Passwords Only Over TLS or Other Strong Transport

Authserver itself is scheme agnostic, i.e. we are not concerned with the HTTP protocol used. However the complete solution is configured to run behind a Traefik reverse proxy that enforces TLS for everything.

Require Re-authentication for Sensitive Features

... to be determined ... We have not yet implemented any options to change user profile information.

Consider Strong Transaction Authentication

As discussed, this might be worthwhile for the super user but not necessarily for applications with less sensitive data, so this is currently not considered for implementation.

Authentication and Error Messages

We do return generic information that does not indicate the reason why a login or password reset, etc. fails and on top of a secure digest compare method to mitigate timing attacks, we added code to equalize timing for timing sensitive routines.

Protect Against Automated Attacks

We have as of yet not implemented lok out nor any other mechanism to defend against automated attacks.

Logging and Monitoring

... to be determined ...

Use of authentication protocols that require no password

... to be determined ...

Password Managers

Authserver itself does not provide the HTML forms that present the user a login form, it just provides the POST actions to perform the actual authentication. However, the forms presented by the other components of Dockerplayground to not prevent the use of password managers in any way.