Cyber Criminals Exploit the Human Factor

Cyber criminals use social engineering approaches to install malware, steal information, perform fake transactions and even shutdown businesses. Greater than 97% of reported attacks target “the human factor” as opposed to making use of known system vulnerabilities.

Social engineering approaches used by Cyber Criminals focus on people, their role in the business, the data they have access to and the likelihood they can be enticed to perform an action. The human factor, our ability to be curious, the biases we have and their effect on our decision-making processes, our emotional state of mind, the way in which we monitor and evaluate situations on the basis of risk or reward, and the level of boredom in our roles all contribute to people being the most effective attack vectors in infiltrating businesses to facilitate fraud, theft and potentially worse.

Over the last 3 years there has been a marked shift towards information-stealing malware, with “the human factor” becoming ever more effective at preying on people. From impostor messages, where an email appears to come from a person the target knows, or malware that silently profiles individuals and steals data and credentials for future attacks, Cyber Criminals have their eyes firmly set of your businesses most valuable assets and the monetary value it holds. This ultimately fuels their revenue streams and funds future attacks.

Who is the Focus?

The Social Engineering approach, focused on “the human factor”, is all about exploiting select individuals and identities in targeted industries, not infrastructure and systems. Conversely, most businesses focus their IT Security budgets on infrastructure and systems,

The largest attack vector is still email, with 93% of all breaches targeting select individuals via approaches ranging from spam to imposter attacks. These select individuals are targeted on the basis of obtaining credentials to,

  • Feed further attacks against the targeted business,
  • Improve the effectiveness of the Social Engineering techniques with which they can obtain credentials and information,
  • Committing fraud

The people representing the greatest source of risk in business are,

  • Very Attacked Persons or VAPs. These are easily discovered identities and shared accounts. More than 35% of identified VAPs details are found online via corporate Websites, social media platforms, newsletters and annual reports
  • VIPs and C-Level executives. Again, these are readily discovered via social media platforms and more than 20% of the email addresses can be discovered via simple Google Searches
  • VAPs, VIPs and shared accounts in Education, Finance and Banking, Automotive & Manufacturing, IT, Media & Advertising (including Marketing) and Retail are frequently the most targeted

What are the Attacks?

As shown in the diagram, email is still the biggest initial attack vector for businesses. In 2018-19 generic email harvesting accounted for almost 25% of all phishing schemes. These were in the main focused toward credential harvesting. Over 99% of emails distributing malware require human intervention, this includes following links, opening attached documents, enabling macros, accepting security warnings and saving and unzipping executables for them to be effective.

Malware free Imposter Message attacks, including Business Email Compromise (BEC) are on the rise. Imposter Messages and BEC are used by Cyber Criminals to build rapport with attacked individuals, obtain multiple points of contact and create a sense of urgency around the activities they require the targeted individuals to perform. These activities include approving payments for fake invoices, or releasing business data.

Phishing lures typically simulate well-known brands such as Banks, Retailers and Webmail, offering login portals that seek to capture specific service credentials or simply obtain email logins that are used in future credentialstuffing attacks.

Domain fraud continues to increase, with attackers using techniques from look-alike domains to legitimate certificates to make malicious Websites appear trustworthy.

How are Select Individuals Identified?

Cyber Criminals are increasingly focused on attacking select individuals in a business instead of every user and reviewing which attacks are successful. These select individuals are either targets of opportunity or identified users with sufficient access and privilege. These people make up the group of VAPs in a business.

VIPs, C-level Executives and Members of the Board are often not VAPs. VAPs are typically more easily identified online, presenting a simpler and more direct means for Cyber Criminals to discover their role and contact details, then targeting them with multiple attacks. On average, across all industries, more than 35% of VAPs details can be found online. The following graph shows the average % of VAPs identified by Web based source,

as opposed to the common source of VIP identities,

However, one area of significant risk for businesses is VIPs who are also VAPs. In these cases, the average, across all industries, is greater than 20% of their email identities could be discovered online via a Google search.

How can Click Studios Help?

Click Studios specialises in the development of Passwordstate, an on-premise web based solution for Enterprise Password Management, allowing teams of people to access and share sensitive password resources. Our solution uses role based access control, with end-to-end event auditing, to provide a secure platform for password storage, management and collaboration.

For more information on how we can help please contact and as always, we welcome your feedback via

Passwordstate V9 Changes for Authorized Web Servers

