A Capstone Journey

Authentication is the act of proving an assertion, such as the identity of a computer system user.

Wikipedia

This week, I’m working on authentication for our capstone project. My first experience with auth involved securing API routes using Auth0 during my Cloud Applications Development course. In this blog post, I’d like to discuss how Auth0 acts like a middleman to authenticate users, how it secures user data, and why developers should consider outsourcing their app security to a company like Auth0.

Auth0 is a platform that handles the complicated process of authenticating users. Administrators configure Auth0 to handle user logins by choosing the type of login to allow i.e. Google, Apple, username/password, etc. Then admins simply provide Auth0 with URL redirects for successful logins and for unsuccessful logins. Auth0 essentially becomes a middleman and the app flow looks like this: a user attempts to login on your website and is sent to an Auth0 login form. Once authenticated, Auth0 sends them back to your website using the specified redirect URL. Generally a cookie is stored locally to confirm to your app that they are authenticated. Under the hood, Auth0 secures sensitive data like usernames and passwords in AWS by salting and hashing data using bcrypt. What is salting and hashing anyway?

Salting hashes sounds like one of the steps of a hash browns recipe, but in cryptography, the expression refers to adding random data to the input of a hash function to guarantee a unique output, the hash, even when the inputs are the same.

Auth0

Let’s look at a real life example of what happens when we hash passwords without a salt. Looking at the 2012 LinkedIn Hash Dump Analysis, 1.13 million people used the password “123456”. If a bad actor decrypts this one hash, he or she now has a password that works for over one million accounts. Hence, salting helps to eliminate duplicate hashes, thereby increasing the security of all your user accounts.

In addition to salting and hashing, Auth0 encrypts this data at rest in the MongoDB database and in motion (during the back and forth requests between Auth0 and the database). It uses a cyrptographic protocol called Transport Layer Security (TLS) with at least 128 bit encryption. This simply means that the length of the key to encrypt the data is at least 128 bits and generally up to 256 bits. While this sounds complicated, there are libraries to help developers with encryption, so why don’t we all just build our own home grown authentication solutions?

One big downside to individually handling authentication is responsibility. The developer is now responsible for all the security and maintenance of the authentication system. This means that every time security best practices change around password hashing or storing user data, the solution must evolve. Depending on the size of your company or developer team, this could be very doable or a major headache.

For our capstone project, we are building an application for a small business that needs authentication for its employees. Luckily, Auth0 has a free tier when you have less than 7,000 users, which is perfect for a small business. Outsourcing security to the professionals frees up our developer team to spend more time solving business problems, ensures tighter software security, and overall is the optimal solution for our use case.

Last week I shared that I was feeling overwhelmed. I’m responsible for the REST API for our project. If you recall, I mentioned that our project requires CRUD operations for 14 different services, each requiring 10 – 15 pieces of information. The thought of manually validating that much data was mind boggling. I needed structure and fast! So I took some time to research Object Relational Mapping or ORM.

I had heard of Object Relational Mapping during both my databases and cloud courses. Essentially, I was told not to use it. I’m a little disheartened that no one taught it to us. I found a library called gstore-node that allows me to create schemas for each of my fourteen services, and it integrates with Datastore, simplifying the query process. Here’s some example code from my cloud portfolio project using Datastore. I really hated this code but I didn’t know to improve it at the time. Also please notice how this code is in a file containing 300 lines of code!

After reading the gstore-node documentation and reviewing several sample projects, I finally started to understand best practices. I separated each pest control service (i.e. feature) into their own directories containing a model, controller, and router. I read that this method is preferable to having three directories named model, controller, and router containing several feature files. For more information, follow this link.

As I began work on the next service, I realized that roach.controller.js contains the same logic for every single feature. So I removed that file into it’s own controller directory and changed the function names to be more generic.

Now to the server code… compare my previous portfolio project POST request without an ORM to my current POST request using gstore-node. The entire file is 19 lines of code.

It certainly helps to separate code blocks into files, but hopefully you can see how the ORM does the heavy lifting. The largest file here contains only 55 lines of code, instead of hundreds. Functions like sanitize(), save(), update(), schema(), and plain() abstract away extra steps that cluttered my cloud portfolio project. Though it took me a few days to learn gstore-node and get my first working route, I spent about five minutes on the second route. Now I feel confident that I can knock out 12 more including testing and documentation in an hour or two. That’s the power of using an ORM. There is an upfront cost but it’s so much simpler in the long run. There is a better way, and the way is Object Relational Mapping.

Like every human being on the planet, I too have had challenging experiences with teamwork. As the Capstone course is entirely composed of a group project, I’d like to share some tools I’ve learned that have helped to mitigate the consequences of difficult team dynamics. My top three favorite tools are team standards, communication, and vulnerability.

I was taught team standards during my coursework at OSU. This is a written document created at the start of a group project. It contains a plan for the group including methods to help resolve conflict, mutually agreed upon before everyone starts tearing their hair out. For my Software Engineering II course, I participated in a group project with my good friend Ronny and another student, let’s call him Jay. When setting up the standards, I rather arbitrarily suggested we have a conflict resolution strategy that the majority rules. This one sentence in our standards document saved our proverbial bacon.

We were each given one problem to solve with the constraint that we weren’t allowed to use built-in methods or Python modules in our code. In addition, we had to create our own black box, white box, and random testing suites for each problem. I was responsible for reviewing Jay’s code when I found an issue with his algorithm. It was taking over 20 minutes to run 1,000 random inputs. The instructor stated he would be testing 10,000 inputs for each problem and each testing suite had to finish in less than a few hours time. In my code review I recommended that Jay optimize his algorithm so that we wouldn’t lose points but he stated that it couldn’t be done.

I reviewed the algorithm Jay wrote to calculate the month, day, and year given the number of seconds since Unix epoch. I realized that there was a simpler way to perform this calculation. Jay was iterating through each day, then incrementing month and year. It seemed simpler to me to reverse the algorithm. Start by checking if the current year (set to epoch 1970) is a leap year, if not, subtract 365 days from the remaining days. By decrementing a year at a time, it saved us 365 times through the loop. Jay refused to work on the optimized version so I refactored his code using this simpler approach. Jay had the most difficult algorithm to be sure, and I believed he was having trouble asking for help. Though it took several hours to fix, we went from running 1,000 test cases in 22 minutes to running 1,000 test cases in 2 seconds.

I brought the optimized code to my group and Jay stated that he didn’t want to use it. I knew it would surely get us all the 4.0 grades we wanted, whereas Jay’s code was an unknown. I tried to communicate this with Jay but he was adamantly against using the optimized code. My second teammate and I decided to accept my PR since the majority rules in our team standard. We received a 100% on the project and all got A’s in the course.

“Teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”

– Patrick Lencioni

Truthfully, I don’t understand why we had to fall back on a “majority rules” standard in this case. Teamwork is a difficult balance. Was I being pushy or domineering? Solely focused on optimized code to ensure my own end goal, an A in the course? Was Jay being prideful or lazy? Not willing to put forth the effort or accept help from his team to ensure everyone’s success?

I don’t think life is ever so black and white. There are plenty of shades of gray here. I just hope that I can do my best to follow our group standards, keep the lines of communication open, and stay humble throughout this Capstone course. Worst case scenario, I have another example for interviews to discuss how I, hopefully, mitigated conflict 🙂