Protecting your Passwordstate Website when exposing it to the Internet

One of the great advantages of Passwordstate is being able to securely provide authorized employees with access to your password credentials whilst they’re out of the office. This requires your Passwordstate instance to have a connection to the internet which could pose a number of complications and well as potentially increase your organizations attack vector.

How do you make Passwordstate more accessible without dramatically increasing the risk to your organization?

Prerequisites for accessing Passwordstate from outside your Network

Before you begin there are a number of prerequisites that will need to be in place.

First, you’ll need to ensure you have an external DNS entry which directs all HTTPS traffic to your company IP Address.

Next, you’ll need an open port on your firewall which will be used to direct all incoming HTTPS traffic to your Passwordstate webserver. This port is the same one you will have configured for Passwordstate in Internet Information Server (IIS).

It is highly recommended that you purchase a signed SSL certificate from an Online Certificate Authority and assign it to your Passwordstate website in IIS. Whilst Click Studios provides and installs a self-signed SSL certificate with Passwordstate it is not recommended for use over the internet. There are many online companies that provide CA-signed SSL Certificates. The key thing to remember is to purchase it from a trusted source and ensure it matches the URL of your Passwordstate website.

Considerations for Securing Passwordstate when exposed to the Internet

A lot of our customers elect to have their Passwordstate instance accessible over the internet. When planning this you should consider the options listed below. As always, we’d recommend following your own internal risk assessment process as part of a Change Management Plan, to determine if there is any associated residual risk or compensating controls required, for your environment.

  • If you would prefer your employees not to have to use Two-factor Authentication whilst inside your corporate network you can use our Allowed IP Ranges feature. This is located under Administration->System Settings->allowed ip ranges and allows you to specify your internal IP ranges;

Once set, along with the Two-factor Authentication, any access from any IP range not matching your allowed IP ranges will be prompted for the Two-factor Authentication option you have set. Now access from the internet will be differentiated from internal corporate access and ensure that additional authentication is required.

  • As part of good Systems Administration practice, you should look at removing older protocols on your webserver. Passwordstate uses the most secure protocol currently supported by Microsoft IIS, TLS (Transport Layer Security) 1.2. The removal of any older, less secure protocols, will help protect your webserver. There are many toolsets available to assist with this, just search for “enable or disable windows protocols” and pick one that works for your organization.
  • The backups feature in Passwordstate requires an account on your webserver with permissions to upgrade the install files. Some customers make this account a member of the Local Administrators group on the Server, but you can give it less permissions by following the guide under Help->Security Administrators Manual->Passwordstate Administration->Backups and Upgrades->Non Local Administrator Rights for the Backup Account on the Web Server.
  • Under Administration->System Settings->Authentication Options->Web Authentication Options we have 2 settings that apply to Brute Force attacks,

    The fist setting relates to the number of failed login attempts before the active session is locked out. By default, this value is set to 5 however you can reduce this value in accordance with your IT Security Policy. Lowering this value will slow down automated attempts at guessing a login for your website.

The second setting relates to the delay in seconds before returning a message of “Incorrect Username or Password”. If you find that entering a false username takes a shorter amount of time to produce the message, compared to entering a false password, then you can increase this value. This will delay the message by the stated number of seconds, which will help to confuse the attacker knowing which information they have wrong.

  • Click Studios Best Practice approach for securing your Passwordstate instances involves securing your Web.config file. There are two parts to this, encrypting your Database Connection string and encrypting your appSetting Section. Further details on how to do this can be obtained from the following blog entry: https://www.clickstudios.com.au/blog/securing-your-web-config-file/
  • You could consider using a Managed Service Account Consider to communicate with the Passwordstate database server, instead of a SQL Login. Managed Service Accounts have the benefit of being locked down, do not permit interactive logins and are able to automatically negotiate password updates with minimal administration overhead. You’ll find information on how to configure this under Section 14 of our Installation Instructions here: https://www.clickstudios.com.au/downloads/version8/Installation_Instructions.pdf.

As always, we welcome your feedback via support@clickstudios.com.au.

Speak Your Mind

*