DEV Community: MxL Devs

Should You Use Password Authentication?

MxL Devs — Mon, 13 Jul 2020 23:41:09 +0000

Today I wanted to sign into a service that I haven't used for awhile, but I forgot my password. So I hit "Forgot Password?", entered my username, and then it sent a password reset link to my email. Fortunately I still remember the password to my email.

I opened up my email, pressed the link, and it directed me to a password reset form where I entered my new password that required at least 8 characters including one uppercase, one lowercase, one numeric, and one special character like $*@&!,

Spoiler alert, I'm not going to remember that password next time either. Chrome asked me if I wanted to store the password, and I said no. I'll deal with password reset again next time.

So this got me thinking about the age-old problem of security: authentication.

What is Authentication

There's already a lot of material out there. I would recommend reading this wikipedia article about it because it's a fantastic start and goes through all sorts of topics.

Basically it's to prove you are who you claim to be. If you walked up to the bank and said you're _______ and wanted to withdraw suspicious amounts of cash from your account, what's stopping the bank from just taking your word?

There are many different strategies involved, and security researchers have come up with three factors that go into the process

what you know (knowledge)
what you have (ownership)
what you are (inherence)

Authentication in Action

So for example today I went to order a Venti Javachip Frappucino from Starbucks. No sponsorship, I'm just a fan, even if it's loaded with sugar.

When it came time to pay, I used my chip-enabled credit card where I entered a PIN to approve the transaction.

This is a simple example of authentication: I have a credit card that's tied to my bank account and only I should know the PIN code for the card.

Of course then they introduced tap-to-pay and suddenly that PIN code just goes out the window for most people if they don't disable it.

Convenience truly is the bane of security.

Why Authentication Matters

It's pretty simple: we all have things that should be private. A bank account, an email account, your computer, your home even. I still use ancient-tech metal lock-and-key which can be easily picked, while some people use like digital keypads (just another password) or more sophisticated things like finger-print scanners, or voice- and facial-recognition systems. Open sesame?

Why Passwords?

You'd think with advancement in technology we'd be able to move on from passwords, but probably 99% of the systems out there still use basic password authentication, whether it's a string you type in to unlock your computer, or that lockpad pattern on your phone.

Personally I don't like passwords at all.

You'll probably write it down somewhere, because who's going to remember all these dumb uppercase lowercase numbers and special characters
You'll probably re-use them, so if someone gets it somehow, all of your accounts can be compromised
You'll probably share it with someone else, who you then have to trust to keep it secret

And especially as a developer, suddenly the stakes are really high: I just want you to be able to have private access to your account; I don't want to have to figure out how to keep your secrets from being leaked.

Alternative to Passwords

Fortunately, the internet has evolved and there are various tools at our disposal. Passwordless authentication had been quite popular and is used in a lot of different services now. SSH keys are a common example that devs probably are familiar with. Then you have fingerprint unlock for your apps which my banking apps offer and are quite convenient.

But outside the technical stuff, you might have come across some passwordless services yourself already like when you "log in with facebook" or "log in with google" and don't need to remember additional passwords. Basically outsource the security to billion dollar companies that probably have more people making sure those secrets will be kept well.

There's a library called passportJS for NodeJS that basically let's you implement authentication with about 500 different strategies easily and I'm sure various frameworks also have similar libraries. If not, might be something you can build :)

But is Passwordless Good Enough?

It's pretty nice to be able to use your google account to authenticate into dozens of services, but what happens if your google account gets compromised? Now all of your services that use that google account are also compromised.

However, that's a risk that the end-user takes on, and not something you - the developer or the business owner - needs to necessarily worry about. Even if hackers find exploits in your system and dump your database, the extent of damage is probably going to be limited to whatever information your users give you, which won't include their passwords that they might be re-using in a bunch of other services!

Personally I would recommend looking into passwordless authentication options and not having to worry about dealing with anyone's passwords or secret questions/answers and so on because it's just less legal stress to worry about and much less technical effort on your part.

Sure, sometimes it might be convenient for me to create a throwaway user account without having to bind one of my throwaway email addresses to it, but maybe this is also a good thing.

But I still want passwords!

(added 2020-07-14)

There are cases where you may choose to offer the option to allowing users to authenticate with a simple password, for example if they don't have access to alternative authentication methods that you've provided.

In this case, the user is trusting you with their password, so you'll have to make sure that you keep it secure! It would be good to read about and follow good password storage practices like hashing and salting the passwords and storing the result in the database. You should never have access to the user's password because that's something you don't, and shouldn't, need to know.

