Mach SSO

Mach SSO is a simple single sign-on solution built for MachTarok.com and similar custom applications. Like all projects I have created, Mach SSO was programmed from the ground up, with almost no libraries or tools used.

Mach SSO was programmed with a few main concepts in mind:

• Security
• Ease of use
• Manageability

The top priority, of course, is security. For this reason, Mach SSO has an extremely strict Content-Security Policy (CSP), can only be accessed via HTTPS, and only allows users to access necessary files. Additionally, all passwords are stored in OWASP-recommended Argon2 hashes in a secure, locally hosted, MariaDB database. Altogether, the extreme security and redundant protections mean that any passwords inserted by the users are safe from all prying eyes.

Ease of use is also a high priority, as a difficult SSO is an unused SSO. For this, I made the client side as simplistic as possible with nothing but a few text boxes and submit buttons.

Finally, manageability. This was easily handled and can be easily improved upon by use of MariaDB. Any user's account can be deactivated or deleted through MariaDB. This does not sacrifice security because the MariaDB password must be known and the user must be on the server computer and locally accessing MariaDB to gain access.

MariaDB

The Mach SSO server acts as a middleman between the clients and the password database. To achieve this, I used the MariaDB NodeJS connector plugin. The MariaDB stores only limited information, including a username and password for each user, but can be easily expanded for one time passwords and other security measures. For additional security, the MariaDB connector plugin user only has the necessary rights to manage the server and cannot access unnecessary items. Effectively, this means that in the unlikely event of an SQL injection surviving my other precautions, the attacker could not delete the database or overwrite other users.

HTTP Communication

Between the Mach SSO server and the client, the communication method must be guaranteed secure and reliable. Because of this, I used simple HTTP communication (SSL secured, of course). All username and password submissions are sent via HTTP and the result is promptly returned the same way. With this style of communication, the client and server can communicate effectively without need for any additional third-party plugins which might prove vulnerable to attack.

Client and Integration

An SSO is only as good as what it signs on to. For Mach SSO, it signs on to Mach Tarok, seamlessly and efficiently. There are two parts to the integration: client and server. The client must sign in using Mach SSO, and the Mach Tarok server must verify the token. For the integration, I used JavaScript message events and HTTPS requests.

JavaScript message events must be verified by both sides of the message. For Mach SSO, this is achieved by using a list of whitelisted domains (machtarok.com) and only sending messages to websites with those domains. For Mach Tarok, the message must come from Mach SSO and is verified in the same way. This means that no third party can perform a Man-in-the-Middle (MitM) message interception attack. To further reduce message frequency, the Username and Token are then stored in secure cookies by Mach Tarok. This allows users to reload the page without having to sign in again.

The clients must send the tokens to the Mach Tarok server for verification. The Mach Tarok server then requests Mach SSO to verify the validity of the tokens. Upon receiving an OK, Mach Tarok then verifies the user and the sign-in process is complete. This final action is done using NodeJS HTTPS requests.

Tags: JavaScript, HTML, CSS, Bootstrap, Client, Server, NodeJS, HTTP, Security, Hashing, Database, MariaDB, Private, Information

Link: sso.smach.us