With the soon to be released Passwordstate V9 Beta we’ve overhauled the Authorized Web Servers functionality. The Authorized Web Servers is used to mitigate against the theft of your Passwordstate Database and the credentials it contains. This is done by explicitly tethering the Database to specific NetBIOS Server Names, preventing your Database being hosted in an untrusted environment.

Enabling this is straight forward, by navigating to Administration->Authorized Web Servers and adding the NetBIOS names of all servers you want to explicitly authorize being able to host the Passwordstate Website. The current version 8 of Passwordstate screenshot is shown below,

New Authorized Web Servers

With Passwordstate V9 we’ve consolidated the location for all Passwordstate Servers and provided greater functionality. The new Authorized Web Servers allows you to specify the NetBIOS names for your Passwordstate Servers, including High Availability members as well as for your App Server. It provides,

  • A status indicator for each server showing the Polling Health and the last time polled
  • The build number of each server
  • The assigned Server role, either Primary or App
  • The High Availability mode status
  • The installation path for each server

The new screen can be seen below,

Note that the Polling is performed in line with all hosts and performed by the Windows Service. The Last Poll Time is the last Poll that occurred. Each Server’s Build No and Install Path is also automatically retrieved on a successful Poll.

When you Add New Authorized Web Server you now have to provide it with not only the Host Name, but also the Server Role (Primary Server, High Availability Server or App Server) but also the type of High Availability Node (Active or Passive) when you have selected the Server Role as High Availability Server,

Note the functionality above replaces the PassiveNode functionality previously located in the Web.config file.

What is the App Server Mentioned Above?

Passwordstate V9 introduces a new Server Role, that of the App Server. But what does it do you ask….well that’s for next week’s blog.

Remember, all feedback is welcome via

Auditing and Graphs

Passwordstate provides comprehensive reporting to ensure you can meet the governance requirements within your organization. All reporting makes use of the built-in audit events. There are more than 110 audit events in Passwordstate, providing a rich source of information that spans multiple categories, including,

Access to Passwordstate Access to Passwords All Passwords Exported
Auditing Data Archived Discovery Jobs Documents
Emails Email Templates Emergency Access
Encryption Keys Failed API Hosts
Logins Passwords Password Lists
Password Resets Password Validation Privileged Accounts
Remote Sessions Reporting Restricted Features
Security Administrators Security Groups Self Destruct
Templates User Accounts User Identity

When reporting on audit events, you can specify all sources or be selective. For example, you could report on only audit events relating to your Windows Service or your High Availability node. These events can then be exported to Microsoft Excel for further analysis, or summarized using the built-in Auditing Graphs.

…But before we get into the details for Auditing and Graphs

If you are trying to diagnose issues around a specific Password or Account you can quickly check the Recent Activity grid for the Password List that contains that account. This will provide useful information relating to the account and why activities such as Password Resets may not have occurred. The example below is for the helpdesk account which has been temporarily locked out;

Selecting Data using Auditing Filters

To begin with navigate to Administration->Auditing and decide on the events you want to review. By default, the display grid will show all audit events that have occurred. The Auditing Filters, show in the image below, help you to selectively focus on the specific types of events you are interested in reviewing;

The Platform options shown in the green rectangle are;

  • All, as the name implies this includes audit events for all the platform categories
  • Web, this platform category includes all audit events related to your Passwordstate Website
  • Mobile, this category includes all audit events related to either your Mobile Client installation in Passwordstate up to and including Version 8, or related to the new native Mobile Apps included in Passwordstate V9. Please note that as of the release of Passwordstate V9 the original Mobile Client is deprecated and no longer included with the Installer Files.
  • API, the API category includes those audit events associated with API Calls
  • Windows Service, includes all audit events associated with AD synchronization, Password Resets, Host and Account Discovery jobs, sending emails and querying event logs
  • Browser Extension, covers Browser Extension authentication with Passwordstate, saving, retrieving and updating of passwords and the use of the password generator,
  • Instance, you can also select your Instance to focus on, either your Primary or HA instance or Both

Lastly, you can elect to include Archived Data by selecting either the No or Yes radio buttons. By selecting No you will be querying the live audit events, if you select Yes it will query the Archived Data. Now you can filter down on a number of items as per the image below;

