With the introduction of Passwordstate Version 10, we’ve made some changes to our APIs.  That’s great you say, but what’s an API?

An API, or Application Programming Interface, is a set of defined rules and protocols that allow a software application to communicate and exchange data with other applications. Think of it as a “middleman” where developers can use it to automate tasks including the retrieval of data, using existing functionality, without having to rebuild the applications from scratch.

An analogy is the drive-through take-away.  Where you the Customer (Client Application), queues in a drive-through lane specifically used for interacting with the Take-Away Venue (Server Application). 

You place your food order from a menu of specific items (rules and protocols) with the Drive-Through Attendant (API).  The Drive-Through Attendant engages the Take-Away Venue on your behalf, ensures the interaction conforms with the required rules and protocols for the interaction, and presents your completed food order to you.

Three Types of API

Passwordstate has 3 different APIs, providing a choice of authentication models for accessing and performing actions on the information stored within Passwordstate.

Standard API

Sometimes referred to as a General API, this uses preset API keys, typically a long-lived string used to authenticate the calling code/script, rather than an account.  This is used at the Password List, Folder or Passwordstate System Wide level. The benefit is it requires no human-based interaction and never expires (unless you force it to).

• Example Use Case: An internal script runs nightly, pulling information from HR systems relating to new employees, and populates entries in an organizations’ Identity Management System and Passwordstate.  In Passwordstate it ensures the new user has access to credentials required for their role by synchronizing Active Directory Groups, ensuring they have been assigned to any specific Security Groups, creating a personal folder and private password list for them, and enrolling the user for the Password Reset Portal.

Windows Integrated API

Also known as a User’s Authenticated Windows Session.  This leverages the user’s existing authenticated system login (Active Directory) rather than actual API keys.  It enables API calls to operate under the same security context as they would have if the user performed the activities manually via the User Interface. In Passwordstate it means a user doesn’t have to generate, copy, or paste keys. Security permissions instantly match corporate IT policies (because the permissions are based on their account permissions).  When an employee is terminated or changes roles as defined in Active Directory, their “API” access vanishes or changes automatically.

• Example Use Case: An employee has a custom script, that retrieves a username, password, one-time Password, and change management template for a custom change management system.  It then passes the credentials to the change management system, and opens the change management template with Microsoft Word.  The employee edits the word document based on the template as saves it to the change management system.  The employee’s security context, established when they logged in via Active Directory, authenticates all the transactions against Passwordstate.

User Based API

Sometimes referred to as Scoped User Tokens, this approach provides a unique API key generated from within a specific user’s account, inheriting that particular user’s access rights and scope as defined within Passwordstate.  It again operates the same as if the user was logged in via the User Interface.

• Example Use Case: An employee, such as a System Administrator, creates an API key that is unique to their access within Passwordstate.  He uses this to authenticate his API calls within a custom script, that reads an “assets” file and adds new Hosts that have been commissioned and deletes Hosts that have been retired.

Is there Documentation Available?

Click Studios provide comprehensive documentation on the 3 types of APIs here,

Each of the API Manuals includes specifics for the API type, including Authentication, Errors, and examples of the API methods that can be invoked.

Automatic Rotation of API Keys

Introduced with Passwordstate Version 10 is the new Job Scheduling Engine.  This allows organizations to centrally manage, execute and audit PowerShell scripts, discovery jobs and operational automation tasks.

Rather than maintaining scripts across separate servers, desktops or scheduling platforms, administrators can manage jobs from within Passwordstate and control who can create, modify, execute and review them.

One of the big wins with the Job Scheduling Engine is the ability to securely access the required API key during execution, without needing to embed the key within the PowerShell script. The API key can then be automatically rotated after job execution, reducing the exposure and reuse of API credentials.

The rotation of API keys is limited to the Standard API and User Based API only.  It is not available with the Windows Integrated API, as this uses the User’s Authenticated Windows Session instead of an API key.

Firstly, there is no issue with fulfilling some capabilities using a cloud-based Software-as-a-Service (SaaS) approach.  Software-as-a-Service capabilities are popular for their quick setup and lower costs (although this isn’t always the case and requires due diligence).  The key area to consider with SaaS is “does it meet all my requirements?”, not just “does it provide the functionality I’m after?”.

On-premise software continues to provide the strategic advantage for organizations that prioritize absolute data sovereignty, deep system customization, and real operational resilience!  Deploying applications, on your own physical enterprise-class infrastructure, can offer distinct long-term advantages over cloud models.

