Day: April 22, 2024

Do you want to add Google Authenticator 2-step verification to your WordPress site?

Passwords alone aren’t enough to ward off hackers and unauthorized users. Luckily, using Google Authenticator 2-step verification can add an extra layer of security to your website.

In this article, we will show you how to add 2-step verification on your WordPress site using the Google Authenticator app.

What Is the Google Authenticator App, and Why Do You Need It for Your WordPress Site?

The Google Authenticator app is a mobile application that adds a second layer of authentication every time you log in to a third-party app or website like WordPress.

Unfortunately, passwords can sometimes be cracked. If you are using the same password on numerous websites, then a security leak on one puts your other accounts in danger. Often, people are lazy, and they don’t change their passwords even after they get an email about a security compromise on a major site.

Well, the 2-step verification is the solution just for that. Even if the hacker knows your WordPress username and password, they will not be able to access your WordPress website unless they have a time-restrained random security code (provided by Google Authenticator).

Because your blog is directly connected to your mobile device, you will be the only person with access to retrieve the unique code for each login. The code expires in a short amount of time for security purposes.

The Google Authenticator app is just one example of a mobile application that provides two-factor authentication (2FA) for various online accounts and services.

It generates time-based one-time passwords (TOTPs) that serve as the second factor for authentication when logging into an account.

If you still aren’t convinced about the importance of WordPress security, then you should probably see how one of Wired.com author’s digital life was destroyed.

After reading that story, we jumped on board with the 2-step authentication for our Google accounts and most other services that offer this feature. If you are as security-conscious as we are and you value your blog, then you should follow this tip to improve your WordPress security.

To further improve your security, we recommend looking at other methods as well. For example, software like 1Password can help you manage your passwords in one place and ensure they are strong enough to withstand potential hackers.

With that said, let’s jump into the tutorial on how to add Google Authenticator 2-step verification to your WordPress site.

How to Add Google Authenticator in WordPress

The first thing you need to do is install the Google Authenticator app on your phone. We are going to use the iOS terminology for the sake of this tutorial, but the process is similar for other devices as well.

Step 1: Install Google Authenticator App on Your Mobile Device

Visit the App Store, search for ‘Google Authenticator’, and then click on ‘Install’ for the application.

Now, let’s get back to your WordPress dashboard.

Step 2: Install MiniOrange’s Google Authenticator Plugin

Go ahead and install and activate the MiniOrange’s Google Authenticator plugin. For more details, you can see our step-by-step guide on how to install a WordPress plugin.

This is a free WordPress plugin that helps protect your site from unauthorized access. Every time you log in to WordPress, you’ll be asked to enter the one-time passcode from the Google Authenticator app to verify your identity.

Upon activating the plugin, you’ll be taken to a setup wizard. Just follow the process to set up your Google Authenticator two-factor authentication in WordPress.

Step 3: Complete the Setup Wizard

Start by clicking on the ‘Let’s get started!’ button.

Next, you will be asked whether you want to set up 2FA after your first login or within the plugin dashboard. Either method is fine.

Click ‘Continue Setup.’

The next step is to choose who you’d like the 2FA to apply to. You can either select all users for maximum security, or you can only have it apply to certain user roles.

Then hit ‘Continue Setup.’

Lastly, you’ll be asked whether or not you’d like to directly enforce 2FA immediately or give users a grace period.

If you choose to give users a grace period, then you can select how long that would be in hours and days. Once that is complete, click on ‘All Done.’

Now that you are done with the setup process, you can decide whether you want to set up 2FA for yourself now or later.

Go ahead and hit the ‘Configure 2FA for yourself’ button.

From here, you’ll be asked to enter the method of 2-factor authentication you’d like to add to your WordPress site.

For this tutorial, we will choose ‘Google/Microsoft/Authy Authenticator.’ Then, just hit the ‘Save & Continue’ button.

Next, you’ll be asked to scan the barcode on the screen. That means you’ll have to pull up the Google Authenticator app on your phone and scan the barcode displayed.

In your Google Authenticator app on your mobile device, hit the ‘+’ icon at the bottom and then select ‘Scan a QR code.’ Then, point your phone camera to your computer screen to scan the barcode.

From here, a one-time passcode (OTP) will appear on your mobile device.

Type that into step 2 on your computer. From there, you can click on ‘Save & Continue.’

Now, you should receive a message that says that you’ve successfully configured two-factor authentication.

Simply select ‘Advance Settings.’

Step 4: Add Security Questions

In addition to adding Google Authenticator 2-factor authentication, you probably want to also add security questions as well.

If you can’t access your Google Authenticator app, then you can still log in to your WordPress website if you answer the security questions that you’ve set up for yourself.

You’ll need to head over to the Mini Orange 2-Factor » Two Factor page in your WordPress admin dashboard. Then, in the Setup 2FA For Me tab, find the Security Questions method and click on ‘Reconfigure.’

Keep in mind that you can also set up other types of two-factor authentication methods, such as email verification, OTP over SMS, OTP over email, OTP over Telegram, and even Duo Authenticator.

Next, you’ll be able to select up to three security questions. You can select two of them from a dropdown menu, and the third will be a custom question that you can come up with on your own.

Then, type in the answer for each of them and hit the ‘Save’ button.

Step 5: Test It for Yourself

Once everything is set up, you can test it out yourself.

Simply log out of your WordPress dashboard and try to log back in.

You will now be taken to a page where you can either answer security questions or use the Google Authenticator to enter your one-time passcode.