The fields in the Green rectangle above cover;

  • Max Records, allows you to specify the maximum number of records you wish to return as part of the search. If you wish to return all records you can enter 0 in this field
  • Password List, allows you to focus on a specific Password List in the drop down list, or search for events across all Password Lists
  • Activity Type, allows you to focus on specific audit events, or report against All Activities
  • Site Location Activity, allows you to focus on events for a specific Remote Site Location. This only applies if you have deployed and have an active subscription for Remote site Locations. The default for all installations is internal. For Remote Site Locations enter the number that corresponds with the Remote Site Location you wish to report against.
  • Begin and End Date, narrows the focus to the selected date range. Simply use the calendar date pickers for the start date and end dates you wish to focus on. A blank begin date will report all events that match the selected criteria up until the specified end date. By default, the End Date is always the current days date

Then simply click on Search to narrow the focus down to those specific events. Don’t forget that you can also filter down using the standard filter boxes under the column headings in the display grid (shown in the gold rectangle).

Export and Purging Audit Records

You may want to take a copy of the selected records, so that they can be included in a report or you may want to periodically Purge specific Audit Records. The options for these are situated at the bottom of the display grid as per the image below,

The Export to Excel will produce an Excel file called AuditingReport.xls containing the contents as per the executed filter.

If you select Purge Audit Records you will be taken to the Purge Auditing Data screen which explains the process necessary to perform the purge. Please note there is no automated purge within Passwordstate. You will need a Database Administrator, or someone responsible for support and maintenance on your SQL database, to perform the activities required. The Purge Auditing Data screen is shown below,

Graphs based on Auditing Data

Auditing Graphs provide a great summary view of your audited events. Like with the Auditing section, you can define filters for the Graphs that are very similar to those on the Auditing screen.

In the example below I’ve run a simple view based on Audit Activity of Login Attempt Failed for 1 year.

The key difference to note is that the duration timeframe is retrospective from the day the graph is based. In the example above it looks back 1 year from the current date.

The Auditing and Graphing capabilities are extremely useful and enable comprehensive reporting against your governance requirements. If you have any comments or feedback we’d love to hear it via

Ignored URLs and Browser Extensions

There is no doubt that Browser Extensions make your browser-based-life easier. The ability to securely manage website logins, while enforcing a reduced attack vector through unique login credentials, should not be understated. The statistics speak for themselves,

  • A 2018 Global Password Security Report revealed 50% of users reuse the same passwords for personal and work accounts
  • A 2019 online survey by Google identified 65% of people use the same password for multiple or all accounts
  • In the first six months of 2019, data breaches exposed 4.1 billion records
  • A 2018 Data Breach Incident Report confirmed compromised passwords are responsible for 81% of hacking-related breaches
  • Globally businesses are losing $4M on average each year due to credential stuffing attacks using leaked and exposed passwords and credentials

The reuse of usernames and passwords from a compromised site leads to a significantly increased attack vector for your business. So how do Browser Extensions help to reduce this risk, and why do I have issues with some websites.

Encourage and Support the Desired Behaviour

To begin with you need to provide the tools along with the education to your users. There is significant value in encouraging and allowing staff to use Personal Password Lists. This is reflected as one of Click Studios Best Practices for Passwordstate and more information can be found here.

Enabling Personal Password Lists needs to be performed alongside a robust training and education program for staff. This training should help them understand the real world impact associated with credential theft and hacking-related breaches. They’ll need to understand why they should have unique credentials, how they generate and store unique credentials and what to be aware of so they can identify when something doesn’t look right. Don’t forget, to get buy-in you need to show your users what’s in it for them.

Create Strong Passwords Using the Passwordstate Password Generator

One of the features of the Passwordstate Browser Extension is the ability to use the defined Password Generator. This can be set globally, via Administration->System Settings->password options->
With the Password Generator on the menu Tools -> Password Generator, select the following Password Generator Policy as the default:
and prevent users from selecting a different policy by selecting the Yes radio button,

This will make the default Password Generator for Browser Extensions reflect what was set under System Settings as detailed above. Note, the user can still choose another Generator if they want. This is why the education part is so important, Click Studios provides users the choice, however the business should reinforce the security standards they have put in place and the benefits those standards provide.

Understanding the Add Site to Passwordstate Dialog

When navigating to a website, one that you don’t have any saved credentials for, on logging in you will be prompted to Add Site to Passwordstate? The dialog provides you with 3 options, Close, Ignore and Save (note I’ve removed the username for the image below),

