Hiding your admin

The default ProcessWire admin URL is domain.com/processwire/. If you want to hide the location of your admin URL, you can rename it. You have the option of doing this during the installation process. You can also do it from the ProcessWire admin. Here's how:

  1. Login to your ProcessWire admin. In the page tree, click and edit the Admin page.
  2. Click the Settings tab and change the Name field to something different. After changing it, save.
  3. You will get a 404 error–this is normal, because your admin no longer lives at the previous URL.
  4. In your browser address bar, enter your new admin URL and you are good to go.

Preventing dictionary attacks

You'll be glad to know that your ProcessWire admin login is secured automatically from dictionary attacks by the Session Login Throttle module, which is installed by default. This module throttles repeated login attempts, preventing the same username from being attempted for login more than once in 5 seconds. Every failed login attempt increases that waiting period exponentially, making rapid-fire dictionary attacks nearly impossible.

You can further lock down the settings of this module by configuring it (in Modules > Core > Session > Login Throttle). If your admin doesn't have simultaneous users coming from the same shared IP address, we recommend checking the box to enable throttling by IP address. When checked, not only will attempts for the same username be throttled, but any attempts (regardless of username) will be throttled by IP address as well.

The only reason that we don't have this "throttle by IP" box checked by default is because some clients have multiple users coming from the same IP address. In that instance, one person forgetting their password could temporarily prevent other people from logging in.

Install an SSL certificate and require https for your admin

Web traffic is inherently insecure and everything sent to and from the server is unencrypted. This includes any login information you use to get into your admin, as well as cookies used to maintain your session. By installing an SSL certificate, you drastically reduce the potential for this information to be intercepted over the network by 3rd parties. As a result, installing an SSL certificate is one of the best security upgrades you can make for your site.

Once you've got an SSL certificate installed on your server, you need to make sure that it is put to use. At minimum, we recommend locking down your "admin" template to only allow https traffic. However, make sure that your site is accessible via https://yourdomain.com before you do this, otherwise you could lock yourself out of the admin.

Once confirmed that your site is accessible via https, login to your admin (using the https URL), and do the following:

  1. Click "Setup" then "Templates" (click the Templates label rather than a specific template).
  2. Click the "Filters" box, then "Show system templates", and choose "Yes".
  3. When the page reloads, you'll have a "System" section where you will see an "admin" template. Click "admin".
  4. Click the "URLs" tab and scroll to the "Scheme/Protocol" section. Click "HTTPS only" and Save.

Keep track of logins

A good security practice is to keep track of who is using the ProcessWire admin. It can be helpful to keep track of both successful and failed logins, and may serve as an early warning when someone is snooping around. You can access the built-in session log via Setup > Logs > session.

If you'd like more information or options than what the default session log includes, take a look at the Login Notifier module by Ryan Cramer or the Login History module by Teppo Koivula.

Don't install the "forgot password" module unless you need it

ProcessWire comes with a module called Process Forgot Password, which can be installed in your admin under Modules > Core > Process > Forgot Password. This can be very handy for many installations. But if it's something that your installation doesn't need, then don't install it.

While we've gone to great efforts to ensure our forgot password module is secure (and in fact, more secure than any other we've seen), it still involves emailing the user a time-limited link to reset their password. As you may already know, email is not the safest way to transport confidential information, so limiting what can happen with email [when you can] is worthwhile.

It's worth noting that ProcessWire's forgot password function only works if the session that requested the reset is the same session that clicks the email link and performs the reset. That provides an additional layer of security over other password reset functions that we've seen. But if your email account is compromised, then all bets are off: your ProcessWire password then has the potential to be compromised as well. So if your site doesn't absolutely need a forgot password function, then don't install it.

Choose strong passwords

This goes without saying, but regardless of how well your admin URL is hidden, you should make sure you (and any other ProcessWire user accounts) have good passwords that aren't used elsewhere.

Comments

  • Michael van Laar

    Michael van Laar 9 months ago 10

    The only downside of securing your admin via https while the frontend has to be accessible via http only (a seldom use case, I know): Your backend login is not automatically recognized by your frontend.

    • ryan

      ryan 9 months ago 00

      Michael, see the $config->sessionCookieSecure option:
      http://processwire.com/api/ref/config/#api-sessionCookieSecure

      If you set that to 0, your session should continue working between http and https switches. Is there a reason not to allow https on the front-end?

  • Michael van Laar

    Michael van Laar 9 months ago 00

    Thank you very much, Ryan. I already thought that there must be an option, but I haven’t had the time to investigate.

    To answer your question: Yes, there is a reason why the frontend of the project I’m working on is not secured using https. On a lot of pages, forms are included as iframes. The form pages are made with Marketo, a marketing automation system. These Marketo pages are served via their customers’ domains. But since the subdomain you set up for the Marketo landing pages is a CNAME record, you can only access the Marketo pages via http. Unless … the Marketo support team installs their costumer’s certificate on their server. They offer this service – but for a … let’s say not really cheap price.

    That’s why we chose to stay with the http Marketo pages, at least for now. But this also means that we only hate iframes served via http. And this means that we can’t secure the surrounding pages with https without having security warnings because of the insecure iframes.

    Not nice. But while writing this I just have an idea how I could solve this. ;-)

Post a Comment

Your e-mail is kept confidential and not included with your comment. Website is optional.