DEV Community: Kent Riggs

Salty Hashes

Kent Riggs — Wed, 27 Mar 2024 01:20:22 +0000

Secure Password Storage: Hashing and Salting

It's time for another plain language blog post. This time about a serious topic. Salty hashes. Mmm... breakfast, right? Not so much. Hashing and salting is standard practice in modern software development where user authentication is required to ensure sensitive passwords are not stored in plaintext in case of a security breach.

When building applications that require user authentication, securely storing passwords is a critical concern. Hashing is the process of passing a password through a one-way cryptographic function to generate a fixed-length string known as a hash. Even minor changes to the input password result in a vastly different hash output.

Hashing: Transforming Passwords

Common hashing algorithms used for password storage include SHA-256, SHA-3, Argon2 and bcrypt. Here's a simple example of how hashing works with the SHA-256 algorithm as a first line of defense:

Password: "myPassword123"
SHA-256 Hash: 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92

The key security benefit of hashing is its one-way nature. While inputting a password will always generate the same hash, the hash is just a sequence of hexadecimal characters that bears no resemblance to the original password. This makes it virtually impossible to derive the password from the hash alone.

Salting: Unique Keys for Every Password

While hashing provides a solid first line of defense, it's still vulnerable to certain types of attacks, such as rainbow tables (pre-computed tables of hashes for common passwords). This is where salting comes into play.

Salting is the process of adding a random string of data, known as a salt, to the password before hashing it. This means that even if two users have the same password, their hashed values will be different due to the unique salt used for each password.

Password: "myPassword123"
Salt: "Xt7&Hy9z"
Salted Password: "Xt7&Hy9zmyPassword123"
SHA-256 Hash: a8b24e9718c1fc9824f93c5d2e98988e9974f31a1d148634308a9a726f5e3d54

The salt is typically stored alongside the hashed password in the database. During authentication, the salt is retrieved, combined with the entered password, and the resulting string is hashed. If the newly generated hash matches the stored hash, the user is authenticated.

Secure Authentication Flow

- User enters password during login
- App retrieves stored salt and hash for that user
- User password is combined with stored salt
- The salted value is hashed using the same algorithm
- If newly generated hash matches stored hash, user is authenticated

Best Practices

Use strong, modern hashing algorithms: Algorithms like bcrypt and Argon2 are designed specifically for securely hashing passwords and are preferred over general-purpose hashes like SHA-256.
Use a unique salt for each password: Never reuse the same salt across multiple passwords, as this would diminish the security benefits of salting.
Increase work factor over time: Many hashing algorithms allow you to configure a "work factor" that determines how computationally expensive the hashing process is. Increase this factor over time to keep up with advancements in hardware capabilities, ensuring that password hashing remains sufficiently slow to mitigate brute force attacks while not overly taxing legitimate authentication attempts.
Don't roll your own implementation: Use well-tested, industry-standard libraries and frameworks for hashing and salting. Implementing cryptographic functions from scratch is risky business.

Hashing and Salting in Practice

Most modern web frameworks and libraries provide built-in tools for securely hashing and salting passwords. One example is in Python's Flask framework using the bcrypt module:

 @hybrid_property
    def password_hash(self):
        return self._password_hash

    @password_hash.setter
    def password_hash(self, password):

        password_hash = bcrypt.generate_password_hash(
            password.encode('utf-8'))
        self._password_hash = password_hash.decode('utf-8')

    def authenticate(self, password):
        return bcrypt.check_password_hash(
            self._password_hash, password.encode('utf-8'))

The example above handles salting and hashing (using a strong algorithm like bcrypt), verifies the entered password against the stored hash and salt which then returns True if the password matches the stored hash, otherwise returns False

This gives an overview of the how and why for salting and hashing when you're building an app that requires user authentication. One last reminder, be sure to stay up to date with dependencies in your app to ensure it stays safe from exploitation as technology evolves.

The following resources go into detail on types of hashing algorithms and their differences and more technical detail on the process itself

Now... I am off to find myself a greasy spoon kind of diner to get a salted hash breakfast for dinner.

Code with Curiosity

Kent Riggs — Fri, 08 Mar 2024 15:56:18 +0000

One of the most exciting things about embarking on the journey to learn to write code is the idea that I can build things that I dream up. As an artist, taking my vision and capturing it on paper beautifully has been nothing short of life changing for me and that desire to create is part of what led me to the program I am currently attending at Flatiron School for software engineering.