Save is straightforward and will create the password record in the chosen Password List. Clicking Close will simply close down the Add Site to Passwordstate dialog box. The tricky option is Ignore. When you click on Ignore you are not only dismissing the Add Site to Passwordstate dialog box, you are also adding an Ignored URL for that website login screen. The end result is that you will now never be prompted to save your credentials for that website URL again – until you delete the Ignored URL record.

To delete an ignored URL, login to Passwordstate and navigate to Preferences->Preferences->browser extension->Ignored URLs, select the URL to delete and click on the Actions icon and click Delete,

It’s worth noting that clicking on Ignore isn’t the only way to prevent the dialog for Add Site to Passwordstate from appearing. Ignored URLs can be manually entered by Security Administrators under Administration->Browser Extension Settings->ignored urls. These ignored URLs are global in effect and prevent all Passwordstate Users from saving credentials for those websites via the Browser Extensions.

Report Sites that have Issues

On occasion you will find a website that our Browser Extension has an issue with, specifically in correctly mapping the user name and password fields. When you come across this, we encourage you to report the issue by clicking on Report Site Issue. This will open up the Report Site Issue page in another Tab and allow you to record the details of the issue. We encourage you to supply as much detail as possible so that our Technical Support and Development Teams can investigate and provide a fix.

As always, we welcome your feedback via

Google Workspace, SAML Authentication and Passwordstate

Last week’s blog was all about SAML2 Authentication with Microsoft Azure. Keeping to a like theme, this week we’ll concentrate on setting up SAML Authentication for Google Workspace (formerly G Suite) and Passwordstate.

Google Workspace provides email and collaboration tools similar in basic function to Microsoft 365 (formerly Office 365). In order to use SAML2 authentication, in Passwordstate with Workspace, you’ll need to specify the settings obtained within the ‘Service/App’ configured within Workspace. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As with the Azure Blog, the terminology isn’t always consistent between SAML2 Providers so you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Workspace,

Passwordstate Field Workspace Supplied Fields
Audience Restriction Service Provider Entity ID
‘Your Passwordstate URL’/logins/saml/default.aspx ACS URL
‘Your Passwordstate URL’ Service Provider Entity ID
UserID or Email or UserPrincipleName Email
X.509 Certificate (SHA256) Certificate
IDP Issuer URL Entity ID

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is this time

Create a Service/App for SAML

In these examples we’re going to configure Passwordstate for SAML Authentication and Single Sign-On with Workspace. First you’ll need to login to your Google Admin Console and click on the Apps icon as per the screen shot below,

then select SAML Apps,

and click on Add a service/App to your domain,

this will take you to Step 1 Enable SSO for SAML Application. Click on SETUP MY OWN CUSTOM APP,

Step 2 Google IdP Information will appear and prepopulate your SSO URL and Entity ID fields for you. Click on NEXT.

this will take you to Step 3 Basic information for your Custom App. Provide an Application Name, in our example Passwordstate, and click NEXT,

on Step 4 Service Provider Details, enter your ACS URL and Service Provider
Entity ID (refer to the table at the beginning of this Blog entry) and ensure Name ID, Primary Email and Name ID Format are selected as per the image below and the click NEXT,

on Step 5 Attribute Mapping click FINISH.

Next, you’ll need to turn this on for everyone by clicking on View details,

and selecting On for everyone, then clicking SAVE,

Download your Passwordstate SAML Metadata

You’ve now created the SAML settings for the Service/App Passwordstate. By clicking on DOWNLOAD METADATA you’ll have access to all the required details  that are required to configure Passwordstate’s SAML2 section,

this will open a dialog enabling you to either, 1: Download IdP metadata, or 2: Copy the SSO URL, Entity ID, and Certificate,

Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot above,

Note we’ve selected to use Email Address, or EMAIL in the Workspace settings as the unique identifier. You’ll need to copy the Certificate from downloaded file or Download metadata screen, ensuring you copy the entire contents into the X.509 Certificate field (including the Begin Certificate and End Certificate lines). The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Workspace information (again use the table at the beginning to map the SAML settings). When finished click on the Save & Close button at the bottom of the screen.

Authentication via Workspace SAML

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Google Choose an account and Enter your password challenge screens. Once you’ve logged into Google Workspace Passwordstate should open up as normal.

We hope this helps with Google Workspace and authenticating to Passwordstate using SAML. Please send any comments or feedback to