What are the Advantages?

Each organization will have different advantages and not all organizations advantages will be to the same extent.  This is because all organizations are influenced by numerous factors, including Capital and Operational budgets, number of employees and IT support staff, their Digital Literacy, the degree of Formalization in the organization and its Risk Appetite.

The Key advantages can be summarized as,

1. Total Data Ownership and Control: ensuring data is stored within your organizational boundary, without the liability of exposing proprietary data to third-party cloud vendors or external hosts.  Retaining capabilities in house, with immediate access to unfiltered log files and permission schemes, assists with forensic data auditing.

• Advanced Compliance and Data Sovereignty: Some industries like banking, healthcare, government, and defense operate under more stringent legal frameworks requiring data to stay local.  This can fully satisfy regional data residency rules and ensure compliance with laws that require sensitive data doesn’t legally cross international borders.

• Unrestricted Customization: On-premise systems allow you to configure / customize to your organization’s requirements and build unique scripts / workflows that match company processes.

• Offline Reliability and Zero Internet Dependency: Unlike SaaS platforms, on-premise software works reliably even if the building’s external internet, or the Cloud providers solution, is unavailable.  All data typically moves over a high-speed local area network (LAN) with minimal latency making software responsiveness highly predictable.

• Complete Control Over the Upgrade Cycle: SaaS providers push global updates automatically which can break active integrations or disrupt users.  On-premise models put the timing within your control, allowing staff to rigorously test updates in a sandbox / quality assurance environment before migration to production.

• Long-Term Cost Predictability: While on-premise typically requires an upfront capital cost for hardware and licenses, it eliminates most recurring subscription based costs.  As an organization scales its users, SaaS monthly / yearly costs can balloon dramatically. On-premise license costs are typically cheaper over a multi-year lifecycle.

Where does Passwordstate fit in?

Passwordstate is a self-hosted enterprise password manager and privileged access management (PAM) solution that runs on the Microsoft technology stack.  Historically we marketed Passwordstate as an On-Premise solution, however this really just means within an environment that you control, can configure and manage, as if the software was hosted on your own servers.

While we don’t offer a SaaS version of Passwordstate, you can host it within your own cloud tenancy, such as in AWS or Azure.  This allows you to still obtain some of the advantages, such as lower initial capital cost related to server and network infrastructure, and quicker setup of your virtual infrastructure.

Protecting your data!

For the purpose of this blog article, instead of implementing a SaaS solution you’re looking at installing Passwordstate on infrastructure you control on-premise, or in a cloud tenancy, and making it available to users no matter where they are located.

This is all well and good, however you’ll still need to give consideration to how you protect your data once you want to expand accessibility beyond your organizational boundary.

For this scenario we can use the following for our example.

The first example below, shows Passwordstate behind a Reverse Proxy where traffic is routed through an external firewall.  Requests are validated by the Reverse Proxy before being passed through an internal firewall to reach the back-end Passwordstate instance.

This example is a modern implementation of the DMZ approach, where access to services is authorized by a “firewall” operating within a Demilitarized Zone.  The Reverse Proxy approach is more sophisticated than simply hosting within a DMZ, but it suffices for the point of this blog. 

The second example below, shows Passwordstate behind an App Proxy. Users hit a cloud security layer (such as Microsoft Entra ID Application Proxy). An outbound-only connector agent running inside the secure internal network establishes a persistent tunnel to the cloud proxy. This configuration enables your external firewall to be completely locked down with zero inbound open ports.

The third example (not shown) is via a corporate VPN solution, where each remote client establishes a VPN connection back to the corporate network.  This extends a company’s private internal network across the internet, allowing employees to securely access company applications, data, and servers as if their computers were physically plugged into the office network.

You can also enable access to credential sets while away from the office, without providing online access to back-end systems.  This can be readily done through the use of Passwordstate’s native Mobile Apps for iOS and Android devices.  Users can use biometric authentication to access an encrypted cache of credentials they have been granted permission to use. This encrypted cache is available offline and has a maximum Time to Live after which it is automatically removed from their device.  All access to credentials is audited, with audit records synchronized with Passwordstate the next time their device reconnects to their instance.

Don’t Forget Best Practice Options

Lastly, if you haven’t done so already, give serious consideration to implementing options aimed at strengthening and enforcing tighter controls on who can access Passwordstate, what they access, and where from.  This isn’t intended to be an exhaustive list of all best practice options, rather an example of what to consider.

Look at implementing 2FA (2 Factor Authentication) with requirements for more stringent controls dependent on the level of access.  As an example,

