Cookie Snatchers (Rails Session Encryption)
We recently discovered cookies. They are delicious. I want all the cookies.
So I just learned about cookies yesterday… they’re still exciting to me ok? A lot of what we do in Rails feels like magic, but I feel like Flatiron has done a good job of developing the fundamentals. There are some parts though the end up being glossed over because Rails does so much under the hood.
One of these items is web encryption.
In our code along, we looked at storing a cookie in the most basic storage possible... literally a method called cookie on the controller. This can store our login parameters, but in a very exposed way.
If we were to view this cookie through a google chrome extension, it’s as transparent as a neo-nazi on alt-right appreciation day… what use is an authorization cookie when it very clearly tells everyone what your user authorization is. This would be good for general items like time zone, language, etc., but personal information shouldn’t be stored this way.
If we throw that sucker into a session method instead of a cookie message, then Rails uses super magical abilities to transform that cookie into this.
When I used the cookies method on controller, the value was exposed. When I used session instead, Rails automatically encrypted the value and stored it within the base cookie. Rails magic happened. I used the session method and it automatically triggered the SecureRandom Module. This is a common library included with Rails that has made appearances in Java and C as well. The value in the cookie is encrypted with a hexadecimal.
The only way to decode this message is with the hexadecimal key. This is also brings us to the distinction between encrypting and encoding data. An encryption relies on a key that can both create and translate received messages. Encoding is more of a one way street and it is used only at sending. Anyone can decode an encoded message, while encryption can only be translated with the use of the key. Encoded messages aren’t meant to be as secure as an encrypted one.
So where is the session encryption key stored? This key is the pass code to any basic Rails server. At the end of the day, I think this question is much more complicated than I anticipated and also am willing to explain within a blog post. The short answer is that every session has a token stored in this value.
This is the Cross-Site Request Forgery token. This is the token that implicitly authorizes the session and the cookie. This is a useful token, but not the encryption key I’m looking for. Rails also offers cookie serialization and cookie storage as further depths of cookie encryption. What I’m looking for, the key to decryption is stored in config/secrets.yml.
The secret_key_base is the basis for all our cookie encryption. The fact that the key is stored in this file and this variable means that it is probably exposed to the outside world. It is definitely exposed if we were to make this open source and share the secrets.yml file. It is also exposed to anyone who recognizes that we are using the base Rails framework.
This is clearly just a surface inspection on cryptography and the encryption that Rails implicitly possesses, but it is useful as a first dip into the field of web development encryption.