SAML Authentication with Azure AD

The Click Studios Technical Support group is regularly asked if we support authentication between Passwordstate and Microsoft Azure AD. The simple answer is yes, and in order to do this you must be using SAML2 Authentication as your global authentication setting. This allows you to setup authentication to, and Single Sign-On for, Passwordstate.

In order to use SAML2 authentication in Passwordstate, you must specify a number of settings, each of which can be obtained within the ‘Application’ configured with your SAML2 Provider. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As the terminology isn’t always consistent between SAML2 Providers you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Azure Active Directory,

Passwordstate Field Azure Active Directory Field
Audience Restriction Identifier (Entity ID)
‘Your Passwordstate URL’/logins/saml/default.aspx Reply URL
‘Your Passwordstate URL’ Sign On URL
‘Your Passwordstate URL’/logins/saml/default.aspx Relay State
UserID or Email or UserPrincipleName Unique User Identifier
X.509 Certificate (SHA256) Certificate (Base64)
IDP Target URL Login URL
IDP Issuer URL Azure AD Identifier
Logout URL Logout URL

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is

Create a Non-Gallery Application in Azure

In these examples we’re going to configure Passwordstate for SAML2 Authentication and Single Sign-On with Azure AD. First you need to login to Azure via the portal and navigate to your Azure Dashboard. From here we select Azure Services->Azure Active Directory as per the screen shot below,

Then select Enterprise applications from the menu on the left,

and click on New Application. This will present one of 2 screens depending on whether you’re using the old App Gallery or the New and Improved App Gallery,

If you’re using the old App Gallery, you’ll see the following screen and will need to click on Non-gallery application as per the image below,

If you’re using the New App Gallery, you’ll see this screen instead and will need to click on Create your own application, give it a name and select ‘integrate any other application you don’t find in the gallery’,

This will create the Enterprise Application with the name you have provided. In this example it’s called Azure Demo-Passwordstate.

Configure and Generate your SAML Single Sign-on Information

Now we need to configure Single Sign-on and generate your SAML Provider settings for use in Passwordstate. First, we click on Single sign-on,

and then click on SAML to be able to specify the settings you require,

this will open the SAML-based Sign-on screen, allowing you to configure settings, download your X.509 Certificate and provide the URLs for configuring your Passwordstate SAML2 Authentication settings,

edit 1 Basic SAML Configuration and 2 User Attributes & Claims by clicking on the pencil Edit icon, and use the basis of the information as per the table at the beginning of this blog. Then click on Download next to Certificate (Base64) under 3 SAML Signing Certificate. Please note, as stated in the image you’ll need to add your users before they are able to login. They can be added via Users and groups on the Left Hand side of the screen,

Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot,

Note we’ve selected to use Email Address, or user.mail in the Azure settings as the unique identifier. You’ll need to open the X.509 Certificate you’ve downloaded previously, with something like Notepad, and copy the entire contents into the X.509 Certificate: field, making sure to include the Begin Certificate and End Certificate lines. The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Azure Enterprise Application (our example is Azure Demo-Passwordstate),
SAML-based Sign-on screen. When finished click on the Save & Close button at the bottom of the screen.

Authentication via Azure AD SAML2

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Microsoft Azure Pick an account and Enter password challenge screens. Once you’ve logged into Azure Passwordstate should open up as normal.

We hope this makes it easier to understand how to authenticate Passwordstate with Azure AD using SAML2. Please send any comments or feedback to

Control Access to Local Accounts with Credential Check-In and Check-Out

Many organizations implement strict access control to privileged accounts in their Domain and on their Windows Workstations and Servers. They work through a stringent process, ensuring local and domain user accounts have the least amount of privilege possible, lessening the possibility of exploits gaining control of systems.

However, the downfall is that a good percentage of organizations keep the same Local Administrator Account and Password combination for all Workstations. The defence, when challenged on why this is done, is typically along the lines of “we only have a handful of trusted staff that use this account”. In these cases, there is typically no auditing of which staff member used it, when and on which workstation. Key users are also typically entrusted with the generic Local Administrator account so that they can assist Support Teams (when they’re overloaded) by installing and trialling software. All of these scenarios provide the potential for rootkits, keyloggers, and other suspect services being installed without your knowledge.

