Forem: Stephen

Password Security: A bit deeper dive into Hashes, Salts, Bcrypt and Node's Crypto module.

Stephen — Fri, 12 Nov 2021 02:46:15 +0000

As I finished much of the administration portion of the current project I'm working on, I started to explore possible solutions for authentication within the app. I spent a good portion of last month going through a tutorial series made by Zach Gollwitzer (link to it on freeCodeCamp's youtube page as well as the playlist Zach's own youtube channel). The tutorial seems pretty comprehensive, it begins with a review of using Express middle-ware, because moving forward, you use lots of middle-ware throughout the rest of the series. The series then moves on to using PassportJS, the Passport Local Strategy and Sessions, and then to using PassportJS with Javascript Web Tokens (JWT) with Passport and then to JWTs by themselves in an angular front-end. I didn't actually go through the very end, which was the part where you implement a JWT in a Angular front-end because I wanted to get back to working on my own project. Transitioning back, I had to think about how I wanted to implement a user authentication system. Did I want to use Passport-Local with sessions? Did I want to use JWTs? I decided to go with what I found easiest while following along with the tutorial, which was using Passport Local and sessions, especially since this is the first time I'd be implement authentication and because I want to get this project done with.

In Zach's course, he used NodeJS' built-in 'crypto' module to produce hashes and salts. Admittedly, I followed the tutorial and just let the magic happen without trying to understand what was actually going on because I wanted to understand how passport worked. In my own research that followed, I found that many developers seemingly preferred the bcrypt standard as opposed to Node's crypto module. A google search will send you down multiple rabbit holes comparing the pros and cons of using Node's Crypto module, or one of npm's bcrypt packages (there's a version that hooks into the V8 engine's C++ underpinnings, while there's another that is totally written in JS and can be run in the browser). So here's some of the advantages of using Node's Crypto Module or Bcrypt that I gleaned:

Bcrypt Advantages:

Seeming industry standard and widely accepted
bycrypt npm package drills into V8's C++ underpinnings, more performant
bcryptjs is javascript from the ground up, and can be used in the browser (for whatever reason)
the bcrypt modules parse salt and hash automagically and only requires one db table column

Node Crypto Module Advantages:

Built into Node, no reliance on dependencies that could one day inject malicious code
No need to install
I'm already familiar with it 😁

In the process of learning more about bcrypt, I learned more about how hashing and salting worked by watching a number of great and informative videos on the topic. I'll attempt to briefly explain it in my own words in the next section.

Hashing and Salting: a quick and dirty primer