• General Users may access their Password Records with login via Single Sign-On,
• Security Administrators, who have access to higher privileged credentials, require additional 2FA to login,
• All users, when accessing highly confidential credentials, e.g. company’s bank account username and password, must provide 2FA when accessing those details.

Using Allowed IP Ranges, you can specify what network ranges Passwordstate can be accessed from.  These can be defined at the website level, when using the APIs or accessing the Emergency Access login page.  Additionally, if accessing the website from outside of the specified IP ranges, you can choose to deny access or request specific authentication requirements e.g. instead of Single Sign-On you’ll need Manual Login Authentication plus a One-Time Password.

In System Settings->Authentication Options->Web Authentication Options you can lock out any user after a specified number of failed login attempts.  You can lock out based on either the originating IP address or the User ID and IP Address.  This helps to protect against brute-force attacks.

Under Reporting & Webhooks you can setup Scheduled Reports or Webhooks.  Scheduled Reports allow you to email an existing report or audit query result for specific Alerts for Failed Logins.  With Auditing queries, you can also send the results through to your chosen Webhook provider e.g. Microsoft Teams or Slack, to send near real-time details into a channel.

Affordable, Extensive and Flexible

In summary, organizations can implement an Enterprise Password Management solution like Passwordstate, that offers more strategic advantage than Software-as-as-Service competitors.  All that’s required is a little thought around the architecture for your hosting requirements, and the appropriate methods of strengthening and enforcing control over accessing your data. 

As always, we recommend architecting your implementation in accordance with “meeting all my requirements“ and analysing your risks before proceeding to implementation.

There has been a recent series of articles and reported posts about Browsers and the risk of clickjacking, where bad actors manipulate a user’s activity by concealing objects beneath legitimate clickable content. 

Clickjacking is also known as a “UI redress attack”.  It typically involves multiple transparent or opaque layers to trick users into clicking on objects, such as buttons or links on another page, when they were intending to click on the top level page. The intent is to trick the user into;

• performing actions, such as entering their login credentials,
• entering their banking details, or
• loading a script of which they are unaware.

The bad actor is in effect “hijacking” clicks or keystrokes meant for a legitimate page and routing them, or the details entered, to another page that they control.

In lieu of this Click Studios has further enhanced the existing approaches to protecting your credentials with additional functionality in both our Browser Extensions and the Passwordstate core software.

Existing Approaches To Protection

But first, we should cover off on the existing protection available prior to Build 9972.  Passwordstate has historically provided a range of features aimed at securing access to credentials via our Browser Extensions.  This has included,

Confirmation of the Passwordstate Server URL.

This check ensures that your Browser Extension is connecting to the correct Passwordstate Instance.  If the Browser Extension is red then the extension is unauthenticated and cannot retrieve or form-fill credentials,

To authenticate the Browser Extension requires you to login to your Passwordstate instance, click on the Browser Extension icon, and then confirm the Authentication URL matches the URL of your Passwordstate Instance that you have just logged into.  If these match then you can enter your Browser Extension Master Password and click the Login button.

Reauthenticate Browser Extension on Opening.

When you close your Web browser, you will typically lock it and on reopening the Web Browser will have to reconfirm the URL, and enter your Master Password, to unlock the Browser Extension,

Note: Your Passwordstate Administrator may have configured Passwordstate to Auto Unlock the Browser Extension on Browser Startup.  Organizations should consider both their operational requirements and perform a risk assessment before enabling the Auto Unlock feature.

Restrict Credential Types Being Accessed.

Your Passwordstate administrator can opt to block a number of credential types from being accessible via the Browser Extension.  This includes Form Filling of OTP codes, blocking those Password records requiring Additional Authentication, and blocking Password Records requiring Check In/Out.

They can also set the strength policy that a user’s Master Password must adhere to.

New Protection in Build 9972

In Build 9972 we have further strengthened the options with our Browser Extension. 

The first of these relates to Ask before form-filling credentials.  If this is set by your Passwordstate Admin, then on browsing to a website where you only have one (1) saved credential, you will be prompted if you want to auto-fill that credential into the login input elements (image below, using Brave web browser),

If you have more than one saved credential for the website you’ll need to select the correct password record first, then you’ll be prompted if you want to form-fill those credentials.

The correct use, in either of these examples is,

• if you are prompted to auto-fill your credentials, but there are no visible login elements and your Browser Extension turns orange, you should stop what you are doing,
• double check the website you are about to form-fill is safe to use.  Is the URL of the website the same as the URL displayed at the top of the prompt box?  If you are uncertain then seek assistance from your Passwordstate administrator!

