The Internet Runs on Cookies
What comes to mind when you see the word ‘cookie’? Chocolate chip? Oatmeal raisin? Snickerdoodle? HTTP or a small chunk of data used by web applications to identify your specific session while using the aforementioned web app? While I wholeheartedly prefer the first, after 5 weeks in Flatiron School’s Software Engineering Bootcamp, I am now inclined to give more thought to the latter answer.
The concept first appeared in computer science as “magic cookies” around 1979 where a transaction ID or some other kind of token was passed from one program to another. The data was not typically until the recipient program returned the cookie data back to the sender or perhaps another program at a later time. Netscape employee Lou Montulli is credited with then applying the practice to web browsing in 1994. MCI Communications had enlisted Netscape to develop an e-commerce application that did not require MCI servers to store data while the customer proceeded through the shopping/transaction process. Not only did Montulli and his team’s work to solve this problem lead to the creation of the online shopping cart, but it also completely changed the functionality of the internet forever.
As previously mentioned, cookies are used to communicate data between websites/applications and a user’s browser or local hard disk. The cookie’s data is stored in a simple key/value format, so it can be easily retrieved by the web application. Web apps utilizing the Ruby on Rails frameworks can take advantage of cookie data persistence in many ways. Typically, cookies store information in HTTP headers which are then saved by a user’s browser as plain text. Rails uses these cookies to maintain continuity and a smooth flow to enhance the user experience while navigating through the application. However, this format is very easy to manipulate and could leave the web app susceptible to potential data breaches and other security concerns if sensitive data is stored incorrectly.
To help mitigate this issue without sacrificing the convenience of a cookie’s simplicity, Rails adds an additional layer of security via the ‘session’ method. Each time a user accesses a Rails application, Rails provides a session object. This session object contains data specific to the user that is tracked and persisted while the user is active in the web application. Session is an entire hash that gets put in the secure session cookie that typically expires when the user closes the browser. Rails stores the data as a hash in cookie on the user’s browser via Rails CookieStore. One of the most (if not the most) important ways cookie/session data is implemented is in user authentication. Sessions allow a user’s authentication data aka username and password to be persisted throughout their time using the application.
By setting up a SessionsController in Rails, the create method can be used to store data (such as a username and password) in the session hash. For the rest of the user’s time on the site (or however long the programmer sets the session data to be persisted) this stored data will be readily available for other controllers and methods to verify the user’s authenticity. While it is relatively simple to setup username and password entry and persistence, rolling out your own authentication methods would be extremely ill-advised.
Storing passwords in plain text inside your database could result in a nefarious hacker’s easiest payday of his career. According to Ruby on Rails security guide, “The underground prices for stolen bank login accounts range from 0.5%-10% of account balance, $0.50-$30 for credit card numbers ($20-$60 with full details), $0.10-$1.50 for identities (Name, SSN & DOB), $20-$50 for retailer accounts, and $6-$10 for cloud service provider accounts.” Thankfully, Rails works to help secure user password with its #has_secure_password method. Implementing the method inside a User model allows the user to input their password and password_confirmation and the method does the rest of the dirty work for you. The method converts the submitted password into digest form and then compares that new digest with the digest previously stored from the user. Password digests are one-way encrypted versions of the actual password string. This encryption offers a layer of security as even if a hacker obtained the password digest, decrypting it to reveal the real password would be near impossible. If the user passes the correct credentials which can be checked using an #authenticate method, a session variable can be used to store their ID. This session variable can then be used to validate that they are who they say they are for the rest of their session.
Ruby on Rails utilizes cookies and session data to enhance user experience and offer basic levels of information encryption and authentication. Please show some appreciation to the numerous developers’ hard work to achieve these luxuries by not repeating your passwords or using “Password123.”