Forem: Westin Humble

Under the Hood: How BCrypt Functions

Westin Humble — Thu, 21 Apr 2022 01:16:52 +0000

Something that I often experience as a student software engineer is taking a feature of a web application that I’ve used hundreds (if not thousands) of times before, and then learning how it is implemented/how it functions. It’s actually become one of my favorite aspects about learning the profession thus far! One such concept that I’ve encountered/learned recently is how passwords are securely stored and accessed. Of course, to even get to the point of understanding the above, one must first learn how a user enters that password data into a form and how that data is transferred to a database. After that, one can safely assume that every time you log in you’re just posting the input from the password form to a database, and a function checks to see if that plaintext password matches the username, then you’re good to go, right? Well, if we deploy a website where the sole intention is to compromise our user’s information, then absolutely! But that’s not what we’re about!

One of the primary tools used in securing passwords (or anything regarded as sensitive information) is hashing. As alluded to above, storing plaintext passwords puts users at risk. People (myself previously very much included) have a strong tendency to use same or similar passwords for multiple websites, and it’s easy to see why. It’s hard to put a number on the average number of applications that a single person has to remember login credentials for, but even if the number was simply five, that’s a lot of effort to generate a secure unique password for each platform! Thus, a data breach has the potential to expose a single user to multiple other breaches (among other risks). Hashing combats this by taking a newly-minted password and generating a fixed-length output. This seemingly unintelligible text that the hash function generates makes password determination difficult, but not impossible.

Given that a hash always produces a fixed length output, one could take many of the available breached databases on the internet and create a reference of all these known passwords/hashes and cross-reference the database in-question. From there, it’s just a matching game. This is where salting comes in! A salt is just “simply” a random string added to the beginning of a password before it is hashed. This adds another layer of complexity to obtain a databases’ sensitive information. If we could also make the hashing function very computationally expensive, such that the function requires a lot of time/space to re-run a password string, then you have a great recipe to make compromising a database at least way more effort than it’s worth. One broadly used cryptographic function to hash/salt passwords (as well as taking a very long time to do it) is BCrypt.

As one would surmise, there are many widely available cryptographic functions; two examples being the SHA2 or SHA3 family. Although these perform similar tasks to BCrypt, they are computationally fast, making brute force attacks easier. In addition to the benefit of being computationally slow, BCrypt also has the advantage of scalability. As modern CPUs become predictably faster at computing hashes, BCrypt will run slower and slower given “faster” hardware.

So we’ve gone over why BCrypt is used, but how exactly does it work? The function can be broken down into two phases.

https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

Phase 1: A function named “EksBlowfishSetup” is called, taking in the desired cost, salted prepended string, and the password. This is where the bulk of BCrypt’s time is spent; generating a set of subkeys from the primary key (i.e. the password).

Phase 2: From here, the 192 bit text “OrpheanBeholderScryDoubt” is encrypted 64 times using EksBlowfish in Electronic Code Book (ECB) mode with the state from the previous phase. This produces the cost and 128-bit salt value concatenated with the result of the encryption loop.

The resulting hash will have some consistent features:

https://blog.boot.dev/cryptography/bcrypt-step-by-step/

It’ll be prefixed by either $2a$, $2y$, or $2b$ (i.e. the algorithm identifier)
It’ll delineate the cost (10 in this case)
Then the remaining characters contain the salt/password hash

Simplified: One algorithm (EksBlowfish) performs a lengthy computation based on input, and the results of those computations are encrypted alongside a fixed string (OrpheanBeholderScryDoubt) to create a fixed length hash.

Once a hash is generated, we need to be able to store it to be compared for authentication purposes. The source code of the BCrypt Ruby Gem actually offers great insight into how this is performed in Rails:

First and foremost, keep in mind that knowing what the password’s salt is is the Password object’s responsibility.
The given password is run through the same function as the stored (with the same salt)
Then the results are compared to the stored hash

Viola! The password can be verified in one line of code:

https://icevans.github.io/bcrypt

Resources (url):

https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

https://www.ubiqsecurity.com/ecb-vs-cbc-block-cipher-mode-differences/