Part of my objective in writing these posts about learning to code is to bridge the gaps that may have gotten me learning to code sooner and connect with friends who are curious. In learning how programs are made I am starting to get a sense of what has always been mystifying to me. How does code go from that green text scrolling down the screen to a functional application?

Much like art, a lot of making an application happens before the work actually starts. In this case I am examining how I went from an idea to learn and connect my artistic ideas to practicing writing code with a visual output I found interesting.

My art in the printmaking world has connected organic flowing shapes, islamic geometry, and optical illusion which got me thinking, these are all rooted in math. There has to be a way to translate that into code, right? Enter GPT. How does math converge with islamic geometry? What mathematic principles visually explain tessalating patterns? Of course there were ways to make this work.

The python graph gallery? Mind. Blown.

It's worth noting that the work of Refik Anadol as the pinnacle of the convergence between art, code, and data is one of my favorite artists in the world right now which is another breadcrumb in this idea.

So many application ideas emerge from solving a problem the creator currently has or sometimes an attempt to improve code within an existing application can start with approaching the issue with curiosity. Another way art and writing code seem similar to me.

As I poked around trying to find the inflection point between python, math and some kind of visualization the usage of Pygame emerged as an interesting option.

Now I had a tool in my tool kit to potentially make something visual! What could that look like? The basic demo for Pygame was simply to draw a circle in a box. Could there be multiple circles? Could they move? Have color? Now we're off to the races.

Obligatory alliteration break: the process for arriving at a particular tool and the importance of preparation, play, and practice in building software is paramount.

That said, my next step was to play with the structure I had started.

I iterated through one ball, multiple balls, multiple balls bouncing, multiple colorful bouncing, all by adjusting the math within the pygame code watching how it affected the output on the screen.

I clearly needed a front end for this adventure. I was excited. Here is where the lesson learning starts to come in. In my haste to apply my thinking I rushed off to make a react UI without entirely considering how all of this might connect functionally.

While in theory it might be able to be functional to pass information via an API from a react front end to the python visualization code it isn't a terribly practical solution for sharing this kind of application.

An evening spent noodling on connectivity, reminding chatGPT that I was fully aware a React front end connecting to a Python back end as a user facing app was not the best option, and a lot of trial and error ultimately resulted in me giving up on bringing this idea to a web interface, for now.

I decided to revisit my current Python learning to add a command line interface to control what inputs I had to wrap the idea up into its current state.

Using a CLI gave a pretty satisfying little route to make adjustments to the code and re-run the visualization without issue. That was enough for me for this first experiment to button it up and get to writing this blog.

If you'd like to play around with my creation it is currently on GitHub. Fair warning, it is very much an idea with novice level execution, so far.

That said, It was a lot of fun to make and explore which has piqued my curiosity to build more. I plan to continue to iterate with making the code more modular for other visualization options and to see where my imagination takes me next.

Git Momentum - learning to push

Kent Riggs — Fri, 16 Feb 2024 16:29:00 +0000

It's time for another edition of newbie developer tips in plain language! This round I am going to be speaking to the subtlety and delight that is interacting with GitHub using a push request.