With Passwordstate, you can easily setup unique Local Administrator and Password combinations for each host, audit and report the access to these accounts, configure Check In and Check Out so only one person can access the account at any point in time and setup scheduled password resets to limit exposure. Enabling PowerShell Remoting is a prerequisite required for this and you should understand the implications of doing so. Microsoft provide a good summary that can be found by searching for “PowerShell Remoting Security Considerations – Microsoft Docs”.

Discover All Hosts and Local Accounts

First, you’ll need to setup a Host Discovery job, identifying all your workstations and adding them into Passwordstate. In the example below I’m identifying all of our Windows 10 Workstations using the following Host Discovery Job.

As you can see from the above image, I’ve targeted the Windows 10 Operating System on our Domain and have specified a Privileged Account with permissions to query Active Directory for this Discovery Job. I’ve also simply selected the CN=Computers (CN being Common Name) on the active directory ous tab. It’s a good idea to initially run the query in Simulation Mode to make sure it’s returning the results you were expecting. Once you’re happy with the result you can unclick Simulation Mode and run the discovery job. You can also specify the frequency of the Discovery Job on the schedule tab. I’ve added in the results of the discovery job to the Hosts tab under a folder called Halox Workstations,

Next, I’ve created a Shared Password List called Local Windows 10 Admin Accounts. This will be used to store the Local Admin Accounts for the Windows 10 Workstations that I’ve added in. In the Password List I’ve selected Enable Password Resets and set the Default Password Reset Schedule to resetting every 90 days. On the customize fields tab it’s worth checking that the Expiry Date field is checked as required as this is updated with the new Expiry Date for the Passwords.

You can also specify the Password Strength Policy and Generator Policies in accordance with your organization’s standards.

Now you can setup the Local Account Discovery job. As per the image below, this discovery job will import all Local Accounts that are members of the Local Administrator’s Group on all Windows 10 Workstations and store the password records in the Local Windows 10 Admin Accounts Password List. You will need to specify the hosts to interrogate on the hosts to be queried tab. Again, you can run this job in Simulation Mode to ensure you are targeting the right machines and verify the results before actually importing them into Passwordstate. Note, If PowerShell Remoting isn’t enabled on the remote systems then you won’t be able to query the Local Administrator accounts on the target hosts.

Schedule Password Resets for Local Accounts

Once you’re confident you are obtaining the right results you can also elect to perform an immediate Password Reset for these accounts by selecting the radio button (bottom of the image). This enables you to bring all the imported accounts under control and reference Passwordstate as the single source of truth for these Local Account credentials.

Alternatively, you can go back to the Password List that the records are being stored in, and from the List Administrator Actions… drop down select Bulk Update Passwords,

When using either the immediate Password Reset or Bulk Update Passwords the Expiry Date will be updated in accordance with the number of days specified under Default Password Reset Schedule to enable future Password Resets to occur correctly.

Enable Check Out and Check In for Local Accounts

Lastly, we’re now at the option for Check In and Check out. This is extremely useful in offering a tight granular control over access to Local Accounts across your workstation fleet. To enable this for all Local Accounts you’ll need to modify the Local Account Discovery job you’ve previously created as follows,

This will now generate a Random Password for each Local Account that is imported, perform an immediate Password Reset on the Host that the Local Account belongs to, and specify the Security Settings of each Password Record limiting access to the password via a Check Out process, immediately perform a Password Reset on Check In and automatically Check In passwords after 12 hours (in case your System Admins have forgotten to). Anyone requiring access to a Checked Out Local Amin Account password will only be able to see who has exclusive access to this credential. All events are of course audited.

You can watch our YouTube video showing the Check In and Check Out functionality here.

We hope this information helps you to understand what options are available to better control access to Local Accounts and improve on your security posture. All feedback is welcome as always via

Specifying Authentication Options

A customer recently asked us to assist in resolving an issue with authentication for some of their users. This sparked some discussion between members of our Technical Support Team as to whether most customers knew where you can set the authentication properties required for access to Passwordstate.

The end result is this blog entry, as a reminder on where authentication properties can be set, and any specific limitations or conditions that apply to those areas. For the purpose of this blog entry we’re using an AD Integrated instance of Passwordstate. If you’re using Forms-Based Authentication then some of the screens may look slightly different.

Global Authentication Options

The first area where authentication options are set controls the settings for all users. This is typically referred to as the Global or System Wide authentication options and is accessed from Administration->System Settings->authentication options as per the image below,