https://blog.boot.dev/cryptography/bcrypt-step-by-step/

https://icevans.github.io/bcrypt

https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/provos/provos_html/node5.html

https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/provos/provos_html/node4.html

How to Interpret and Use Documentation as a Student Software Engineer

Westin Humble — Wed, 30 Mar 2022 01:12:49 +0000

Since my last blog, I’ve entered into phase 3 of my bootcamp where we’re tasked with learning an entirely new programming language (Ruby) among many other backend-centric concepts. Just like that, despite barely taking the training wheels off with Javascript, it was already time to learn and implement another language. Luckily, after hundreds of repetitions in building apps and solving problems with one programming language, the process is significantly less daunting to learn another.

10,000 foot view: These languages all need to accomplish similar tasks. You need to be able to define variables. You need to be able to write functions. You need to be able to access and modify data in objects and arrays. In my experience thus far, the real differences come down to syntax and built-in methods. The bridge between your more familiar language’s syntax and built-in methods and the language you’re trying to learn is documentation! However, understanding documentation with the purpose of rapidly applying is a skill in and of itself, and one that will be the focus of this blog.

In my previous career, I was a Prosthetist/Orthotist. To make that uncommon job description succinct, I used evidence-based practice to restore mobility to people with limb loss and/or a wide swath of neurological and musculoskeletal conditions. One of the toughest and most important aspects of the job was implementing best practice garnered from reading scientific articles/current research (e.g. evidence-based practice). Scientific articles are very dense and overwhelming to digest until one has read many over time, and most importantly, learned how to effectively parse through them to be able to evaluate the quality of the document and implement the findings.

As I was learning the basics of javascript (and now Ruby), I noticed a lot of similarities between developer documentation (known colloquially and lovingly as “docs”) and scientific articles, and even experienced a similar amount of dread upon first glance! The initial time I had googled “MDN map” to learn how to use that built-in method in a specific case, I left the page more confused than when I arrived. This is unsurprising given that software engineering concepts, like concepts within science, have building blocks that can’t be skipped if full understanding is the goal. That said, even if a grasp on the building blocks is solid, that doesn’t mean that parsing through docs as a beginner can’t be extremely time consuming.

The parallels between understanding docs and scientific articles (for me), come down to the following two general principles:

Reading the article (or doc) in-full is rarely required. Focus on what you need! For someone practicing evidence-based rehabilitation, it came down to fully comprehending the methods and results sections. The introduction and conclusion are more important to those in academia. Similarly, to borrow from the map example above, it’s doubtful that the ES2015 implementation of your desired built-in method will be relevant to you at the start of your programming journey.
If you don’t understand a concept, don’t panic- Google! It was rare that I would come across a novel scientific article and fully understand, for example, a machine they were using for testing and/or an advanced statistical method. A (relatively) quick search would fill in those “building blocks” and allow me to move on in comprehending the article. In the case of software engineering, I had no clue what a callback function was the first time I came across the reference in an MDN doc. Isn’t having unlimited information at your convenient disposal great?

Following these general principles, I’ve been able to greatly expedite my process of learning Ruby. More specifically, I like to quickly hone in on the following four items when parsing through docs:

What data type the method takes in
The needed parameters
The return value
An example of implementation

Quickly locating the above will allow me to answer the following questions in a rapid fashion:

Do my intake, parameters, and return values match?

But what about the locating the example? Were we doing that just for fun? Not quite- the example allows me to have a template to quickly match syntax!

If the answer is “no” to the first three questions, then chances are you will have to find another built-in method (or no built-in method) to accomplish your goal. But knowing what you can’t do is half the battle! For the rest, chances are Stack Overflow or GitHub will have what you need.

Consider the following example in Active Record. You need to query in a pry session by the first name (a string) of a user within a database. You find find (pun intended). Will this specific finder method work for your purposes, and using the above questions, how quickly can you determine if it will or won’t?

https://api.rubyonrails.org/v7.0.2.3/classes/ActiveRecord/FinderMethods.html#method-i-find

