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.
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.
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.
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.
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.
Passwords are caclulated with pbkdf2_hmac, using a sha256 hash, a 16 byte salt generated with urandom() and 100000 iterations.
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.
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.
... to be determined ... We have not yet implemented any options to change user profile information.
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.
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.
We have as of yet not implemented lok out nor any other mechanism to defend against automated attacks.
... to be determined ...
... to be determined ...
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.