Feedback

Let me know your thoughts about user authentication and security. I don't have a security background so my understanding is quite limited to high-level concepts. Maybe passwordless is also not that great? Are there other forms of authentication that you use, or read about, or have thought about?

Why Good Code Needs Comments

MxL Devs — Thu, 09 Jul 2020 02:58:54 +0000

Sometimes I see devs say things like "good code doesn't need comments". The rationale being, if your code is well-written, it should be self-explanatory to the next developer that's looking at the code.

Actually I used to say that as well, but that was mostly because I was (and maybe still is?) quite a lazy commenter. I thought "how would I not understand my own code?" as long as it's written clearly enough? Don't even get me started on writing design documents or maintaining them, but I'll leave that for another topic.

But at some point I started to appreciate comments, so I'd like to share my thoughts on it by sharing some experiences I've had while writing code, which might offer some insight into why even the best code might benefit from having comments.

Story Time

I wrote an article previously about web scraping. If you're interested in scraping or having issues with getting scraped, might be something to read, but it's not related to this story besides that I write various random tools like scrapers and bots.

In particular, my tools come in different flavours

some of them run on a server constantly listening to web hooks
some of them wake up once every hour or so to poll for data
some of them fire up a browser to navigate a couple pages
some of them transform data from one format to another as part of a pipeline

Basically they all do different kinds of things. They're all tools that are written to solve specific problems, and most of these deal with completely different problem domains. Some of these scripts are about 10-20 lines long, others might be 100+.

I have dozens of these small tools lying around, some of them I've never looked at for years but still in use.

Why Did I Write That Again?

Websites will change. API's will change. Data formats will change.

Basically, requirements change. It's just how things are and you just have to deal with it when it happens. If you're lucky, things might not change that often, but on the flip-side, because it doesn't change that often, you don't look at your code that often either.

Eventually you'll start forgetting details, and one of the most frequent problems I've had when one my tools crashes is I have no idea why my code is doing what it's doing!

How Self-Explanatory is Good Code?

When I look at my code, I know exactly what it's doing, because I came up with descriptive variable, method, and class names. I have spaces after each comma, and good indentation or curly brace placement to make that code look clean and absolutely fabulous.

Indeed, it should be quite self-explanatory what the code is doing, but there are so many things that self-explanatory code fails to explain

Is this code correct?
Why is it written this way?
How should this code be used?
What problem is the code meant to solve?
Are there better ways to solve the problem?

Of course, "what is this code doing?" is an important question as well, but that's just one out of many other important questions that I have when I look at a piece of code.

Beyond My Code

At some point, I started moving away from only reading and writing my own code. I started using libraries. I started using frameworks. I started code-reviewing. I started extending other developers' code.

Not only do I need to understand the problem, I also need to understand how you've attempted to solve the problem through your code. I might be able to understand what your code is doing, but then I might have to put it all together to understand why you wrote it that way.

Most of the time it's not like my 100-liner simple tools that do just one or two jobs, some of these could be massive 100000+ line codebases with hundreds of classes and components written by dozens of developers over the course of many years.

It really can take a lot of time to truly understand what the code is doing, and not having any comments to help explain the purpose of the code can make it that much harder to put things together before you can actually dig in and write something of your own!

We are Problem Solvers

The biggest lesson I've learned in software development is understanding my role as the coder. The code is simply a solution to someone's problem, and there's an entire process that you (or someone else) go through before you arrive at the final solution that will be turned into code and delivered.

By writing comments to explain the purpose of your code and a bit of the thought-process that goes into it, it will greatly benefit the next person (perhaps yourself even) who looks at your code and wonder why you wrote it and how it should be used.

Feedback?

What are your thoughts on comments to explain your code? Are there strategies to good code writing that can allow you to express your thought process without necessarily writing it as comments? I'd love to be able to read a piece of code and understand the big picture behind it since it minimizes the amount of text I'd have to write.

Secure your Data API from Web Scrapers

MxL Devs — Sun, 05 Jul 2020 01:35:02 +0000

I do a lot of data scraping on the web, and one of the first things I look for is an API. Even if the platform doesn't provide a publicly documented API, generally they will probably have some sort of undocumented "private" API to facilitate client-server communication like search queries or other fun AJAX stuff without reloading the page.

