Hardening Passwordstate from Within The UI

When asked about recommendations for hardening Passwordstate we’ve never really had a single point of reference for customers.  This blog has pulled together the responses previously sent to a number of customers and consolidated it for the first time.  Customers should understand that not all of these recommendations may be appropriate for they way in which they use Passwordstate. 

Each of the suggestions should be considered, and if applicable to your business, assessed formally via an internal risk assessment and approved via a change submission before being implemented. 

Encrypt Your Web.config Files!

Yes, this isn’t performed within the Passwordstate UI, however it is a fundamental best practice approach for securing your Passwordstate instance.  It ensures that should anyone have access to your Web Server’s file system they can’t use the details of the Web.config file to access and retrieve your Password Credentials.

The process of encrypting your Web.config is straight forward and details on how to perform this encryption can be found in our General Installation Instructions.  Theses can be found on our website under Support->Documentation->Installation Instructions,

You should encrypt the Database Connection String and appSettings section of your core Passwordstate Web.config file.  If you’re using our App Sever or HA (High Availability) Module you should encrypt the Database Connection String and appSettings section in the Web.config files for those as well.  If you’re using our Password Reset Portal subscription, you’ll only need to encrypt its appSettings section.

While the detailed instruction for each can be found in the corresponding Installation Instructions document, the approach is easy.  All you’ll need to do is open a Command Prompt with administrator privileges on each of the webservers running the core Passwordstate or optional App Server, HA or Password Reset Portal modules,

  • navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319,
  • type in aspnet_regiis.exe -pef “connectionStrings” “c:\inetpub\passwordstate” and press enter.

This will encrypt your Database Connection String.  You should then encrypt your appSettings sectionby,

  • typing aspnet_regiis.exe -pef “appSettings” “c:\inetpub\passwordstate” and pressing enter.

You’d also do this for each App Server, HA Server and the Password Reset Portal Server.  Note you’ll be changing the location of c:\inetpub\passwordstate to the correct locations on each of those webservers.  After each one you’ll need to stop and restart the relevant Windows Service. 

2FA for logging into Passwordstate

Using 2FA (Two-Factor Authentication) allows you to implement an additional level of protection when accessing credentials and data stored within Passwordstate.  You can use this as part of the primary authentication for all users, or in conjunction with SSO (Single Sign-On) for select users.

Click Studios recommends that if you are using SSO (Passthrough AD Authentication) selected as your System Wide Authentication option then don’t apply an additional 2FA option to all users.  It will frustrate them and defeats the purpose of implementing SSO to Passwordstate.  You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts.

In these cases, you can implement the additional 2FA as part of a User Account Policy applied to specific Security Groups.  Just consider the implications as they relate to inappropriate access to highly privileged or sensitive accounts and restrict that access accordingly.

Use 2FA for Emergency Access

Following on from the concept of applying an additional 2FA for users that need access to highly privileged or sensitive accounts, look at configuring this for access to your Emergency Access account.

The Emergency Access account is highly audited and access to it can be restricted to a specified list of Security Administrators under Administration->Security Administrators.  You can configure the requirement for 2FA with OTP (One-Time Password) to further protect the Emergency Access account and subsequent access to your Passwordstate configuration.

Define Allowed IP Ranges

You can specify the IP ranges that Passwordstate is accessible from, that the Emergency Access account can be used from and where the API (Application Programming Interface) can be initiated from.  These are configured under Administration->System Settings->allowed ip ranges,  

You can also state the behaviour when Passwordstate is tried to be accessed outside of the stated Allowed IP Ranges.  This can range from denying access to additional methods of authentication.

Ensure Brute Force Detection is Enabled

Brute Force Detection works by monitoring for failed login attempts from the same IP Address and username combination.  Once these reach a predetermined number of failed login attempts the corresponding IP and Username is blocked from trying to login to Passwordstate. 

You can configure the maximum number of failed attempts under Administration->System Settings->authentication options->Web Authentication Options,

You can also delay the error message response to make it harder for an attacker to determine if the error is related to an incorrect username or password.

Use Feature Access to Restrict Access (to Features)

Using Feature Access allows you to grant or deny access to multiple features and menus.  This would ideally be done by specifying Security Groups, however you can also set this on individual user accounts.  The options are extensive as highlighted in the image below,

To define access to any of the features simply navigate to Administration->Feature Access and select the tab you want to set access for.  The image above shows the mobile tab where you can set permissions for users allowed to use the native iOS and Android mobile apps.

Specify the Functional Roles Used

Introduced in Passwordstate V9 Build 9493, Authorized Web Servers for the core Passwordstate product and any instances of the App Server, can have specific Functional Roles defined.  There are 7 main roles that can be defined, allowing customers to offload intensive processing associated with these roles to another webserver in your farm,

Click Studios recommends that customers deselect any Functional Roles not required for their Primary, High Availability and App Server instances.

Consider Security Administrators and the Roles they Hold

This one requires careful consideration before enacting.  In large organizations with a correspondingly bigger IT department, you can have the luxury of segregating the Administrative Roles within Passwordstate to multiple Security Administrators.  This ensures that no one individual has the ability to change all areas within Passwordstate.  In smaller organizations you may be forced, out of necessity, to provide more roles to fewer or even 1 Security Administrator.

To define the Administrative Roles within Passwordstate to a Security Administrator simple navigate to Administration->Security Administrators, click on the Administrator and select the roles you want to grant them.

Note, a Security Administrator cannot make changes to their own account, or a security group they are a member of.  Any changes need to be performed by another of the Security Administrators defined in Passwordstate.

Consider Using a Managed Service Account

This relates to database connectivity for Passwordstate.  Both Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA) effectively use an Active Directory account for service-related tasks while easily keeping that account’s password secure. 

MSA accounts cannot be used to log into a machine, have rotating passwords that are managed by the domain, and cannot be locked out.  Group Managed Service Accounts provide an even higher security option for non-interactive applications/services/processes/tasks that run automatically but need a security credential.

By using and MSA or gMSA you have no ability to know the password that is used for database connectivity as it isn’t stored anywhere within Passwordstate.  You can find instructions on how to configure Passwordstate to use a MSA in our General Installation Instructions here,

Privileged Account Credential Password Visibility

You have a couple of options relating to restricting the visibility of Privileged Account Credentials, used for Active Directory Account lookups, Host and Account Discovery, and Password Resets.  You can hide the value of the password field from all Privileged Account Credentials.  This removes the Password Field and provides on screen information stating it is saved to database,

You can also set visibility of only the Privileged Account Credentials that you have been explicitly granted access to,

Both of these settings are configured under Administration->System Settings->miscellaneous as per the image below,

Hardening the Operating System and IIS

Click Studios would also recommend following established processes to harden your Passwordstate webserver OS and IIS.  The best approach for doing so is to follow Microsoft’s recommendations rather than trying to develop your own. 

The following is offered as a starting point in determining what is appropriate for your organization https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/windows-security-baselines

You can choose some or all of the suggested options in this blog to harden your Passwordstate instance.  The key as always, is to understand what you are doing, the implications of doing it, the benefits of taking that configuration option and that the change mitigates or removes the risk you are trying to address.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.