As stated on the screen above, the default System Wide authentication option for Passwordstate is ‘Passthrough AD Authentication’ which requires no additional input from the user.

If you wish to change this simply select the option of your choice from the Choose Authentication Option drop down list. This will change the default authentication options for all Passwordstate users. The screen provides you with options for additional settings used with Manual AD, AD Integrated, Forms Based authentication as well as settings for other options including the popular ones such as SAML, Yubikey and Duo.

Authentication Options for Specific User Groups

Next you can set specific authentication options for groups of users through User Account Policies. This is performed by creating a User Account Policy, specifying an authentication option and assigning that policy to a group of users. To create a User Account Policy, navigate to Administration->User Account Policies and click on Add to create a policy,

Give the User Account Policy a name, description and choose an authentication option at Setting ID A6,

In line with Click Studios Best Practices, we recommend that if you have ‘Passthrough AD Authentication’ selected as your System Wide setting then don’t apply an additional Two-factor Authentication option to all users. It will frustrate your users and defeats the purpose of implementing Single-Sign-on to Passwordstate. You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts. It is recommended that you do this via Security Groups and not by supplying individual usernames.

Once you’ve selected the authentication options and any other settings you want to apply, click on Save and then using the Actions icon next to your new policy, click on Apply Policy to Users. An example of applying Google Authenticator in addition to Manual AD Authentication / Passthrough AD Authentication can be found here.

User Preferences – Authentication Options

Passwordstate allows users to set a number of preferences. One of the ‘preference sets’ that can be individually configured on a per user basis is authentication options. This allows each user to specify what Authentication Option they wish to use when accessing Passwordstate, and what additional authentication options they want for accessing their Password Lists. For users to set their own individual settings they need to navigate to Preferences->Preferences->authentication options,

From this screen they can choose an Authentication Option as well as configure specific settings for multiple authentication options for 2FA. You should note however that the options that appear here can be hidden and overridden by;

  • An active User Account Policy, that applies to the user, with the Setting ID A6 set as ‘Use the System Wide Authentication Settings’,
  • Specific Authentication Options have been selected to be hidden under Administration->System Settings->authentication options->
    Hide the following Authentication Options on User’s Preferences screen:


Additional Authentication Required for IP Ranges

Lastly, you can choose to select different authentication options based on the IP address range that access to Passwordstate is initiated from.

This is especially useful when your System Administrators need access from non-trusted IP ranges, such as needing to access Passwordstate from an externally initiated VPN or when accessing from an Internet connection.

To configure authentication options specific for unregistered IP Ranges navigate to Administration->System Settings->allowed ip ranges->Web Site Allowed IP Ranges, specify the IP ranges for allowing access to Passwordstate and then under setting If the Passwordstate web site is accessed outside of one of the IP Ranges listed above, force the user to authenticate using the following method: choose an authentication option. If there are any settings required for that authentication option you can enter those details on the Administration->System Settings->authentication options screen.

We hope this helps you understand all the areas within Passwordstate where authentication options can be set. If you have any feedback, we’d love to hear it via

Password List Performance Testing

We’re asked every now and again about potential performance impacts with regard to the size of Password Lists. While every organisation is different there are some general considerations that should be thought about when designing your Password Lists within Passwordstate. These include,

  • Logically separate your password credentials based on meaningful descriptors such division, team, function, role etc.
  • Use Folders to group like Password Lists
  • Try to apply consistent permissions within a navigation tree’s nested folders
  • Keep the Password List display grid to 50 records or less

Despite using these points when designing your Password Lists you may still end up being tempted to create a few big lists. But how big is too big?

Sample Server Specification

We recently performed some performance testing for a customer who was looking at potentially creating some really big Password Lists. For the sake of consistency during the performance testing we spun up a modest Hyper V Windows Server 2019, using 2 processors and 8 GB of RAM in our Technical Support Test Lab,

Password List Sizing’s Used

Whilst many organizations end up with Password Lists that are organized in quite a granular fashion (using the considerations at the top of this blog entry) we’ve positioned the samples on the generous side of things when performing the testing.

The performance issue you encounter with extremely large Password Lists is directly related to HTML rendering. We generated 5 Password Lists, containing 5,000, 7,500, 10,000, 25,000 and 50,000 password credentials by first creating the Password Lists in the Passwordstate UI and then using our API to add in the required number of passwords for each particular List. The Lists didn’t need to contain usable login entries as such, they just needed to contain correctly formatted password records.