In fact, because it's undocumented, there may be a lot of security-related issues that they might not think about, simply because it's not intended to be consumed by the public (but probably more likely, who likes to think about security?)

One thing I've noticed, as a web scraper, is generally how easy it is to make API requests myself.

A Simple Example

Let's say you have a blog or other content system and you wanted to implement a search function, where the user enters a search query and then your server uses it to return a list of relevant results from the database.

The Request

After building your API, you might make a request like this on the client-side:

POST https://api.myblog.com/search

query=scrape&type=tag

Which is intended to return all posts that are tagged with "scrape" in it. And then you proceed to test your API, verify that it works, and commit your code.

Fantastic, job well done. You release your feature, and now you can tag your posts and let people find them using tag search.

The Scraper

So now I come along and I wanted a list of all your posts on your site. Perhaps I want to build my own site that basically mirrors all of your content (think about all those instagram clones) so that I can enjoy some extra traffic without doing any work. All I really have to do is run a scraper periodically checking for new content and then download them to my own server.

To figure out how your site works, I would come to your blog, type in a search query, and hit submit. I would then notice that you make an API request and then proceed to take a look at how the request and responses are constructed:

the headers, like cookies, origin, host, referer, user-agent, custom headers, etc
the body, to see what data is sent
any security features like CSRF tokens or authorization

Then I would replicate this request and send it from my own server, which bypasses CORS because CORS doesn't mean anything if I can spoof the origin. And also because a lot of people probably don't really understand CORS and set Access-Control-Allow-Origin: * on their server anyways because half the answers on StackOverflow recommend it as a solution. Conceptually, it's not that difficult to understand and I highly recommend reading about it, maybe over at MDN.

Some Bad Queries

I would start by trying different things. Maybe try something as simple as an empty string

POST https://api.myblog.com/search

query=&type=tag

Maybe your search engine will match on EVERY tag and then give me everything in one shot.

Or I might try some wildcards, maybe % or * hoping you don't sanitize your parameters (which can potentially open up a different world of hurt!)

POST https://api.myblog.com/search

query=%&type=tag

Solutions???

Generally, depending on what country you're operating in, the law is on your side since your terms of service will include something about unauthorized access to API's. And if you don't, you probably should! But of course not everyone will respect the law, and depending on the kind of data you're working with, sometimes you might want to be a bit more proactive in preventing scrapers from taking all your data too quickly.

Just like how getting your database hacked and exposing millions of customer data would be a massive blow to your business even if you have the right to sue the hackers, you might not want to wait until it actually happens so that you can play your legal cards.

Unlike securing a database, you can't just stop people from making requests to your server. After all, how does one distinguish between a request from your website, and a request from a 3rd party client that I wrote in Ruby or Python or Java or straight-up curl?

I believe the goal in this case is to make scrapers work hard. The harder they have to work, the more requests they need to make, the slower the data collection process becomes, and the easier it is for you to flag it as suspicious activity and then take action automatically.

Depending on the nature of your content, you might for example enforce a minimum character limit and sanitize the inputs to avoid wild card operations on the server-side. Where you do your checks is important because I build my own requests, so any front-end validation is basically useless. Relying on the client to be honest is like giving me the key to your safe and hoping that I don't open it.

Other common examples in other applications I've seen include

limiting the number of requests per time interval (ie: request cooldowns). If your app users aren't intended to make 100 requests a second, don't let them.
Paginating your results. This is a pretty common strategy for various performance-related purposes (for better or worse), but combining it with request cooldowns, it can be pretty nice.
geofencing strategies, where search results are limited based on a provided location which could be the name of a region, or a pair of latitude, longitude coordinates. Might not apply to you, but if it does, really makes life hard for scrapers.
rate limiting, where you impose limits on the number of API requests that can be made before no more requests can be made. This is useful if requests must be authenticated with a token, possibly tied to a user account. This won't be effective if I'm hitting the server directly with the same token that your own client uses.
compile to native code. This one is actually quite effective because unlike plain-old javascript that anyone can read like a book, reverse engineering native code requires more than just some basic understanding of how to use code-beautifiers and browser debuggers. Sure, they can still do it given enough time and effort, but probably 95% of people in the world don't have this kind of skill set.

By effectively using filters and cooldowns, you can force scrapers to work hard to obtain your data instead of just coming in and then walking away with everything in 5 seconds!

Feedback

Are there any techniques that you like to use to "secure" your data from scrapers? Or perhaps it's not necessary for the average app developer to think about?