Speaking of rabbit holes, here’s a long-eared thief 🐱👤 making off with a cookie! 🍪 Singing about cookies, today we discussed cookies and Rails session stores, as well as authentication and authorization.
A few questions came up, and I’ve a blog presentation tomorrow, so I thought I’d do some research and here’s what I found:
In short, yes. When using an internet browser without an SSL/TLS certificate all information is transferred in 🔠 clear text 🔠, hence the hard push to HTTPS by browsers.
“The HTTP specification specifically states that HTTP is not considered to be a secure 🔐 method of user authentication (unless used in conjunction with some external secure system such as SSL or TLS)” [source]. Encryption and public keys is a bottomless 🐰 🕳you will never escape from, unless you’re a seasoned spelunker …
HTTPS or HTTP/TLS stands for Hypertext Transfer Protocol Secure or HTTP over TLS (Transport Layer Security)[the brief definition at -developer.mozilla.org] [full protocol text at ietf.org], formerly SSL (secure sockets layer, v2.0 and 3.0 are both deprecated in 2011 and 2015 respectively.), which encrypts 🔒your data to prevent the data from being read while it is being transported.
Two notes here:
- SSL/TLS certificates usually cost money 💸, but there are now free options available from different organizations for different reasons (a google search will popup some leads). The one I’d recommend first is built by the Linux Foundation. 🌟 Let’s Encrypt 🌟is free, automated and open certificate authority (CA), built for the public’s benefit.
- The IETF (Internet Engineering Task Force) is a standards body which has been developing open international standards since 1986. It is made up of network designers, operators, vendors and researchers and 🤼 anyone can get involved 🤼. Its also THE place to keep yourself in touch with standards that are in the making or are being updated [✨current topics of interest✨]. The best way to get dip your foot in is to 📧sign up for their mailing lists📧.
⚠️ p.s. apparently Rails may log your POST requests with clear-text passwords unless you adjust your logging level.
There is a defined standard for cookie limits [RFC6265 :Limits] however each browser has different limits for themselves. The standards are:
- at least 4096 bytes per 🍪
- at least 50 🍪s per domain
- at least 3000 🍪s total
This site seems to have been last updated in 2017 with some limits for popular browsers.
More info Links:
- RFC 6265, the current official specification for HTTP cookies @ ietf.org
- What are Cookies? epic.org — electronic privacy information center
Although these 𝟛 subjects 三 have tremendous depth and really going deeply into any one of them would be many blog posts deep, from my reading I’ve gathered a few insights, which I’d like to share.
Hashes are generated by hashing algorithms which are a 𝟙一 way process, as opposed to encryption 🔒and decryption 🔓which is a back and forth process. A plain text string can be encrypted and decrypted using a key. In comparison a hash converts a plain text string, but cannot un-hash the string, but is subject to attacks such as a 🌈rainbow table which precomputes a huge number of hashes and compares the hashed plain text password again that pre-generated list (e.g. John the Ripper and RainbowCrack). They are also vulnerable to 💪🏼brute force attacks like a 📗dictionary attack or credential recycling ♻️. Many tools are readily available for hackers, and security professionals, to use in penetrate testing systems.
The co-called “Moore’s law”, in which Gordon Moore predicted that computers would increase in power, yet decrease in cost exponentially has remained in effect and the fact that computers’ power to compute and store data is growing exponentially means that brute force and rainbow table attacks are that much easier to execute. [Moore’s law vs actual transistor count animation]
🧂Salting 🧂adds a unique, “fixed-length cryptographically-strong random value” (auth0.com has a plethora of deep rabbit holes to visit in regards to security) to create a new string that is unique. Even if two passwords are identical clear-text strings, when they are passed through the hashing function and then salted, the two resulting hashes will be different. This salt can be stored in clear-text alongside the hash.
In contrast, 🌶️ Peppering 🌶️ is adding a secret password for the hashing function that adds uniqueness to the to-be-hashed string. I won’t go into this because, again, this is another deep rabbit hole but this blog post is informative.
Finally, there is bcrypt, which plays the game a little differently than other password hashing methods. It intentionally runs slow to make cracking , as opposed to its predecessor crypt, which didn’t have an “adaptable cost” to slow down the calculation time [this link at auth0 has a deep dive and a chart of times to hash at different cost settings]. This makes the function viable even as processor power and storage capacities rise, with lower costs, by increasing the delay it makes using rainbow or brute force attacks less feasible because of the time cost. The challenge is to balance out the growing processing time with the patience of users using the system and who are waiting to log in.
The field of encryption and security is an interesting one, with many areas of specialization and an unending amount of demand for knowledgeable programmers and IT staff. If you’ve found this interesting, I wish you the best of luck! As for me, I’ll let the pros show me how its done!
Мой блог никогда не завершать without a random change in topic. There is a bonus today because there are 2.😃😃
- For reference, a list of HTTP status codes that can be returned in Ruby on Rails. These can be utilized thusly:
class ModelsController < ApplicationControllerbefore_action :require_login[insert route methods here]privatedef require_login
return head(:forbidden) unless session.include? :user_id
## Response Class
***HTTP Status Code | Symbol***
100 | :continue
101 | :switching_protocols
102 | :processing
200 | :ok
201 | :created
202 | :accepted
203 | :non_authoritative_information
204 | :no_content
205 | :reset_content
206 | :partial_content
207 | :multi_status
208 | :already_reported
226 | :im_used
300 | :multiple_choices
301 | :moved_permanently
302 | :found
303 | :see_other
304 | :not_modified
305 | :use_proxy
307 | :temporary_redirect
308 | :permanent_redirect
400 | :bad_request
401 | :unauthorized
402 | :payment_required
403 | :forbidden
404 | :not_found
405 | :method_not_allowed
406 | :not_acceptable
407 | :proxy_authentication_required
408 | :request_timeout
409 | :conflict
410 | :gone
411 | :length_required
412 | :precondition_failed
413 | :payload_too_large
414 | :uri_too_long
415 | :unsupported_media_type
416 | :range_not_satisfiable
417 | :expectation_failed
421 | :misdirected_request
422 | :unprocessable_entity
423 | :locked
424 | :failed_dependency
426 | :upgrade_required
428 | :precondition_required
429 | :too_many_requests
431 | :request_header_fields_too_large
451 | :unavailable_for_legal_reasons
500 | :internal_server_error
501 | :not_implemented
502 | :bad_gateway
503 | :service_unavailable
504 | :gateway_timeout
505 | :http_version_not_supported
506 | :variant_also_negotiates
507 | :insufficient_storage
508 | :loop_detected
510 | :not_extended
511 | :network_authentication_required
source : [https| ://guides.rubyonrails.org/layouts_and_rendering.html](https ://guides.rubyonrails.org/layouts_and_rendering.html)