Here are some of my most notable contributions.

Secure Sign-In

During my final semesters of college, I had the pleasure of working for a non-profit organization. Some of my work there was to rewrite an existing but flawed sign-in system. The system was deeply integrated into our flagship application and most of our other apps–which was separate software–tied into it for authentication. The sign-in system assigned users an arbitrary username and password, which was combination of personal data (such as year of birth). Each associate would use these credentials to sign-in and access his/her data within the system.

Unfortunately, the system received several support tickets. Most were a result of user error where the associate could not remember his or her credentials but some were a result of the design. As time went on it became aggravating to manage the repeating tasks to support the system.

The team banded together and concluded the best solution to the problem would require developing a new app to act as a centralized single sign-on system that would support our suite of existing apps. This would retire the existing sign-in system embedded within our flagship application.

But there would be challenges along the way:

So the meetings begun and we hashed out the details:

  1. Existing applications would continue to look and function as normal with little changes.
  2. The sign-in links in applications would instead redirect to the centralized login system.
  3. Upon completion of sign-in the system would redirect back to the origin application.

Here is how it worked:

<a href="/signon?redirect={URI}">Sign in</a>

The link above was embedded within existing applications. The sign-on screen would allow the user to enter the email/password combination.

Fig. 1. Single Sign-On screen.

When successful, it would emit an Hypertext Transfer Protocol Location header telling the browser to redirect back to the origin.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Connection: keep-alive
Date …
Location: {URI}

<!DOCTYPE><html lang="en"> ...

Next, the applications had to be slightly modified to communicate with the new sign-on system. We adapted the existing apps to call into a new centralized single sign-on application protocol interface (API). The idea was to make as little changes as possible. Instead of setting up the session and authenticating the user, the responsibility was to ask the API who the user was and within itself authorize the user to perform certain actions.

That's it. Little impact. However, this was not entirely true, there was some impact to the user. The credentials they were familiar with would no longer work. The team decided to move away from our existing usernames and ditch the insecure password consisting of personal identifying information. The move would lean toward using an e-mail address with a user provided password.

This meant we would migrate existing accounts to use the associated email address on file. And instead of creating temporary passwords when the system went live, the user would receive an email to enter his/her password upon first login.

At a minimum the sign-on system included a few key features:

  1. Sign-in form using email + password.
  2. Reset feature to recover password.
  3. CAPTCHA to prevent computerized attacks on the system.
  4. Secure hash of password.

If the user forgot his or her password, they could opt to have an email sent that would allow them to reset their password. Since user passwords are never stored in plain text, there is no way to recover the original input. Instead passwords are salted-padded with random values-then input into a one-way cryptographic hash function.

When too many failed attempts occur for a given user, a CAPTCHA would appear that would prevent automated attacks.

The overall architecture of the system followed the Model-View-Controller (MVC) design pattern to make the code easier to maintain. The system used binded query parameters to prevent SQL injections as much as possible. It also never revealed whether an email address existed in our system when requesting a password reset.

Overall the project was a success. Users appreciated using their email address and not an arbitrarily assigned username. Over time less tickets occurred. All existing applications were ported to utilize the new single sign-on system.

Built with DocPad on NodeJS platform. Hosted on Raspberry Pi. Made with in Kentucky.

Please write inquires or communication to electronic mail address:


Copyright, works licensed under Apache 2. Icons by Icons8