One final note, learning to correct syntax and incorrect data type errors through error messages in the terminal has become increasingly valuable to (recently) indispensable for me. I suspect this is the case for everyone as they move through their software engineering journey. Remember that errors are every bit as valuable as expected output! When it stops feeling that way, there’s always docs!

Common React Mistakes and the Student Software Engineer

Westin Humble — Tue, 08 Mar 2022 02:23:46 +0000

In my last blog, I had outlined a cursory overview of big O notation and how I thought the student software engineer should employ it. In the second part of this blog series, I want to switch gears to something slightly less abstract, but still emphasizing the student software engineer’s experience.

Recently, I have begun learning the basics of the popular Javascript library, React. I instantly took to React’s tidy philosophy of front-end development and even got a little misty-eyed at the prospect of (generally) not having to refer to lines 99 and above.

However, that’s not to say that there wasn’t a learning curve. True to software development form, many of my errors and troubleshooting resolutions came down to small syntax errors and a misunderstanding of a couple of React’s key building blocks. Below are some of the “aha” moments I had (in somewhat chronological order), in hopes that it may save other’s some time!

There’s a reason that it’s called “passing” props. You can’t assume that a child component will have access to props just by virtue of the prop being in a parent component. You must pass the props within the return statement of the parent component, and that props can then be received in the parameters of the child component function.

Passing props to displayData

Display data receiving the props

One of the aspects I like about React the most is the emphasis on the single responsibility principle. Along that vein, it’s important to ensure the props, fetches, and anything passed down the component tree has the most efficient path possible.

For example, it may be tempting to place your fetch in the component at the very top of the tree (let’s call it “App”) given its access to every component. However, if there exists a component that is meant to be a container (let’s call it “containerLol”) for your displayed data with access to all remaining components necessary to render this data- it’d be best to perform the fetch within containerLol (versus App) to avoid unnecessarily passing props and making debugging more time consuming.

Although the useState hook is a great tool for right situation, it’s best not to overuse. I definitely went overboard in overusing state early on, and debugging became much more difficult than it should have been. Primarily, these problems arose from state’s asynchronous nature producing outputs from user input that were… less than predictable.

The rule(s) of thumb of using state only when:

Data can’t be passed via props
Is not unchanged over time
Is not computable from other state/props with a component

have been very helpful for the purposes of reinforcing good practice on using state.

You know how when you’re learning something new and your references tell you not to do a particular thing and you do it anyway? That was my experience with violating the principle of state’s immutability.

Directly modifying a state variable with a setter function produced one particularly frustrating debugging session. At least when dealing with arrays (which we often are), spread syntax and/or an array method that returns a new array are your friend!

The way to not update an state variable containing an array

The correct way to update an state variable containing an array

Big O Notation and the Student Software Engineer

Westin Humble — Sun, 13 Feb 2022 21:32:15 +0000

Greetings from (not so sunny) Brooklyn, NY during the early stages of year 2022! I’ve recently begun Flatiron’s Software Engineering 15 week immersive program, and what better way to expand-upon concepts (that the program can often only afford an honorable mention) than blogging? For this series of three blogs, I want to focus on material that I’ve found particularly interesting and how it benefits the student software engineer to at least have a cursory understanding. The first such concept is Big O notation.

When first learning the basics of Javascript and how to build software/craft solutions for web development, little attention is paid to the efficiency of the algorithms employed. This is understandable, given that it seems like the equivalent of learning an entire written and spoken language in (typically) a relatively short timeframe. At first, the most critical take-aways are the tools you have at your disposal and how/when they are used. Global variables are plentiful, every function (no matter how often it is used) is named. You may even try to make the most deeply nested loop imaginable just to see if you can make it work for a specific purpose!

At least in the bootcamp setting, this sandbox phase of programming comes to an end quite quickly. Much of this is for readability and best-practice reinforcement. But in the world of web development where one can’t make accurate assumptions about how up-to-date most user’s hardware/operating system is, it becomes important to your code as efficient (i.e. accomplishing as much as it can while using as little resources as possible) as can be. One way to estimate this is Big O notation.