An example of the warning notification (Browser Extension turns orange) is shown below,

The above image is courtesy of https://websecurity.dev/password-managers/dom-based-extension-clickjacking/

The second of the new settings Globally disable Auto-Fill for all users will enable the Browser Extension to identify websites it has the matching credentials for, however they will not be automatically form-filled and the form-fill overlay will not be presented in the input elements.  To fill these credentials, you will have to manually click on the Matching Login record in the Browser Extension (image below),

Basis of Protection

Our approach is based on heuristic protection to mitigate against known click-jacking techniques.  When this is triggered the extension icon will turn orange and not form-fill as a precaution.

As always users should ensure they trust the website before providing any credentials.

In May we posted our Blog on Alerting For Best Practice Encryption, outlining how Passwordstate offers a Defense-in-Depth option for encrypting your configuration files, and now alerts on configuration files used by Passwordstate that have not yet been encrypted.

For details related to this article please see https://blog.clickstudios.com.au/alerting-for-best-practice-encryption/

But how are configuration files encrypted and what is the application responsible for the encryption.  This week’s blog fills in the gaps.

Using Built-In Functionality

When you install Passwordstate, one of the system requirements is .NET Framework 4.7.2 (or higher).  This provides the tools and libraries required for web applications, including an application called aspnet_regiis.exe. 

This application is used to encrypt or decrypt sections of a Web configuration file. The ASP.NET framework automatically decrypts encrypted configuration elements in your Web.config file when it is loaded into memory for use by the website.

The encryption of configuration elements is referred to as protected configuration and it ensures highly sensitive information is not stored in a readable or decodable format. This improves security by making it difficult for an attacker to gain access to that sensitive information, including usernames, passwords, database connection strings and encryption keys, even if they gain access to the file or the associated database etc.

when encrypted, the configuration elements can only be decrypted on the server responsible for the original encryption.  They cannot be decrypted on any other system.

Please note, if the memory for your application is compromised, the sensitive information from your protected configuration section might be compromised as well.  This is not a vulnerability associated with Passwordstate, rather a potential weakness in your Defense-in-Depth approach.

How to Encrypt Your Protected Configuration

We’ve produced a manual showing how to encrypt (and decrypt) the protected configuration elements in your web.config file.  This includes the relevant configuration elements for the following;

• Primary Passwordstate website
• High Availability Passwordstate website
• Password Reset Portal
• AppServer Module
• Remote Site Locations Agents
• Self Destruct Web Site (Push/Pull implementation)

The manual can be found under the documentation section of our website here https://www.clickstudios.com.au/downloads/version9/Encrypt_Passwordstate_Config_Files.pdf

We encourage customers to reference the Encrypt Passwordstate Configuration Files manual.  This will provide guidance of which configuration elements require encryption.

Encrypting… an Example

This example is based on encrypting the two configuration elements used with your Primary Passwordstate instance.  These are connectionStrings and appSettings.

On your Passwordstate Web Server open a Command Prompt with administrator privileges and navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319

Now type in aspnet_regiis.exe -pef “connectionStrings” “c:\inetpub\passwordstate” and press enter.  Note that if you installed Passwordstate in a different location you’ll need to replace c:\inetpub\passwordstate with the location of your Passwordstate instance.  You should see the following;

Now you should proceed to encrypt the appSettings section of your Web.config file.

Type in aspnet_regiis.exe -pef “appSettings” “c:\inetpub\passwordstate” and press enter.  Again, if you installed Passwordstate in a different location you’ll need to replace c:\inetpub\passwordstate with the location of your Passwordstate instance.  Your screen should look similar to the one below;

Now that you’ve successfully encrypted your Database Connection String and AppSettings, you’ll need to restart your Passwordstate Windows Service.  To do this you can enter the following commands;

net stop “Passwordstate Service”, and,

net start “Passwordstate Service”

You should be presented with the following after running each command.

You can now exit out of command prompt.

Decrypting… an Example

This example is based on decrypting the two configuration elements used with your Primary Passwordstate instance.  These are connectionStrings and appSettings.

On your Passwordstate Web Server open a Command Prompt with administrator privileges and navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319.

Again note, if you installed Passwordstate in a different location you’ll need to replace c:\inetpub\passwordstate with the location of your Passwordstate instance.