If I could explain what hashing and salting is in my own words (because, it turns out it's a beautifully thought out method of password protection and authentication):

A password is first hashed using a hashing algorithm. Algorithms like blowfish and argon2 associate a random set of characters to a given word or string of characters (in the case of a user, a password). After the assignment of those random characters (in the case of bcrypt, 31 characters represents a given entered string), the actual password is lost forever, and whatever the user enters is converted to a hash and compared to the hash that was stored in the database after their initial database entry. If the two compared hashes match (the initial passwords hash will always look like that even if the password is forgotten), the user is granted access because they entered a string of characters whose hash equivalent matches the stored hash in the database.

While this solution itself is clever and elegant, there's an underlying inherent problem; if the password is too simple, a simple word or number combination, or even a word and combination (such as 'BuffaloBills99' or 'NWO4Life'), the corresponding hash may already have been discovered by hackers generating whats called rainbow tables using dictionaries of words and concatenating digits at the end. If a system is hacked, and malicious parties obtain the database with these simple hashes, they could match at least a few of the entries using rainbow tables because there are at least a few users who will, unfortunately enter easily cracked password entries. Along with that, there may be users who use the same password, which would, in turn, generate the same hash value, and if a hacker or malicious party figures out that hash value for one, they could search the whole password hash table for matches.

The solution to adding complexity to a given hash by default is by adding a salt, another random set of strings to the hashed password to derive a new hash. Ideally, each password hash would have its very own random salt paired it to create individually unique hashes so that even if there are multiple matches among the first round of hashes, those matches would be obscured by the newly given salts. While its necessary to record the explicit salt paired with each password hash, and the salt is known to anyone who accesses the database table, a malicious party would have to first un-salt each salted hash to even start seeing matching hashes. This may sound like a worthwhile task, but what if the password table contains millions of rows? And the malicious party may still not be able to figure out what the unsalted hashes mean even if there are matches! Remember time is a resource we can't get back!

So, anyways, the way Node's Crypto and Bcrypt/BcryptJS handle hashes is a bit different between their two paradigms. Node's crypto produces a salted hash and the salt, requiring the developer to make two database columns to store each, while the bcrypts return a value with the combine salted hash and salt, and bcrypt has its own methods that can use the integrated salt value to unsalt the salted hash value. This in turn requires a single table column in a given database.

A given bcrypt method produces a bcrypt hashstring in the following format:

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
\__/\/ \____________________/\_____________________________/
Alg Cost      Salt                        Hash

Source: Wikipedia

Bcrypt produces a string where the salt is 22 characters long and the (salted) hash is 31 characters long, along with a few characters that indicate the precise algorithm being used and the 'cost' (or how many times a salt string is randomized/salted?... I'm still a bit murky on understanding that).

While, again, the node-crypto module, provides individual hash and string values that you can conveniently store in two columns of your preferred database:

The hash value is 128 characters long, above, so it couldn't be all be shown on screen.

Two distinctive ways to handle the same problem, with bcrypt's being a bit more clever, at least in my opinion.

This is a coding blog afterall...

I guess I could share some comparative samples of code used to generate the hash and salt using a bcrypt and crypto npm module. The crypto sample is from tutorial I wrote about earlier, and the bcrypt sample is from a little node project/sandbox I conjured up this past Sunday to better understand how bcrypt worked without mucking up my current main project:

const bcrypt = require('bcryptjs');

async function hashesString(userInput) {
    const password = userInput
    const saltRounds = 15;

    const userInputHashed = await bcrypt.hash(password, saltRounds)
    return userInputHashed;

}

module.exports.hashesString = hashesString

The bcrypt module provides bcrypt.hash() (also bcrypt.compare()) methods that you can nest within async functions so that the server can do other things while all of the computationally intensive hashing rounds happen.

I then imported that async function to the file holding the relevant route (in this small project, I just put the routes in app.js):

const { hashesString, passwordCheck } = require('./bcryptUtil');

app.post('/submit-form', (req, res) => {
    const userInput = req.body.string;
    hashesString(userInput)
        .then((output) => {
            console.log(output);
            res.send(JSON.stringify({ output: output }))


        })
        .catch(err => console.log(err))
})

Now for the code from the authentication tutorial I followed:

const crypto = require('crypto');



function genPassword(password) {
    let salt = crypto.randomBytes(32).toString('hex'); 
    let genHash = crypto.pbkdf2Sync(password, salt, 10000, 64, 'sha512').toString('hex');

    return {
        salt: salt,
        hash: genHash
    }
}

The hash generation functionality within the crypto module is a bit more involved, here's what the parameters are for the method:

crypto.pbkdf2Sync(password, salt, iterations, keylen, digest)

Where password is normally the string input entered by a given user, salt itself can be derived by another method (in the above code its created using the crypto.randomBytes method, 'iterations' are seemingly the crypto module's equivalent of asking for the number of rounds, 'keylen' allows the developer to determine the length of the resulting hash, and 'digest' seems to be the algorithm used to generate the hash.

Here's genPassword being used in a route method, my comments and all:

const genPassword = require('../lib/passwordUtils').genPassword


router.post('/register', (req, res, next) => {
    const saltHash = genPassword(req.body.pw);
    /*^ passes collected password to genPassword from passwordUtils*/

    const salt = saltHash.salt;
    /* ^Holds value of salted saltHash 
        returned from genPassword */

    const hash = saltHash.hash;
    /* ^Holds value of salted and hashed 
        saltHash returned from genPassword */

    const username = req.body.username;

    const admin = false;

    let newUser = new User(

        username,
        //^takes username value entered from form
        hash,
        //^stores salted and hashed password
        salt,
        //^stores salted password
        admin
    )

    newUser.save()
        .then((newUser) => {
            console.log(newUser)
        });
    //save is a method for the database
    res.redirect('/login'); //redirects back to login page
});

The method above may look longer but it does much more than the bcrypt post method; as opposed to just console logging the hash, here, the username, hash, and salt could be sent to the a database (the method also console logs the new user info because dev environment), and then the server redirects the browser to the /login route.

In Conclusion...

So if it isn't clear to you yet, I might have written this article to explain how hashes and salts work, as well as to try and figure out whether to use bcrypt or node's crypto module to do the hashing and salting in the project I'm currently working on. To be honest, I still can't pick one. I'm more partial to crypto, and yeah, it's dependencies don't have the magic ability to become malicious one day because it's built into node. But bcrypt, bcryptjs, to be precise, seems a bit easier to use. So the stalemate continues. I at least hope that you, the reader, come out of this with a better understanding of how passwords are normally stored in databases.

If you'd like to take a look at the little experimental sandbox I put together, here's the link. Here's the link to my implementation of Zach Gollwitzer's code throughout his authentication tutorial which I linked to above. I used MariaDB instead of MongoDB because I think relational databases are cool too.

**This post is also up on my wordpress blog at bxbytes.com. Link here.

PUT vs. PATCH: A Conceptual Dive into their Differences.

Stephen — Tue, 09 Jun 2020 12:21:52 +0000

Intro -- Staring down HTTP method the rabbit hole

Last week, while meeting (over Zoom) with my morning discussion group from the Flatiron School, we found ourselves looking at a list of HTTP verbs to try and match them with their respective CRUD (create, read, update, and delete) actions. We found that two verbs, at first glance, could both fulfill update duty for a web application, so we decided to take a deeper look, even if it was for five minutes.

POST method, Hyper Matter Transport Protocol, circa 24th century

The most alert among us (it was about 9:30 AM) quickly skimmed stack overflow threads on the topic aloud. The prevailing summary we gathered from our brief google excursion was that PUT is used to just update a whole file, while Patch is used for updating only specific portions. Upon looking for a good enough description, I found this:

With PATCH... the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.
Source: https://stackoverflow.com/a/21661036/5456075

Of course, that couldn't be enough for me. I wondered further, "which came first? PUT or PATCH? Is PATCH some old HTTP verb from the 90s?"

Of course I'll write a blog that requires me to read Internet Engineering Task Force specification documentation!

What I found

I decided to go straight to the primary source of information regarding the PATCH verb, the PATCH proposal documentation from the Internet Engineering Task Force, where I was able to confirm (based on what a group mate previously told me) that the PATCH verb was a recent addition to the Hypertext Transfer Protocol, the method was proposed in March 2010, long after many in the most developed nations have moved on from slow dial up connections could have reaped benefits from a seeming incrementally updating feature. By contrast, the PUT method was proposed in 1999 (here is a great Quora response that cleverly answers the difference between PUT, POST and PATCH).

A big difference between PUT and PATCH is that the PUT method is idempotent, or that, every instance of a given data update via PUT method will be the same (an example would be mashing a submit button that sends the same data in a put request... the data can be sent 100 times and it will be the same). That's a clear difference to the nature of the PATCH method, which allows updates to a specific part of a larger resource. While PUT always overwrites a whole resource, and an instance of an update doesn't change, every instance of a PATCH request doesn't have to be the same, or idempotent.

The nature and resulting problems with using PATCH

Lacking the necessity of being the same, there comes other inherent ramifications to using a PATCH request as opposed to a PUT request. Because there are formats and standards to send data, application of a patch method is inherently non-universal. In plainer english, in almost every differing format of data, a developer will have to come up with a new wheel design to update a small part of that resource using patch. While it might be easy to change send a key value pair in a JSON collection, it might be much harder to try and change a line of text stored within a blob in a relational database table.

An example of a PATCH request being shorter than a PUT request by sending specific data. From https://stackoverflow.com/a/21661036/5456075

A developer also has to weigh the risk that, with making custom headers and means to patch an update to a given type of resource, the resulting PATCH method might be bigger than just using a PUT method that simply overwrites the whole older version of a resource. Other potential horrors awaiting a developer if they attempt to implement a system utilizing PATCH updates include:

Potential staleness of requests (if a newer request reaches the server before the older one).
Malformed, or improperly formatted, patch documents (possibly as a result of lack of a universal standard formatting for the patch method).
Servers improperly configured to support PATCH requests.
Finally, the incremental/piecemeal nature of PATCH requests makes it easier for bad actors to gradually send malware such as a virus that can gradually be "patched" together on a receiving server (it's much harder to do this with PUT and POST requests).

Of course, these are all downsides if a developer wants to build a solution from scratch. As I learned recently, frameworks such as Ruby On Rails utilizes PATCH requests effortlessly because of the collective brainpower that goes into developing solutions of that scale.

Conclusion -- And Thinking Fourth Dimensionally

Don't worry Marty, tracks will be there in 100 years

So, why care about the differences of PUT and PATCH? Why care about how it's implemented if it's already utilized in frameworks like Rails, I won't ever care to know the difference! Maybe you won't, but the method was only proposed in 2010, it's been around for a short amount of time compared to other HTTP verbs. When PUT was first introduced, it took time for its usage to be adapted because of the perceived overlap it shared with POST, but now, the two are used for separate and important concerns. The reason why I wondered if PATCH was a holdover from some bygone era involving 56k modems was because of the potential for the method to send small amounts of data, something that would speed up internet communication for users using low bandwidth or unreliable connections. In the west, we may have moved away from 2g and 56k modems, but the developing world is only now getting access to relatively expensive, data capped connections to the internet.

While users in the developed world can wave off such considerations of importance and savings of data utilization, developers have to consider the problems and frustrations users in the developing world face. The internet of the near future cannot always be about transferring Cadillac sized requests between client and server, and considering more specific and concise requests will be ideal.

Sources

MDN: PATCH
StackOverflow: What is the main difference between PATCH and PUT request?
Quora: What is the difference between the PUT and PATCH requests in HTTP? Response by Aaron Evans
Youtube: Idempotency in Cows And Rest APIs