Invented by German mathematicians Paul Bachmann and Edmund Landau well before electronic computers were viable, Big O notation describes the limiting behavior of a function when the argument tends towards a particular value or infinity. As with many mathematical concepts and notations, Big O has been coopted by by other mathematical theorems as well as for more applied applications, as is the case in computer science. It’s important to note that Big O notation in computer science does not and cannot directly measure a particular algorithm’s complexity/its effect on a given computer’s hardware. It’s also important to note that most algorithms run so quickly/efficiently that their use of resources is negligible.

So where does Big O notation come into play? For the student software engineer, I believe it comes down to having an understanding of how to categorize an algorithm’s runtime efficiency (expanded upon below) and when to start thinking about your program’s runtime efficiency and the effect it might have on your user’s experience. For the latter, the rule of thumb is to start reducing complexity/using the most optimal tools when you are writing a program that processes a large amount of input data, performs complex operations, and generates a large amount of output data.

When it comes comes categorization of algorithmic efficiency, it is my understanding that it is not unheard-of to be asked to categorize algorithms according to Big O notation in technical interviews for jobs. Accurate categorization demonstrates that the interviewee has at least an understanding of what/when to avoid come time to start building code snippets and making pull requests.

The most common categorizations of time/space complexity using Big O notation in web development are constant, logarithmic, linear, and quadratic. Both time and space complexity are measured relative to the the size of the input (i.e. the steps necessary for the algorithm to accomplish its task). Space complexity also tends to be harder to estimate given variation between environments and programming languages. Of note, both time and space complexity can be viewed as an inverse relationship, where (within reason) sacrificing one can benefit the other.

At the highest level, Big O notation describes how many steps an algorithm takes based on the number of elements that it is acted upon, and classifies it according to the worst case scenario.

A practical, newbie friendly, non in-depth guide of the most common categorizations are below:

Constant O(1). Where “1” represents the amount of steps taken to complete the function, an example would be performing a search using an element’s know index value.
Linear O(n). Where “n” represents the amount of data to be traversed, an example would be iterating through an array, with time complexity increasing by one step per element.
Logarithmic O(logN). These algorithms are characterized by the the number of operations increasing by one every time the data is doubled. A classic example of using a logarithmic algorithm is searching for a specific name in a phone book. Rather than searching through the whole phonebook, it’s better to start by not looking in in the letter directory where you know their name will not occur. These are especially useful algorithms for large data sets.
Quadratic O(N^2). Used to characterize algorithms that are quite slow, complexity is proportional to the square of the size of the inputs (e.g. if the input array has 10 elements it will perform 100 operations). An example being a function that traverses through an array twice to find duplicates or a one that requires nested iteration.

https://miro.medium.com/max/1400/1*yiyfZodqXNwMouC0-B0Wlg.png

For further elaboration, below are some built-in array methods within Javascript and their associated Big-O notation classification (IF used on an array). Consider what the method does, the required steps, and the output (if any):

.indexOf( ) = O(n)
.push( ) = O(1)
.unshift( ) = O(n)
.pop( ) = O(1)
.shift( ) = O(n)
.slice( ) = O(n)

Need a too long/didn’t read version? For the beginning software engineer, always keep algorithmic efficiency in the back of your mind (along with what tools work best for which scenarios), and make sure to understand the most common categorizations come time for technical interviews in job applications! This was a very condensed overview of a big world when it comes to time/space complexity in software engineering algorithms. There’s a lot to know, and a lot yet to be fleshed out. Feel free to drop a comment with questions, critiques, feedback, or just to say hi! Thanks for reading!

Final Note === Here’s a nifty web-based tool for directly measuring the time complexity of your algorithms. Just pick a language, paste your code, and give it a run:

https://tio.run/#

Sources (url):

https://www.bigocheatsheet.com/

https://www.britannica.com/science/computer-science/Information-management

https://jackkrupansky.medium.com/what-is-algorithmic-complexity-or-computational-complexity-and-big-o-notation-9c1e5eb6ad48

https://towardsdatascience.com/the-big-o-notation-d35d52f38134

https://blog.webpagetest.org/posts/benchmarking-javascript-memory-usage/#:~:text=At%20the%20median%2C%20sites%20are,and%20~9.6MB%20for%20mobile.