Performance Results

The baseline performance testing results are tabulated below. The good news is that Password Lists will take a fair number of password records before being substantially impacted by HTML rendering,

Password List Name

Number of Records

Rendering Time

5000 Passwords


Less than 1 second

7500 Passwords


1.5 seconds

10000 Passwords


2 seconds

25000 Passwords


4 seconds

50000 Passwords


8 seconds

Based on the results above most organizations could scale-up individual Password Lists to accommodate between 5,000 to 7,500 password records if required and still have response times for rendering between 1 to 1.5 seconds. Having said this, we can’t really think why you would need to have this volume of password records in a single list if you’ve designed your Passwordstate implementation and Password Lists appropriately.

Impact on IIS Worker Process

Another point worth noting, is the impact on your IIS Worker Process. During the performance benchmarking we observed the larger Password Lists had a significant impact on the resources required for the IIS Worker Process. Running the test on the 25,000 password records list caused the CPU usage to spike to 51% and the 50,000 password records list to spike at 55% CPU usage.

We hope this information is helpful and we welcome feedback via

Some Examples of Best Practices for Passwordstate

Here at Click Studios a couple of staff from Pre-Sales and Technical Support are pulling together the first draft of our Best Practices guide for Passwordstate. The recommendations provided in the Guide are a direct result of assisting organizations around the world deploy Passwordstate successfully and streamline their privileged access management practices.

As the finished version of the Guide is still a little way off, we thought you may appreciate having a couple of the Best Practices previewed here.

Securing your Web.config File

One of the easiest ways in which you can secure your Passwordstate Instance is to encrypt both the Database Connection String and appSettings Sections of your Web.config file. This ensures that anyone having access to your Web Server’s file system will be unable to use the details of the Web.config file to access and retrieve your Password Credentials.

The process is straightforward and requires you to separately encrypt the Database Connection String and appSettings Sections of your Web.config file using aspnet_regiis.exe. The executable is usually located in the %windows%\Microsoft.NET\Framework\versionNumber folder. Once you’ve encrypted the two sections you’ll need to stop and restart the Passwordstate Service.

The example image below shows the command being executed for the AppSetting section, stopping and then restarting the Passwordstate Service,

Full instructions for performing this can be found within our documentation here or our blog entry here.

Use 2FA with SSO for highly privileged Accounts

Most organizations choose to install the AD Integrated version of Passwordstate and enable Single Sign-On (SSO) access to their Password Lists (Password Vaults).

The use of SSO is great for providing seamless entry to Passwordstate, once users have been successfully authenticated against your Domain, using their Active Directory credentials. However, for access to highly privileged and sensitive account credentials, stored within Passwordstate, we recommend you introduce an additional level of authentication.

An easy way of doing this is by enforcing 2FA, with a Smartphone App like Google Authenticator, for either your Systems Administrators or against access to Password Lists containing the highly sensitive credentials. To do this you create a User Account Policy (UAP) that specifies that users must use Google Authenticator (the example below uses Manual AD and Google Authenticator) and apply this UAP to your target list of AD accounts,

The Systems Wide Settings for Authentication Options remain set as Passthrough AD Authentication. Now anyone in your target list of users will be prompted for their Google Authenticator PIN as an additional level of authentication when browsing to your Passwordstate Website.

Full instructions for performing this can be found in our blog entry here.

Allow the use of Private Password Lists

Allowing the use of Private Password Lists for users within your organization is encouraged. Organizations that adopt and promote the use of Private Password Lists for their employees typically build a healthier cybersecurity awareness in their workforce. These employees more quickly embrace and adopt credential management practices, for both personal and business use within the organization.

You can automatically create Private Password Lists for all new user accounts as they are added to Passwordstate by enabling the option When a new User Account is added to Passwordstate, automatically create a Private Password List for the user. You can also specify the name of the Private Password List using the variables FirstName and Surname and base the new Private Password Lists on an existing or newly created Password List Template.

Once you have chosen your template, you’ll need to enforce the creation of the Private Password Lists on that template by creating a User Account Policy and targeting All Users and Security Groups,

Now each new User will have their own Private Password List and be configured as the Administrator of that List. Again Full instructions for performing this can be found in our blog entry here.

We hope you find this preview of some of our Best Practices useful and don’t forget to provide any feedback via