Now type in aspnet_regiis.exe -pdf “connectionStrings” “c:\inetpub\passwordstate” to decrypt the connectionStringssection and press enter.  Once this is completed then type in aspnet_regiis.exe -pdf “appSettings” “c:\inetpub\passwordstate” to decrypt the appSettings section and press enter.  You should be presented with the following after running each command.

You’ll also notice in the image above we’ve stopped and started the Passwordstate Service.

This week’s blog links in with the theme of controls around accessing credentials, or Password Records in Passwordstate.  It follows on from the recent blog posts of Reporting Access To Sensitive Credentials and Getting Started With 2FA.

The Check Out/Check In capability operates at the Password Record level.  It enables users to manage access to the Password Record in collaborative environments where Password Records are shared.  When a Password Record is checked out, it becomes unavailable for others to use until it’s checked back in.  This prevents conflicts and ensures that only one person is accessing that system or account during the period it is checked out.  Auditing occurs as normal for any Password Record.

An example being, your organization keeps unique Account and Password combinations for all network switches.  You only have a small support team with access to the Password Records and are updating configurations or firmware on each switch.  You use the check-out/check-in capability to ensure only one support staff member can log into the switch being worked on.  If a second support staff member tries to access the password record they can’t.

Check Out and Check In Action

The below image is provided to show what the UI looks like when checking out a Password Record (image on the left) and again, when checking in the Password Record (image on the right).  Users trying to access the Password Record are provided the message Checked Out. 

If a user hovers over the Information symbol, they can view the UserID and Name of the person who has checked out the Password Record and any Auto Check-In Time that has been set.

Enable Check Out / Check In

The following applies to existing Password Lists and Password Records that you want to apply the Check Out/Check In capability to.  Select the Password List and navigate to the Password Record you want to apply the capability to.  From here, open the Password Record by clicking on the Title from the display grid.  This will open the record as below,

From here, click on the security tab, which will provide access to the Check Out capability.  You’ll need to click in the check box as shown below,

Then click Save.  On this screen you also have the options below,

Change Password On Check in:  This allows you to automatically generate a new random password for the Password Record and apply this during the Check In process.

Check In Automatically After:  This allows you to specify a time delay before automatically checking the Password Record back in.

Note, to successfully Change Password On Check In you’ll need to ensure the Password Record has both the Password Requires Check Out as well as the Check In Automatically After selected, and the Enabled for Resets has also been checked. 

Failure to do this will result in the Password field not being updated, but auditing will record that the Password Record has been updated with the time and date of the saving of the record, which could be misleading.

Enabling New Password Records for Check Out & Check In

The following applies to creating new Password Records set for the Check Out/Check In capability from an Account Discovery job.  For the purpose of this blog post we’re assuming you have an existing Account Discovery job, Host Entries and a relevant Password List.

Firstly, we’ll need to ensure the target Password List has the Enable Password Resets check box ticked.  This is set by right clicking on the Password List name and selecting Edit Properties, then clicking on the box as per below,

 Next, you can setup the Local Account Discovery job.  As per the image below, this discovery job will import all Local Accounts on HP Switches and Routers and add all newly Discovered Accounts to the Password List called Routers and Switches located in the Infrastructure folder, and perform an immediate Password Reset for the account,

Lastly, make sure to check the boxes Password Requires Check Out, and if required Change Password on Check In as per the image below,

What is Two-factor Authentication?  It’s a security measure that requires a user to verify their identity using two different methods.  In doing this, there is an extra layer of security compared to just accessing an account with a username and password.  You’ll sometimes see this described as “using something you know” like a username and password, with “something you have” like a token or code.  You’ll typically see Two-factor Authentication abbreviated as 2FA.

2FA significantly reduces the risk of unauthorized access, even if someone has stolen a password.  Websites and service providers are increasingly using 2FA to protect users’ credentials from being used by hackers, who have stolen a password database or used phishing attacks, to obtain user passwords. 2FA requires a possession factor or an inherence factor to be used along with the knowledge factor (username and password).

Possession Factors can include an ID card, a security token, a mobile phone, a mobile device or a smartphone app, to approve authentication requests.

Inherence factors, also referred to as biometric factors, is something inherent in the user’s physical self, such as fingerprints or facial characteristics, to approve authentication requests.

Options For Two Factor Authentication

In addition to the primary Authentication options of Active Directory and Local Logins, Passwordstate supports multiple authentication options that can be used in 2FA approaches,

The above list can be found on our website under Authentication Options on the Products menu.  The majority of these authentication options are possession factors and are used with your knowledge factor, either Active Directory user account and password, or local login account and password.