Go ahead and select the ‘Google Authenticator’ option.

On this screen, you will be asked to enter your OTP from your Google Authenticator app.

Type in the code and then click ‘Validate.’

Now, you will land back into your WordPress admin dashboard, as usual.

Lastly, we recommend that everyone turn on 2-step verification on their Google accounts. You can also configure that with Google Authenticator, as shown in this tutorial.

We hope this article has helped you add Google Authenticator 2-Step verification to your WordPress website. You may also want to check out our article on the most common WordPress errors and how to fix them or our ultimate guide to boost WordPress speed and performance.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post WordPress Security Tip: Add Google Authenticator 2-Step Verification first appeared on WPBeginner.

If you tend to follow React stuff, you might know that React has a new thing called “Server Components”. Mayank has an excellent blog post about them. It starts out with calling out the nice things about them, and then fairly calls out all sorts of not-so-good things about them. Me, I think it’s all weird as hell. Just the fact that React was “just a UI library” for so long now needs a Node.js server behind it to take full advantage is a heck of a leap. And it’s already gone so far that you have to say "use client" when you want a component not to be a server component? (But actually it means: “it’s both a server component and a client component”). Ooof.

I’d link you to the docs for Server Components, but there aren’t any. There is just an update blog post, and little mention in the Bleeding-edge React frameworks section:

These features are getting closer to being production-ready every day, and we’ve been in talks with other bundler and framework developers about integrating them.

So if you want to use them, you may only do so in Next.js. If you’d like to build them into your framework, you hold your breath until the React team reaches out to collaborate. Maybe that’s a little unfair, but I don’t see what you’d read to get started with it all, aside from trying to dig through Next.js code and see how they did it. We use Next.js here at CodePen so we’ll be able to take advantage, I just think it all feels strange.

Next.js is an ultra popular way to use React. So if you just happen to be using Next and staying up to date, you’re using Server Components. That might be advantageous to you. That’s frameworks at their best, really. You do very little, frameworks evolve and you take advantage of the magical things they do behind the scenes. But reality has shown that framework upgrades can be painful. Rarely are there major version upgrades that don’t require work due to incompatibilities. One casualty of this Server Side Components changeup is most of the CSS-in-React landscape.

Josh Comeau has a solid deep dive into this situation. It’s ultimately a pretty simple problem with no real solution at the moment for some of the libraries, like styled-components, arguable the biggest player:

The fundamental incompatibility is that styled-components are designed to run in-browser, whereas Server Components never touch the browser.

Internally, styled-components makes heavy use of the useContext hook. It’s meant to be tied into the React lifecycle, but there is no React lifecycle for Server Components. And so, if we want to use styled-components in this new “React Server Components” world, every React component that renders even a single styled-component needs to become a Client Component.

It’s not the end of the world because, well, if you use them your stuff will need to be client-side only like it already is.

Just to prove what a smart, forward-thinking, attractive, good-smelling person I am, I’ve long been a fan of CSS Modules, and they have no such problem, as they don’t promise to do dynamic things that only JavaScript can do, it’s largely just a scoping API. Likewise, any other of these CSS-in-React libraries that promise “Zero-Runtime” are in good shape. That was really the way to go all along, if you ask me. Styling choices shipping as static CSS is with the grain of the web in a good way.

React is evolving in other similarly massive ways as well. Adrienne Ross has a pretty great rundown in Get your codebase ready for React 19. The massive thing is that it’s going to be a compiled framework (!!!!?!). So totally gone is the “it’s just a UI library” situation that was never really true but now is extremely very not true. While it’s a massive change for React itself, I imagine it won’t be a massive change for developers. People developing with React are almost certainly using a build process anyway and the React compiler will become a part of that. If you’re on the Next bandwagon, surely it will smurf its way into that pipeline. Maybe it will only be available in Next?! I’d say that sounds wild, but since that’s literally what is going on with Server Components, it almost seems likely.

Svelte feels like the first major framework of this generation to require a compiler, and by and large I think people applaud it. It makes client side bundles smaller and it makes authoring work easier. Easier, because you aren’t responsible for figuring out specific details when the framework needs help being performant. The use of useMemo and useCallback in React are performance-specific hooks that if you aren’t using or using incorrectly are hurting your application. That sucks. The fact that you don’t have to think about them anymore with a compiler is a welcome upgrade.

What I’d like to see, and I know there are many who agree here, are client-size bundles sizes actually coming down. In that first article I linked up, Mayank noted that despite Server Components existing now, JavaScript bundles headed to the client are increasing. Again, that sucks. I’m sure the story is very different in fully fleshed out applications that can take big advantage of Server Components than it is for a Hello, World scaffold, but still, we want them coming down across the board.

React is such a monster player on the web right now, I think of it in the Too Big to Fail category. Whatever whacky choices they make, developers will just fall in line. Companies write checks for developers that know React, and the job market sucks right now, so the pressure is even higher to know React. Perhaps even force yourself to love it.

Technologies do tend to come and go. I’m sure we all have our own examples of web tech that was once big and is now all but gone, or at least gone from good graces. But when tech gets big enough, it tends to not go. WordPress is huge, and it’s been huge every second of my entire web dev career. To me it echos social media in a way. In the middle days of Facebook, it’s demise was often predicted. Friendster died, after all. MySpace bit the dust. Google+ came and went. People are fickle. So too will Facebook die and be replaced by the new and shiny. But it didn’t, and it’s demise is no longer predicted. It’s too big to fail. So too is React.