As a developer of commercial scripts, two of the most often asked questions are:
- How secure is the site?
- What’s all this about cookies?
When it comes to user authentication, cryptography relies on three principles which can be applied to your authentication scheme in total:
- Who the user is.
- What the user knows.
- What the user has.
Don’t worry, I’m not going to launch into a missive on PGP keys or one authentication scheme over another. Instead, we are going to apply this principle to users of your nifty-super-duper Perl based web product.
Who the user is
This may not seem obvious at first, but some people sign up for websites pretending to be someone they are not. I know … shocking. So the first thing you need to do is ensure who a user is.
There are different ways to achieve this. The most obvious is that you only allow users to have an account when you meet with them face to face and you create the account yourself. Not really an ideal solution.
The second way and the easiest to achieve is to ensure that the user signs up with a valid email account. It’s a better solution, but still not overly compelling.
The third option is what some of the big boys do, force a user to provide a cell phone number. They then send them an activation code via SMS that must be used to complete their registration; in other words, a One-Time Password.
In the real world, however, most of us Perl guys rely on the second option, email authentication. More on that later.
What the user has -Two-Factor Authentication
When we talk about One-Time Passwords (OTP) or Two-Factor Authentication (2FA), we are usually referring to either a customer device or a cell phone application that can generate/display these OTPs. Where I work at my day job, we have a little thing-a-ma-bob that we plug into the USB port of the computer when we are signing in. For large sites on the web, this is where the big boys use apps and customer devices to generate the OTP.
However, I’m going to show you in a later post an easy way to implement your own 2FA using OTP, and you only need a bit of time instead of a big budget.
What the user knows – Password
The password is the weakest link in the whole discussion of authentication. Weak password rules should be something that shames you enough that you start giving some serious thought to this.
Let’s assume this is the available character set for creating passwords:
That’s 58 characters to choose from.
If your website password requirements are four characters from any letter or number, not case sensitive, then there are only 424,270 possible permutations.
If your website password requirements are twelve characters from any letter or number, not case sensitive, then there are 891,794,789,340 possible permutations.
Once you add case sensitivity, those numbers go up to 1,929,501 and 112,992,892,764,570.
When it comes to cryptography, long is always better. Forcing a minimum of twelve characters provides almost 113 trillion permutations – much better than 424 thousand.
My next post will rant about passwords and provide some useful code that you can implement.
One mistake that a lot of noobs make is to rely on a cookie holding a login value after authenticating the user. What I mean is they set something ridiculous like:
print "Set-Cookie: login=true;\n";
Please, don’t ever do this and rely on it to keep nare-do-wells out of your site. Portswigger Web Security offers a suite of products called Burp that will allow a user to intercept and modify cookies … and they’re the good guys!
Imagine what a bad guy could do ….🕵
HTTPS vs HTTP – The final word
Before we get into the mean n’ potatoe posts of this topic, I need to urge you to get an SSL certificate for your web site if you don’t alreay have one. Seriously. They’re are cheap and they are incredibly valuable. If you don’t believe me, just google the topic.
Start with this video:
Now go, code, be happy. 🤓