Authentication Options: Where Are They Set?

The Authentication Options in Passwordstate are set in a number of areas.  Globally, you can set the base Authentication, including your chosen 2FA in System Settings.  This will apply to all accounts accessing Passwordstate.  This is the recommend approach that will cater for the majority of users.

 Or, you can allow individuals to set their own authentication options under their user Preferences (you can also hide this option). 

Or, you can mandate what authentication options are required based on Security Group Membership.  This is extremely useful when also being used with Single Sign-on (SSO) and you need to cater for individuals that operate within a highly privileged account set.

With all of these options, Click Studios Best Practice for Passwordstate Authentication is to cater for the majority via global settings and fine tune for major alternatives via User Account Policies.  Setting Authentication options under preferences should normally be used for high value/impact individuals (read Business Executives).

Authentication Options: How Are They Set?

For people new to managing Passwordstate, the simplest Authentication Option to set is the global setting (also referred to as the System Wide Setting).  To do this navigate to Administration->Systems Settings->authentication options, and under Web Authentication Options select your preferred 2FA from the drop down list labelled Choose Authentication Option

Remember to select an option that uses the 2 factors, for example Manual Login and Google Authenticator.  If you want to disable the ability for individuals to set their own authentication options you can set the options to be excluded under Hide the following Authentication Options on User’s Preferences screen,

The next option is under User Account Policies.  This should be the go to area for exceptions to global authentication settings,

Under Administration->User Account Policies you can define specific options for how Passwordstate looks and behaves, including the type of Authentication Option to use.  The options available from the drop down list are identical to those present under system settings, with an additional option of Use the System Wide Authentication Settings.

Once you have specified all the options for your chosen PolicyName you’ll need to apply the policy to a user or users.  It is highly recommended that you use Security Groups to define who your policy is applied to.

In the example above, Passwordstate is using AD Single Sign-on as the global setting and specifying that all Security Administrators instead must use Manual Login and Google Authenticator as their authentication option.

Lastly, if you have decided to provide it, is the ability for users to set their own preference for authentication options.  This is managed on a per user basis under Preferences->Preferences->authentication options->Web Authentication Options.  Once again, the options available from the drop down list are identical to those present under system settings and include the Use the System Wide Authentication Settings.

Additional Options

Passwordstate has additional options for 2FA.  These include providing the option for accessing Passwordstate outside of your normal IP address ranges, when accessing a Password List containing highly confidential credentials and providing an additional level of security when using the Emergency Access account.

The first is found under Administration->System Settings->allowed ip ranges.  Here you can set additional Authentication Options for when users try to access Passwordstate outside of the list of Web Site Allowed IP Ranges (image below),

This is useful for authenticating users that work remotely, such as on-call Administrators, when they need to access Passwordstate from anywhere outside the corporate network.

Next is for highly confidential Password Records.  You can specify at the Password List level, that users must first authenticate using the specified Additional Authentication, before accessing any of the Password Records within that Password List,

This adds an additional layer of security when accessing those highly confidential or sensitive Password Records.

Lastly, you can enable 2FA on your Emergency Access Account.  This is a highly recommended best practice for Passwordstate.

In summary, 2FA significantly reduces the risk of unauthorized access, and Passwordstate provides multiple authentication options for organizations to choose from.

From access to Passwordstate, access to highly confidential password records, access based on security group membership and the IP address range a login is originating from, our 2FA options have got you covered.

This week’s Blog revisits one written in 2020.  The focus being on alerting Security Administrators and other interested people when particular passwords, or credentials, are accessed.

But first to recap, Passwordstate uses the concept of a Password Record, that contains amongst other things a username and password combination.  It can also contain a URL, a description, an expiry date etc. 

Password Records are contained within a Password List.  Think of this as a logical grouping of like Password Records, an example being all website Password Records for accounts associated with purchasing IT equipment and consumables. You could then have different Password Lists for different types of purchasing, such as catering and office consumables etc.

Next, we have Folders.  Folders allow you to organize your Password Lists in a meaningful way.  This could be based on your organizational structure or using an activity based approach.  The example here could be all Password Lists used by IT System Administrators, stored under a folder called System Administrators, as opposed to those used by IT Desktop Support, stored under Desktop Support.

This approach of Password Records, contained within Password Lists, with like Password Lists being stored in Folders, provides a degree granularity that makes assigning permissions to those Password Records logical and easy.

Password Record being Reported:

We’re using an example here on how to report on specific Password Records being accessed.  In this example we’ve got a fictious Password Record for our primary banking account. 

This is already protected by applying permissions on the Password List and Folder, but as this is an account that provides full access to our bank, we absolutely want to know when it’s being used.

Below is the screenshot of the fictious account,

Scheduling the Report:

Next, we’ll setup a Scheduled Report that runs once every 5 minutes.  This report will only generate and send an email if the password for ClickStudiosAccount has been accessed.  If no one has viewed or used the password record then no email will be generated.  This prevents false positive emails and helps to focus your attention when one containing real information is received.

First, navigate to Reports->Scheduled Reports and click on Add Report as show below;

When Adding Scheduled Reports, on the report settings tab give it a Report Name and a Report Description (optional), but importantly make sure you CC in a user or an email address of your choice in the CC Report To field (image below). 

The report is sent to the person creating the Add Scheduled Report by default, but it will also be CC to the email address specified.  Ensure you tick the option to not send the report if no results are produced (to stop the false positives), and then choose the report type as Custom Auditing Report.

Next, on the schedule tab, select the frequency of One Time, click on the Generate report and specify a frequency of 5 Minute(s) (image below);

Then, on the auditing settings tab, select the Password List where the password is located, the Activity Types you wish to check for, Query Previous for 5 minutes (of auditing activity), and enter the unique value you set in the Description field of the Password record, then click on Save Report;

With Activity Types you can select more than 1 (one) type.  In the example we’ve selected the following Activity Types,

• Password Copied Between Lists
• Password Copied to Clipboard
• Password Retrieved
• Password Screen Opened
• Password Viewed

Note, the Activity Types are directly related to Auditing Events.

Receiving The Report:

The report will now run every 5 minutes, and on finding any entries matching the Activity Types selected, will email the person that setup the Scheduled Report as well as the email addresses specified on the CC line. 

The report will contain each of the matches that occurred during the 5 min time interval stated (image below),

This week’s blog was prompted by a support call we received.  A customer was enquiring what was the best way to ensure they were keeping up with the latest information related to Passwordstate Builds and renewals.

This post references a number of different areas, from the main Click Studios website, to our internal licensing portal as well as our forums and your own Passwordstate instance.

Change Log

On our website, located under the Download menu, you’ll find our Change Logs.  We publish 2 Change Logs, one for the current major version, Passwordstate V9, and one for the previous major version.  The image below shows the Change Log for V9,

The Change Log details all changes that are included in each build of Passwordstate.  This enables customers to review the changes and make informed decisions on associated change, impact and / or risk associated with updating to that build in their organization. 

The information provided includes the build number, release date, descriptions of the changes, along with flagging any associated database schema or security updates.

Change Log entries are posted when Click Studios releases each new build and publishes the matching SHA-256 based checksum for the latest download file.

Nominated Contacts

Click Studios has an internal licensing portal that holds the licensing details for each Passwordstate Registration.  The customer related details that are stored are the registration name (Customer Name), the Country and Industry sector (used for marketing purposes) and up to four (4) sets of contacts. 

These are referred to as Nominated Contacts, and contain a First Name, Surname and business email address.  They serve as the primary points of communication, receiving all license keys, critical product updates, and automated renewal notifications.  Customers can elect to use a generic email address as one of their four (4) Nominated Contacts if they chose.

Maintaining accurate and up-to-date Nominated Contacts is the responsibility of each customer.

Forums

Our externally hosted Forums site enables customers to assist one another by sharing knowledge and information, submit requests for future functionality, and subscribe to content. 

To access the Forums site, select Forums from the Community menu on our website.

Then login, or if you don’t have an account Sign Up for one (it’s free). 

You can view each of the Forums including Announcements,

If you have an Account, and are logged in, you can Follow the content.  This allows you to set the frequency of emails sent to you advising of the new content.  For example, in the image below we’re following the Announcements Forum, and want to receive An email when new content is posted.

In doing this you’ll receive an email every time we release a new build.

RSS Feed

Click Studios provides an RSS feed capability from our website.  An RSS feed is a web feed format used to publish frequently updated content like blog posts, or announcements. It allows users to subscribe to a website’s feed and receive updates without constantly visiting the site.

To access the RSS feed, navigate to Advisories at the bottom of the Media menu.  At the bottom of the Advisories page, you’ll find the RSS feed URL.  This will need to be added to your RSS reader. 

As an example, you can use Microsoft Outlook (classic) and right-click the RSS Feeds folder, select Add a New RSS Feed, paste the URL from the website shown above and click Add.