To git (ok ok, I'll only make this joke once) value from this blog you'll want to be familiar with setting up your account and basic jargon like understanding what a repo is and what GitHub is in general. Also, you'll want to be up to speed with using the command line, CLI, terminal, or whatever you call it as your method for interacting with GitHub

There are also other resources out there speaking to the complexities of workflows in proper dev environments when working with teams worth investigating. This writeup is not that, but I highly recommend checking some out like this excellent reference on types of branching that added a few wrinkles to my brain by Vincent Driessen.

On to the pushin'

We all have some kind of general idea what pushing and pulling does in a variety of contexts but specifically within GitHub those words do not directly translate exactly to what is happening with your code when you use those commands. Things happen behind the scenes and there can be consequences for those actions. Let's explore a little deeper.

While it is true that the git push command does upload your local repository what is unclear is that there are other actions that affect what is pushed, when, and why. This is because the whole point of GitHub is version control. Lets take a second to define what that means.

Version control is effectively the detailed tracking of changes and updates to code in software development. Given the high specific, structured, and detailed nature of programming itself you might imagine that one of the most popular platforms for managing version control for developers also carries those traits.

You could say, one does not simply push code into Origin/Maindor.

Sure, if everything is in order and no other code is involved in where you are pushing your code to it might be as simple as adding, committing, and pushing your code but if you're working with other people on a project chances are you'll have some other concepts needed to get your code in to the bigger project.

Ok ok, great. I write my nifty code, I decide I'm ready to share it with the world, and so I push it into the broader codebase, right? Nerp. Sorry. We have hierarchy and structure and the grand order of things to consider here. In the aforementioned link to branching theory you'll learn that you have your local code which is likely on a branch. A subdirectory if you will in the hierarchy of version control so that when your misplaced comma throws the proverbial wrench in the operation the finger can be pointed squarely at you. No pressure.

This is a good thing, really. Branches and local work allow for the detailed hierarchy and version documentation needed to manage complex projects effectively. The graphic above gives a simple visual for what is happening when code is pushed. It goes from your local work on it's own branch into the main code for the project in a documented way.

Utilize many branches to segment your work appropriately for what you're working on. If it is a new feature? Branch. If it is a separate addition to the broader concept of the project? Branch. Methodic and documented is the name of the game in version control and well documented code.

Preparing for the push

Now that we know there is a top down structure with local and remote branches of code let's get to what you, fellow fledgeling, need to know to upload your precioussssss code to your branch.

A couple of nice to know commands to be aware of to ensure you're going in the right direction before we move forward:

git status allows you to view all of the files that are staged before committing them. Handy little tool, that.

git branch will verify what branch you're working on so that you don't just try to push your code directly to the main branch.

Adding your local code in preparation to push it up to the main branch is done via git add in your command line. You can use this to specify specific files like git add README.md or by adding everything in your local repo by adding a period like so:

git add .

Now that your files are added to the list of what is going to be pushed up you'll want to impress your therapist and commit to something. That's right, you have to own your work and even tell everyone what you did by adding a little description. Which, much like real life, it is very important to communicate where your head is at. The commit syntax is as follows:

git commit -m "And if you gaze for long into an abyss, the abyss gazes also into you"

In reality, commit is what records the changes to the repository. It is very important here to understand the style of commit messagges expected in the project your working on and to leave meaningful clues to what is happening in your code for those that might be reading it after you. Here is what is really going on with your commit message straight from the hubses mouth:

git commit creates a commit, which is like a snapshot of your repository. These commits are snapshots of your entire repository at specific times. You should make new commits often, based around logical units of change. Over time, commits should tell a story of the history of your repository and how it came to be the way that it currently is. Commits include lots of metadata in addition to the contents and message, like the author, timestamp, and more.

That is powerful stuff! I liken this step to a saying from my World of Warcraft raiding days. Pot early, pot often. Frequent commits create a paper trail so to speak of all your hard work. Use it to your advantage and commit early, commit often.

The final step is actually pushing your code. Which seems benign enough but this precipitates a variety of things happening. The push is part of syncing code with the broader code base. It takes your added changes and committed descriptions of those changes and moves them to the public version of your branch. This is only part of the equation though.

Depending on what state the branch you're pushing that code into is in you may need to address what to do with your changes and how they are going to affect the broader code.

Fetching, pulling, and merging are tools in the tool kit for working with ensuring your code is clean and pushed up to the branch that I'll visit in another post. For now, you should have a deeper understanding of what it means to add, commit, and push with some new tools to check up on your code before you push it on up.

Until next time.

I used this guide from Atlassian as a resource for this post including the image above.

Declaring Functions

Kent Riggs — Fri, 26 Jan 2024 17:46:39 +0000

A friendly stroll through some basic Javascript function concepts.

Intro

Functions are one of the basic building blocks of making Javascript, and a variety of other programming languages, work. Not only are functions a key element in making code do something they also allow for cleaner and more concise code as well.

If I've learned anything about learning a programming language, as a complete novice to coding, it is that for any general statement there are probably 3849208 circumstances that augment that general statement. However, one of the things I wish I understood sooner was the basic syntax requirements for functions so here we are. Learning by teaching.

Intrinsically a function is just a block of code. The most basic syntax involves using a set of parenthesis and curly brackets as your clue that you're looking at a function.

(This is where grown up developers would say "but but, curly bracket, object literal..." and we're going to say "yeah yeah, pipe down, we're talkin' functions right now and everyone knows it.")

Here's the goods. Pretty simple, right?

function genericFunctionName () {
     //what it does goes here
}

A lot of documentation will start introducing things like case structures and types of functions and all of the things that are required to know at some point. I've found value in internalizing the most basic syntax as a starting point. I also learn better through conversational writing as references are hooks for memory to latch on to, which is why the tone of this is more casual than most.

Back to the function. It is also true, that this function won't do anything... yet.

One thing that many people find challenging is naming their function! This is common. Using something like "genericFunctionName" or whatever your function is doing is super important for making the mental connection to what is happening with that code block. If you find yourself getting lost in naming just use a generic descriptor for the part of the code like the example above.

Steppin' on the gas

Moving on up to making a function do a thing. Let's get a little more descriptive with the bits and pieces of a function declaration. The word function itself is a special word, keyword, that is used to signify it should follow the rules of that keyword as defined by Javascript the programming language. We need that part.

Next is the name of the function. Gonna do you a sneaky here... functions don't always need names. SHHHHH. That's a later thing.

For now, for simplicity sake, we're going to name our declared function and we are going to use camelcase. (here is a cute image of a camel with text visually depicting camel case in it's humps just in case you're unfamiliar)

Mandatory: always start your function name with a lower case letter

Next we need parenthesis which is where parameters can be passed to the function in our current state of just declaring a simple function.

However in Javascript in general, parenthesis are the booming narrator voice Invocation Operator which will bring your functions to life. Invoking and calling the function mean the same thing. It is effectively running the function.

Lastly, we need a statement or the body of the function which is where the code goes that defines what the function actually does.

You knew it was coming. It's time for the requisite "Hello world!" baby's first output moment.

function nerdJoke() {
   console.log("Hello world!);
}

In the function above we've used console.log as the thing that spits something out somewhere. So far I like sticking console.logs all over the place because I want to see what is happening as I write code.

A quick aside: If you're following along or practicing coding you'll need to be in a place that can run your code. I've been using replit.com as an easy and free tool to do just that.

Now we have a function that can do something! It can say "Hello world!" to a console. If we tell it to. This is another thing that was a challenge for me to wrap my brain around as a newbie. It's there. It's in the code... why can't I see it?

When writing code everything is manual. You're the one making the behind the scenes magic that everyone expects to just happen as users of apps and programs as a consumer.

So we need to call or invoke, or call, the function just by giving some Destiny's Child snaps and a little head wiggle. That's right, "Say my name, say my name." says our little function wanting to be called.

function nerdJoke() {
   console.log("Hello world!");
}

nerdJoke()

Embrace the nerdy 90's humor and say the function name with the parenthesis after to invoke it and voila. Output to the console. Mission accomplished.

Ok ok, that was fun and all but let's step it up a smidge. I never really understood what was so special about saying "Hello world!" in another screen either. Let's make this basic structure work for us.

Are you one of those people that says, "It was my understanding that there would be no math." Guilty. Write functions to do math for you!

function square(number) {
  return number * number;
}

console.log(square(3));

In this example we are demonstrating using a parameter in the function declaration. A parameter is an expected piece of information. Think of it like a placeholder for what may be filled in later in the function.

In the above example we continue the pattern by using the function keyword to start, square is the name of the function, (just because we're squaring the number and that made sense to me but you could have called it uncleGeorge if you wanted to), and then we're leveling up by adding return to the body of our function.

Return is another keyword just like the word function. It is a known word in Javascript that is a very good little keyword that does exactly what it's told right on the spot without any hesitation. In this case return is giving this function something to do by multiplying our two parameters together.

Return is poised and ready as signalled by the number parameter in the first parenthesis and the asterisk * is the operator in this function. Not to be confused with the aforementioned invocation operator or smooth operator or any other kind of operator, really.

There are a LOT of operators in Javascript. You'll learn about them another time. For now it's easy to understand that the standard symbols in arithmetic like + - * / for add, subtract, divide, or multiply work as operators in functions.

But, wait! There's more! What is this? A wild new parenthesis has appeared!? Look at all of those scary stacked up parenthesis with the 3 inside of them at the bottom of our function. That 3 in the parenthesis in our console.log is an argument ...in a good way.

The console.log uses its booming narrator voice Invocation Operator to invoke our function name, square, and the argument, 3, which then takes the place of the parameter in the function.

Stop. Right meow. If you're not completely confident in how this works. Go over it again. Trace your finger on the screen. Say this out loud and go from bottom to top. "Ok, so, square is the function name. 3 is the argument that the parameter, number, was holding a space for. The body of the function says to return number times number and console log said number is now 3. So... the answerrrrr is... 9?" Jackpot.

This illustrates the difference between parameters and arguments. The parameter, number, is returned when the function is invoked and is multiplied by itself as defined by the number * number in the body of the function.

Working through the flow of how a function works is a game changer for it making sense. Channel your inner Mr. Miyagi and wax on wax off this concept until you can catch a fly with chopsticks. Bow

Another fun thing to see in action is that the words in the function could have also been gibberish if you like to be a lil silly.

You're off to a great start with some basic function knowledge. In future volumes we'll explore more function types to get into the real, functionality, of javascript. I'll see myself out.