Welcome to the Patchstack Weekly security update! This is the first Patchstack update for 2022, Happy New Year and let's get into the security news and talk about factors of authentication.
This week I will give a quick roundup detailing the number of vulnerabilities added to the Patchstack database last month and I will give an update on the backlog of unpatched vulnerabilities we are working on addressing.
I will then cover the topic of secrets as it pertains to authentication, and how you can understand some granular points of what makes something secret how to secure your login pages with more than just a password.
I need to start with a quick correction to last week's update. I recommended users of the Shortcode Addons plugin update to 3.0.2, I misspoke and should have recommended 3.2.0 which is the most recent release of this plugin.
In the future, I will simply recommend updating to the most recent release instead of specific version numbers to help avoid this sort of confusion.
In the last month, the Patchstack database added over 100 new reports of vulnerable components in WordPress. These reports included 71 reports from the Patchstack Alliance (formerly Red Team) itself.
Kudos to these researchers who are looking for insecure code and kudos to the team who reviews these reports and reach out to developers who can push a patch and secure sites running their code. It is only when we all work together so well, that sites are protected from attackers.
On the topic of reaching out to developers, we are still stuck with a backlog of vulnerabilities in dozens of WordPress components from last month. This backlog is due to non-communication from the developers, and we are at the point where we must escalate and inform the public. We have even informed the developers that we will be disclosing the vulnerabilities details this week, to which we have received no response, just dead air.
We are currently communicating the issue through side channels privately, to help ensure that most sites are protected before the public release. Some details, such as the name of the vulnerable components and risks of these unpatched vulnerabilities will be released publicly soon.
If your organization would benefit from knowing more about these vulnerabilities before they go public and support the Patchstack cause of securing open-source web applications then please reach out, I would love to chat.
The decision to disclose before a patch is available is not an easy one, but we have site owners in mind and believe being transparent and honest is key. Code will have bugs, and some bugs will be security concerns, what matters here is how the bugs are getting addressed.
Site owners need to know if they are running insecure components, and more importantly, site owners should know if the developer they trusted is ignoring reports of security issues that affect their websites.
If you are paying for the Patchstack app will get these vulnerabilities virtually patched, your sites will be safe. If you are hosted at one of our partner hosting providers, you can feel safe knowing they are also getting details to protect their customers before the details will go public.
When it comes to authentication, everyone is familiar with the traditional username and password combination. I will assume you have set up an account with a website before or used a pin or password to log in to the computer or mobile device you're on right now.
Likely you are securing that device or account with a secret phrase, password, or PIN (Personal Identification Number.) This is security through a single secret or single factor of authentication. While it works for most cases, it has its flaws. Secrets like PINs and passwords can be guessed, brute-forced, or leaked.
This is why many security-conscious services, support two-factor authentication or 2FA. You may be familiar with 2FA already, if you have ever had to look up a 6 digit pin that changes every 30 seconds via an app on your phone, well; that is a popular form of two-factor authentication called time-based token, but it is not the only form!
To understand other factors of authentication. We should redefine what that first factor is. Secrets like passwords can also be understood as knowledge an individual has. The weakness of secret knowledge is if the knowledge is made public or is easily guessed, then it is not considered a secret, no longer is secure, and you will want to update the password to something new, so it is a secret again.
If you prefer an analogy. You can think of the traditional passwords kind of like a combination lock like you may have on your suitcase. Most of us don't rely on combination locks to secure high-value items, like our front doors or on our vehicles.
We instead use something physical, like a key, which offers more protection than a PIN or padlock. That is because keys can not be easily leaked or guessed (but I apologies as this is where the analogy falls short, at least for anyone familiar with locksmithing, or lock sport.)
But I digress ... the point I was going for was that even on the internet, we can utilize physical things, or I should say access to physical things, to offer additional factors of authentication and better protection than just a PIN or passphrase.
If passwords are something only the user should know, then the second factor could be a lot of things: It could be a physical location represented by an IP address, it could be a temporary token either displayed on a personal device or sent to a secondary account or email address, it could even be a window of time restricting access to a login form.
The free Patchstack plugin available on the WordPress plugin repository supports many options of additional factors of authentication. In fact, you don't need to stop at two factors, you could add three, or four factors if you wish to really lock down your login page. Let me share what those factors can be, and what the pros and cons are for each.
Starting with a low-effort, simple option, you can protect your site's login page by obscuring the login form's location. This option is good at protecting websites from the waves of brute-force bots that hammer websites every second trying default login pages with a bunch of credentials.
But, this is essentially a second secret, like a password or pin it is something that is known, and which could eventually get leaked, guessed, or shared with the wrong person. It is a great option for site owners with non-technical users, but not the best option if security is critical.
Another option for sites with non-technical users is restricting login hours. If you only work on a website during your working day, (or inversely, if you only update your website during the evening or weekends) then blocking anyone from accessing the login page during off-hours is a nice feature.
There would be no surprises to wake up one morning to find someone logged in at 3 AM and defaced your whole website. However, this restricting login hours would still allow brute force attacks full access during your approved time window, so this option works best when you enable other factors and not very well as a sole additional factor of authentication.
Time-based tokens are a widely adopted second-factor authentication method. These are the 6 digit pins generated every 30 seconds or so, typically accessed via another device. It is one of the best options for a secondary factor of authentication and is used by a lot of high-security websites.
The caveat is, it requires more technically-savvy users to set up and manage, and if their mobile device ever gets lost, replaced, or breaks it may require nullifying the old token and setting up 2FA all over again. But, perhaps that is the level of security you want. If you perform any sort of commerce or handle sensitive data on your website it is probably the level of security you need.
Finally, you can restrict access to your site's login page based on IP address as well. Which is a fair solution for non-technical users, but somewhat difficult to manage on the site itself. What makes this difficult to manage is the fact IP addresses can change, and regularly do.
You may find yourself locked out of your website unexpectedly and it will take a lot of effort to add your new IP address or range of IP addresses to the approved list. The catch is, you will be unable to log in to the WordPress administration panel to add your IP again.
This option may be good for situations where you can guarantee a static IP address or safe range of IP addresses but does require a lot more technical knowledge to manage and maintain than the other options.
I think that is enough to talk about factors of authentication. I could share more on the subject like biometrics, centralized authentication, VPNs, or beyond corp portals. But, they're not available in the Patchstack plugin and I am out of time.
Let us move on to some thanks and appreciation this week. Starting with you. Thank you for sticking around and learning all about those additional forms of authentication.
This week's thanks go out to all of the developers who patched security bugs in their code last month, and thanks are deserved to the Patchstack Alliance members who found and reported those bugs. Finally, a thank you to everyone putting in an effort to make the web a more secure place last year, you made an impact in 2021, and I look forward to seeing the impact you make in 2022.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security Update!