Now, when new announcements are released, you’ll receive an email like below,

New Build Alerts

Lastly, if your Passwordstate instance has access to the Internet, it can be configured to reach out to our website to determine if a newer version of Passwordstate has been released.  If a newer build has been released a message will be displayed in the Notifications area, see below,

You can set the frequency of this check to 7, 14 or 30 days, or set Do not check for new builds (this is not recommended).  You can also show new build alerts to all users or just your Security Administrators.

In summary, by ensuring your Nominated Contacts are up to date, subscribing to either our Forums and / or RSS feed, and enabling Check for New Builds you should always be notified of the latest information related to Passwordstate Builds and renewals.

Then, it’s simply review the changes as advised in our Change Log and plan the change in accordance with your organizations Change Management policies and procedures.

Introduced in Passwordstate Version 9 Build 9905, passkeys are a phishing resistant credential that can be used to replace passwords.  It is a cryptographic credential, based on asymmetric public-key cryptography and uses a public-private key pair.  The webserver or Relying Party has the public key associated with the account.  The users Authenticator holds the private key for the account.

The specification for passkeys falls under FIDO2 and the World Wide Web Consortium’s (W3C) Web Authentication or WebAuthn specifications. 

Passkeys allow a user to sign in to websites using a similar process to how they unlock their device, using biometrics, a PIN, or a pattern.  They are typically used instead of entering a username and password combination on a login page.

In the Passwordstate implementation, the passkey’s private key is stored inside the corresponding Password Record.  This means that wherever the user logs into Passwordstate from, so long as our Browser Extension has authenticated back to Passwordstate, the user can access and utilise their passkeys, or the corresponding username and password combination, to login into the website.

High Level Workflow

The diagram below demonstrates the workflow related to a website login using a passkey.  This is a high level representation and is not intended to be an in-depth technical description of the process,

1. The User browses to the login page of a website they have a passkey for.  Note the browser is termed the User Agent and the website is referred to as the Relying Party in this workflow.  Typically, the user will select a prompt to either login with username and password, or, login with passkey.
2. When selecting to login with passkey the Relying Party (website) issues a Challenge to the User Agent (web browser) for the credential id of the user.  Remember, the Relying Party only has the public key relating to the public-private key pair.
3. The User Agent forwards the challenge to the Authenticator (the Passwordstate Browser Extension) for the corresponding private key stored in the Password Record for that website.  The User Agent then prompts to User for verification to use this passkey to login to the website. On positive verification, the Authenticator uses the stored private key to sign the Challenge.  This creates the cryptographic signature which is sent back to the User Agent.
4. The User Agent verifies the cryptographic signature using the public key and informs the Relaying Party of a successful authentication.  The website now responds and admits the authenticated user.

Real Example: Adding A Passkey!

The example we are using in this blog is for the Target website.  We have previously created a username and password combination and saved this Password Record in Passwordstate.  Next, we login to the website, navigate to settings and click on Sign in & Security (image below),

This takes us to the Sign in & Security settings, where we have the option of creating a Passkey by clicking on the Add passkey button (image below),

When clicking on the Add passkey button, the Passwordstate Browser Extension will prompt to save the Passkey to the existing Password Record used to login to the website (image below),

On clicking Save, the private key belonging to the private-public key-pair is saved in the Password Record.   The public key belonging to the private-public key is saved by the website.  The website will then typically display a message that the passkey has been created (image below),

The passkey is now available for use.

Real Example: Login With Your Passkey!

In case you missed the notification on screen, most websites will send through an email advising your passkey has now been added to your account.  The Target example is shown below,

Now, when browsing to the login page of the website, we can elect to either login using our Username and Password combination, or by using our passkey.  When clicking on the Sign in with passkey, the website will issue the challenge and Passwordstate’s Browser Extension will prompt to Login with Passkey?

When clicking on the Browser Extension Login button, the private key for the private-public key pair will be retrieved (image below),

the Browser Extension will sign the challenge request using the private key, the web browser will validate the cryptographic signature using the public key and confirm a successful authentication to the website.  The website will now accept the authenticated request and permit us entry.

Your Password Record

As stated previously, the passkey private key is saved to the Password Record.  The image below shows the Password Record used for this example.

Benefits of Passkeys

Organizations who implement support for passkeys typically see the following benefits as passkey use increases:

• Safer, more secure, and faster online experiences for users
• Reductions in phishing, credential stuffing, and a reduction in attack surface