Customizing Email Templates

Passwordstate uses emails to communicate events to Systems Administrators and Users.  The events range from failed logins to account status changes and information regarding password access, expiry and when credentials are copied to the clipboard.

Almost all emails are supplied in template form and can be individually customised to conform to an organizations style, culture and internal language.  Only system dependant emails, such as those used to alert for Annual Support and Upgrade Protection expiry, are fixed and unable to be modified.    

Where are Email Templates Located?

All Email Templates for the core Passwordstate product are located under Administration->Passwordstate Administration->Email Templates.  From here you can;

  • Enable or disable individual templates,
  • Modify the contents of a template, including previewing and testing the template,
  • Enter additional recipients for selected emails,
  • Restore the template back to its default wording, and,
  • Enable or disable all templates.

Customers with subscriptions for the Password Reset Portal Module can modify the email templates associated with Verification Policies under Administration->Password Reset Portal Administration->Verification Policies.  From here you can;

  • Modify the 3 enrolment email templates for each Verification Policy,
  • Any email that is sent as part of the Verification Policy being used, and,
  • Preview each email template.

and under Administration->Password Reset Portal Administration->System Settings->password expiry reminder template, you can;

  • Select the number of days to alert before a password reset is required, and,
  • Modify the contents of the template, including previewing it.

Passwordstate Email Templates

Each of the core Passwordstate Email Templates located under Administration->Passwordstate Administration->Email Templates includes a description.  This description states who the email is designed to be sent to.  These are typically either Password List Administrators, Users, Security Administrators, or Creators of Self Destruct Messages,

To modify a template, simply click on the name of the template (in this example we’re using the Access Request Template) and enter the customized text then click Save.

Note you can also click on Preview to see what the email will look like as well as testing the result with Test Email.

Password Reset Portal Email Templates

As stated earlier in this blog entry, customers with a subscription for the Password Reset Portal Module also have Email Templates that can be customized.  To modify the wording used in the Password Expiry Reminder email navigate to Administration->Password Reset Portal Administration->System Settings->password expiry reminder template,

From here you can modify the Email Subject and email body.  Again, you can click on Preview to check the formatting is what you’ve intended before clicking Save.

Next, for each of the Verification Policies you are using, use you can modify the 3 enrolment email templates and any emails sent when using the verification policy.  Simply navigate to Administration->Password Reset Portal Administration->Verification Policies, and click on the name of the policy you want to modify (in this example Email Temporary Pin Code),

From here you can modify the wording for each of the 3 enrollment emails as well as the email used to send the temporary pin.  Please note verifications policies that don’t use email, in the verification process of a user’s identity, will not be shown here as an additional email option.

Again, simply change the wording as required for each of the email templates, preview the results as appropriate and don’t forget to click Save when you’re finished!

By customizing the Email Templates to match the language and style of communication used in your organization you can reduce confusion and maintain consistency of in-house style.

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Customizing the Passwordstate UI

Passwordstate has a substantial amount of flexibility with multiple configuration options.  It provides many options for storing, securing, sharing, displaying and using password credentials and associated information. This flexibility enables your Security Administrators to tailor your installation of Passwordstate to best match your organizational requirements.

While this flexibility can be invaluable it can sometimes also result in information overload for your users.  To maximize the usage of Passwordstate across your user base you should consider streamlining the UI (User Interface). The intent being to provide a simplified, functional interface that doesn’t distract or overwhelm your users.  

What Can be Simplified?

There are logically 4 categories of settings that can be used to simplify the UI for users.  These categories can be thought of as;

  • Passwordstate Build and Notifications
  • Unused Menu Groups and Items
  • Access to Hosts
  • User Account Policies

Passwordstate Build and Notifications

This category relates to displaying the build of Passwordstate being used and access to the Notifications Area.  The current Passwordstate Build is normally displayed in two separate areas, the Administration Area (Red Dot 1) and in the Passwordstate Title Logo (Red Dot 2) as per the image below;

The Notifications Area (Red Dot 3) displays notifications such any New Builds that are available, and alerts for,

  • Maintenance renewal reminders
  • Password Reset reminders for Forms-based and Local logins
  • Pending Access Requests requiring review, approval or deny
  • Days remaining for trial license
  • Reminder for Encryption Key Rotation
  • Windows Service unavailable on primary server
  • Ad Blocker detected for the Passwordstate website
  • Health Check based on errors in Error Console, excessive queued emails and excessive Auditing Records

The settings for Passwordstate Build and Notifications are contained in two separate areas.  The first relating to the Passwordstate Build (Red Dots 1 and 2) is controlled by;

  • For Red Dot 1, access to the Administration Tab is only provided for Security Administrators.  This doesn’t affect standard users.
  • For Red Dot 2, visibility of the Build Number at the end of the Passwordstate Title Logo is set under Administration->System Settings->branding Show Passwordstate Build Number.  This allows you to Show the Build Number at the top of the screen to All Users or Only Security Administrators.  Simply click on Only Security Administrators and your users will not see the build number when they login to Passwordstate.

Visibility of the Notifications Area is role dependent.  Users will have access to any notifications of a functional nature, including;

  1. Password Reset reminders for their login,
  2. Any Pending Access Requests requiring their review, approval or deny, and,
  3. If they have an Ad Blocker that is detected for the Passwordstate website.

All other notifications are only displayed for Security Administrators with the exception of advertising a new Passwordstate Build is available.  To ensure this is turned off for all standard users navigate to Administration->System Settings->check for updates and under Show new build alerts for make sure Only Security Administrators has been selected.

Unused Menu Groups and Items

Most users will never need all of the Menu Items located on the left-hand side of the screen.  These can be either hidden, or disabled and when doing this we strongly recommend you base the changes on Security Groups as opposed to manually entering user accounts.

For our example, if a user is never going to use the Reports->Auditing option you can remove this Menu item by navigating to Administration->Feature Access->menu access, ensuring If a user doesn’t have access to a Menu has Hide it from them selected and then Set Permissions to not include that user (again based on a Security Group wherever possible),

This will remove the Menu item Reports->Auditing as per the image below (normally shown where the red arrow is),

Alternatively, if the users don’t require any of the menu items for a specific group, say Reports, then you can hide the entire group by using the Set Permissions next to the Menu Group.  This can be done for all Menus Groups except Passwords.

Access to HOSTS

Generally speaking, the Hosts Tab is only used by staff or contractors in an IT Department.  It is used to enable remote access into network devices, servers and other PCs.  By default, all users have access to the Hosts Tab,

As most of your users will be unlikely to need the Hosts Tab you can remove it by navigating to Administration->Feature Access->Hosts and clicking on the Hosts Tab Permissions button,

From here it’s the standard Passwordstate permissions screen and you simply need to search for the groups that should have permission and add them using the >> button.  You can also select the All Users and Security Groups and remove that from the Applied Permissions screen using the << button.

User Account Policies

Our recent Blog entry https://blog.clickstudios.com.au/develop-user-account-policies/ talks about how useful User Account Policies are for controlling settings for different groups of users.  We’re not going to go back over the same material but simply highlight the settings and values you can consider for simplifying the UI for your users.

Add UAP TabSetting IDSettingValue
User preferencesA14Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation TreeNo
Password List Screen OptionsB4Make the Recent Activity Grid visible to the user This is all the Auditing data for the selected Password ListFalse
 B6Make the Pie Charts visible to the user Pie Charts on the right-hand side of the pageFalse
Home Page Screen OptionsC1Dashboard Layout Settings Use the icon to the right to organise Zones and Panels. Do not try to modify the data in this textbox manuallyTick Zone 1 and Zone 2
 C2Show the Password Statistics Chart Show or hide the chart which represents Auditing data, displayed at the bottom of the pageFalse

And when you put it all together…

Using one of our internal users as a test case you can go from this,

To this,

Hopefully this helps demonstrate how you can simplify the User Interface and not distract or overwhelm your users with information and options they may not require. 

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Develop User Account Policies

One of the many strengths of Passwordstate is that it uses RBAC, or Role Based Access Control to assign granular permissions to objects stored within the system.  RBAC restricts access based on a person’s role and is one of the main methods for advanced access control.  In Passwordstate this means that users can only access the credentials, hosts and information that’s related to their job and that they’ve been assigned access to.  Access can be based on their need to view, create, or modify credentials or stored information.  Using RBAC helps in securing your company’s credentials and subsequently the access to sensitive information.

What’s needed to assign Granular Permissions?

The majority of Passwordstate implementations are Active Directory Integrated.  This means that Passwordstate has been installed so that it can readily integrate with and utilise/synchronise User Accounts and Security Groups setup in Microsoft’s Active Directory.  This allows you to fast track the appropriate Accounts and Security Groups rather than creating them from scratch (if you are using Forms Based Authentication). 

The choice to setup your system as Active Directory Integrated or to use Forms Based Authentication is performed on initial setup under System Settings;

But don’t be concerned if you’ve setup Forms Based Authentication, we supply documentation on our website that guides you through the migration from Forms Based to Active Directory Integrated (and AD to Forms Based).  Navigate to https://www.clickstudios.com.au/documentation/ and follow the appropriate documentation as indicated below;

How do you assign these Granular Permissions?

First, you’ll need to ensure the Security Groups and User accounts have been imported into Passwordstate and that you have a folder hierarchy that looks similar to your organizational structure.  For reference, a blog on setting up a folder structure matching a fictious organizational structure is located here https://blog.clickstudios.com.au/guide-to-set-up-folder-structure-and-permissions/.

Next, you’ll need to ensure you’ve added the required Security Groups from AD that contain the users you want to assign permissions for.  While the image below has a lot of arrows it is straight forward.  Navigate to Administration->Security Groups and click on the Add AD Security Group located beneath the display grid on the Left-Hand Side.  This will take you to the screen below.  Now search for the Security Group Name you’re after, Select the Name in the Security Groups Search Results and then click Save;

You can of course do the same thing with User Accounts, but you’re better off assigning permissions based on Security Groups as a general rule.

You can now assign permissions for this Security Group on Folders and Password Lists.  The example here is the Security Group Server Administrators has been granted Modify Permissions on the Password List SharePoint Accounts,

So…What Are User Account Policies?

User Account Policies allow you to manage specific sets of settings for groups of users.  The settings relate to various user settings normally set under a User’s ‘Preferences’ area, and ‘Screen Options’ for Password Lists and Folders.  When a User Account Policy is applied to a User (in this context as a member of a Security Group) it disables their ability to modify the settings under ‘Preferences’ themselves.

There are 34 different settings that can be applied to a User Account Policy.  While a lot of the options control cosmetic settings, such as Specifying the Base Color or Show Header row on all Passwords Grids the keys ones of interest for this blog are;

  • Mask Password Visibility on Add/View/Edit Pages
  • Auto Generate New Password When Adding a New Record
  • Specify which Authentication option will apply to the user’s account
  • In the Passwords Navigation Tree, Use Load On Demand Feature
  • Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation Tree
  • Make the Recent Activity Grid visible to the user
  • Set the Mobile default home page to Password List Search or Password Search

These settings are particularly useful for different groups of users.  For example, you could mandate that all members of Server Administrators, that by virtue of their role have access to highly privileged accounts, can’t just use SSO (Single Sign-On).  Instead, the User Account Policy for the Security Group Server Administrators ensures that in addition to SSO they must use Google Authenticator as a second method of authentication when logging into Passwordstate.

To setup User Account Policies, navigate to Administration->User Account Policies and click on Add.  This will take you to the Add User Account Policy screen

From here you’ll need to provide a Policy Name and Policy Description, and change the required settings across the following areas;

  • User Preferences
  • Password List Screen Options
  • Home Page Screen Options
  • Mobile Access Options, and,
  • Password List Options.

Once you made all your changes click Save at the bottom of the Screen.

Apply the User Account Policy to your Security Group

Now we’ve created a User Account Policy, in this case Google Authenticator, we can apply it to the Server Administrators Security Group.  Select the Action menu next to the User Account Policy and click Apply Policy to Users.  This will bring up the User Account Policy Permissions screen.  It’s then a matter of searching for the Security Group, selecting it with the >> button and clicking Save

Now when all Server Administrators browse to your Passwordstate URL they will be prompted to enter their Google Authenticator OTP even though the global authentication settings under Administration->System Settings->authentication options->Web Authentication Options are set to Passthrough AD Authentication.

User Account Policies Are Additive

When developing your User Account Policies, you can do so in a couple of ways.  You could go ‘all out’ and have one policy for the primary Security Group that caters for all the settings you want to take effect.  Or you can take the ‘incremental’ approach and have policies with only a few settings in them.    

The latter approach of incremental policies is effective in that you can reuse those policies time and again for different Security Groups.  And when the policies are applied at logon they are additive.  By this we mean that the all of the applicable policies are applied to the user.  You just need to remember that if you have the same setting in multiple policies, but each policy has a different value, the last of those policies takes priority.  Polices are applied top to bottom with those lower in the policy grid taking precedence over those higher in the grid. 

User Account Policies are an extremely useful tool when catering for different settings for different groups of users.  All that is required is some thought and testing to achieve the results you want.

Got feedback? We’d love to hear it via support@clickstudios.com.au

What’s with the Red Crosses?

With the production release of Passwordstate V9 in March 2021 we changed the existing Permission Models used in Passwordstate Version 8.  These changes, based on feedback from our Global user community, were aimed at simplifying the methods of assigning permissions while still providing flexibility.

Recently our support team have been receiving a number of Support Requests asking for assistance with issues associated with understanding and rectifying incorrect permissions.  We’ve also been receiving support requests stating there appears to be an error, with some folders showing red crosses on them.  So…what’s with the Red Crosses? 

A Quick Recap on Version 8 Permission Models

First let’s do a quick recap on the permission models that existed before Passwordstate V9.

The Standard Permission Model enables the permissions to be set on the Password List, in the image below the Credit Cards Password List. These permissions are then inherited or rolled-up through the Folder Structure to enable access to the Password List.  Again, in the example anyone that is provided permission to Credit Cards also has permission applied to the folders Finance, London and Click Studios to ensure they can get to the Credit Cards Password List.

Using the Propagating Permission Model, you set the permissions required at folder level and these permissions propagate down to the target Password Lists. You would set the permissions at the London folder and all nested folders and any Password Lists they contain will have those permissions set the same.  In the example blow, London and Finance have the same permissions and the two Password Lists, Credit Cards and Online Systems are accessible.  If the folder has a downward pointing green arrow then the permissions model is Propagating.

With the Manual Permissions Model, you could specify a folder to have the permissions manually set.  Manual Permissions only apply to the folder they are set on and do not inherit permissions from any nested folders or Password Lists beneath it.  If a folder has a blue padlock, then the permissions model is Manual.

You’ll note that in the image above the Click Studios folder is set using the Manual Permissions Model and the folders London, Finance and the two Password Lists in the Finance Folder have been set using the Propagating Permissions Model.

What Changed under V9?

The Beta 1 release of Passwordstate V9 introduced 2 significant changes to the Permissions model.  The image below shows the reference in the Change Log, dated 11th January 2021,

  • The first of these changes was that Folders and Password Lists could be configured to block inheritance from parent objects, and,
  • and second, the Manual Permissions Model was removed and replaced with blocking of inheritance and propagation of permissions to nested folders and Password Lists.

This model was subsequently called the Advanced Permissions Model.  But what does that actually mean? 

An Example

Let’s use an example to clarify the new model.  The Advanced Permissions Model allows you to disable inheritance of permissions from above, at any folder level in your structure, and then set and propagate a different set of permissions to any folders and Password Lists below that folder level.  It effectively replaces the Manual Permissions Model used under version 8.  Let’s use an example based on the image below;

The Red Circle 1 shows that Propagating permissions have been set at the Customers Folder and these are propagating down to each folder as shown the Blue downward arrow.  Except for the Allsand folder which has blocked inheritance from above, has different permissions applied to it and is propagating these to any nested Password Lists.

Red Circle 2 also shows that inherited Permissions have been blocked by using the Advanced Permission Model at the Customer Service Folder, with a different set of permissions set for that folder and these propagating down to the nested Password List Web Logins.

In Summary, the Red Crosses simply show that inheritance has been blocked at that folder and new permissions have been set and propagated down to any nested folders or Password Lists.

Got feedback? We’d love to hear it via support@clickstudios.com.au

Importing Passwords via CSV

Passwordstate is an Enterprise Password Management Solution…check.  It allows the secure storage of passwords and other associated data of interest…check.  It provides auditing of access and change on these passwords and associated data…check.  But how do you get Password Records into Passwordstate?  Good Question!

Passwordstate provides a number of mechanisms to add Password Records into Passwordstate.  These include adding records via;

  • Browser Extension.  This is arguably the most basic method of adding a password record to Passwordstate.  It is limited to web site credentials and a user’s Private Password List or selectable for any of the Shared Password Lists they have access to.  On entering your Account Credentials on a web site login screen you’ll be prompted to save the record in Passwordstate.
  • UI (User Interface).  This is the next most basic method of adding a password record.  It requires the user to have logged into Passwordstate.  From here the user chooses where the record should be added, either a Shared or Private Password List and adds the new password record and all associated information.
  • AD Synchronization.  This is typically setup by a Security Administrator and is based on adding your Active Directory Domain information and then synchronizing selected AD User Accounts and/or Security Groups (including their Users) into Passwordstate.
  • API.  You can use custom scripts to utilize the Passwordstate Standard and Windows Integrated APIs to add password records.
  • CSV (Comma-separated Values).  You can generate a CSV template and populate it with the records to be imported.

Adding Password Records Use Case

The example we are using for this week’s blog is the migration of user accounts for the CEO’s Performance Management Portal.  These were previously stored in a separate password management system and are being migrated into Passwordstate.  Prior to the migration I’ve created a Shared Password List under the CEO Office Folder and called it Performance Portal.  As you can see in the image below there are currently no Password Records in this Password List,

I’ve based the Password List on the Web Site Logins template and created the Password List using the Add Shared Password List Wizard.

Next, we’ll generate an appropriate CSV (Comma-separated Values) Template that matches the default fields for our Password List.  This is done by clicking on the List Administrator Actions… drop down list and clicking on Import Passwords,

This brings up the Import Passwords Screen, effectively a mini-wizard style process that allows the creation of the CSV Template that is used for capturing the records that will be imported,

Simply click on the Generate CSV Template button.  This will create a Comma-separated Value file as shown in the image below.  Note that I have Microsoft Excel installed and that is why the file titled results.csv is shown as an Excel file.

When you click on Open file the results.csv file will open, in this example with Excel.  I’ve copied across all the data to the correct fields as per the image below and saved the file, making sure not to convert it to a .xls file.

Now we’re ready to test the import and if everything is ok, import those password records.

Check and Import the Records

In this example, we’ve already created the Shared Password List called Performance Portal, and created a matching import template based on the type of Password List we’re storing the records in.  We’ve populated the CSV template results.csv with the records and are now ready to import them.

The first thing we now do is test the import process.  This is found on the tab labelled step 3 – import data,

Simply select the file results.csv using the Select button, and then click on Test Import.  This provides you with an opportunity to test importing the data against the field definitions shown under step 2 – populate template with data.  All being well you’ll be presented with the Import Successful screen advising the test import of records successfully passed the import process.

Now click on the Continue button, reselect the step 3 – import data tab, reselect the results.csv file and then click on Import Passwords.  You will now be presented with the Import Successful screen as show below;

And to prove the records were imported correctly, on clicking Continue we are automatically taken back to the Performance Portal Password List showing that the records have indeed been imported as per the image below,

The Import using a CSV template is a useful means of bulk importing password records from other systems and spreadsheets.  The key is ensuring that the right CSV template is used (generated for the target Password List).  And to be 100% sure test the import first!

Got feedback? We’d love to hear it via support@clickstudios.com.au

Updates to Licensing and Encryption Keys

We recently published a blog on how easy it was to rotate your Passwordstate Encryption Keys https://blog.clickstudios.com.au/how-to-rotate-your-encryption-keys/.  Since then we’ve released V9 Build 9350 which introduces a number of related features.

Key Rotation Reminder

NIST recommends a life span of up to two years for Symmetric Data Encryption keys. This is the type of encryption key used by Passwordstate and Click Studios strongly recommends that customers manage and rotate their Passwordstate encryption keys on a regular basis.  Please note that while the NIST standard is for up to 2 years, the environment in which it is used, the characteristics of the data being protected along with your organization’s risk factors need to be taken into account.

With this in mind, Passwordstate now allows you to set a notification prompting you to update your Encryption keys.  This can be found under Administration->Encryption Keys as per the image below,

The options provided are for 6, 12, 18 or 24 months. The reminder works by sending a message to the Notification area located in the top right-hand side of the UI (User Interface).  The notification sent is;

Encryption Key Rotation Reminder. Best Practise recommends it’s time to generate new encryption keys, and re-encrypt your data. This can be done on the screen Administration -> Encryption Keys.

This notification is only a reminder and there is no enforced rotation of encryption keys.  The reminder is only visible to Security Administrators that have been granted access to the Encryption Keys Role under Administration->Security Administrators.

Confirming the Encryption Used

When Passwordstate is first installed you have the option of installing it to use either 256 Bit AES Encryption or FIPS 140-2 (Federal Information Processing Standards) Encryption.  Click Studios recommends installing your Passwordstate instance to use the default 256 Bit AES Encryption unless you are mandated by the United States Government to configure your Microsoft Windows environment in FIPS compliance mode.

If you’re unsure what encryption is currently being used in your Passwordstate instance, simply navigate to Administration->Passwordstate Administration and look at FIPS Encryption.  If you are using the default 256 Bit AES Encryption the value will be set to No.  If you are running FIPS Encryption then the value will be set to Yes,

Changing the type of Encryption Used

For the purpose of the blog, you’ve confirmed the type of encryption used (256 Bit AES Encryption) and need to change to FIPS encryption.  The first thing that is required is to obtain a FIPS version of your license keys.  To do this you’ll need to request a copy from Click Studios sales team via sales@clickstudios.com.au.  When requesting the FIPS license keys you’ll need to send through an image of your License Information screen with all license Keys fully visible (the screen below has the keys redacted),   

Once you’ve received the new license keys you’re ready to start.  Navigate to Administration->Encryption Keys-> Encryption Key Rotation and make sure to read the information provided.  Once you’ve completed any required steps, you’ll need to Enable Maintenance Mode, return to the Previous screenand then click Begin Key Rotation,

And So It Begins

The first thing you are prompted for is to confirm you’ve read the notifications and understand that action is required by you, and if you want to migrate from the standard AES 256 Bit Encryption to the FIPS 140-2 Encryption.  Tick both boxes and then click on Begin Key Rotation.

You’ll now be able to update the license keys in the Update License Information screen with the updated keys provided by Click Studios Sales.  Copy and paste each key into it’s respective field, ensuring there are no leading or trailing spaces (the keys in the image below have been redacted), and then click Next,

You will now be taken to the Encryption Key Rotation screen showing all the Tables and Records that will be re-encrypted with the new FIPS based keys.  To commence the process, click on Re-Encrypt Data.  The image below shows the data being re-encrypted with the tick symbol showing completed tables and the clock symbol showing tables and records still to be processed,

When the process is complete the Key Rotation Complete screen is presented.  Again, please read the details presented, undertake any post Key Rotation tasks as advised and then click on the Start Passwordstate button,

Once you have logged back into Passwordstate you can check that you’ve been re-encrypted using FIPS 140-2 encryption by navigating to Administration->Passwordstate Administration and look at FIPS Encryption.  It will now show FIPS Encryption set to Yes,

And proving you can change it back again

And for the purpose of this blog, I’ve changed our demo environment back again by running the same process and re-encrypting using AES 256 Bit Encryption.

Restrictions on Usage

The type of keys you use are registered in our internal licensing portal and are used for automatically generating your license keys on renewal of your Annual Support and Upgrade Protection.  If you ask for FIPS keys and then decide to use your AES keys you will need to let us know.  Otherwise we’ll generate new license keys in the incorrect format.

Customers with Global Licenses will need to use either the 256 Bit AES Encryption or FIPS 140-2 keys.  It is not possible to have both sets recorded in our internal Licensing Portal and renewed automatically.

Tracking when to rotate your encryption keys, and converting between AES and FIPS encryption (and vice versa) is easy under V9 Build 9350.   We hope this information helps you to understand the process and would love to hear any feedback via support@clickstudios.com.au

Password Lists Linked to Templates

Passwordstate provides the capability of storing both Shared Password Lists and Private Password Lists.  Shared Password Lists, as implied can be used to share either the entire contents of the list, or just individual Password Records.  Private Password Lists, again as implied, cannot be shared and are private to Owner / Password List Administrator of the list.  This is regardless of whether the Private Password List was created directly by the Owner, or it was created for them as part of the process of adding their account in to Passwordstate.

And just recapping, Passwordstate allows more than just the storing of Passwords.  In fact, the number of different types of Passwords and associated details / meta data is almost limitless.  This provides you with substantial flexibility when it comes to storing information in Passwordstate. 

To get you started Passwordstate provides 15 Password List Templates and a Password List Wizard.  You can also add your own Password List Templates to for specific fields containing data you want to control and audit access to.  You can even link your Password Lists to the Password List Template it’s based on. 

Why Link Password Lists to Templates?

When a Password List is created, you have the option to Link this Password List to the selected Template that it’s based on.  But what advantages does this provide?  Password List Templates are used to apply consistency to settings for your Password Lists.  In large implementations, instead of having to manually modify hundreds or even thousands of Password Lists to incorporate a change, you can instead link them to the Template they’re based on.  When you do this, you manage all settings for all those Password Lists from that Template.

In the example above, the PeopleSoft Password List has been created and linked to the Enabled for Password Resets Template. This means the majority of options for the PeopleSoft Password List will be disabled when you chose to Edit Password List Details as per the image below;

And to be clear, it could be any of the above settings, or fields located under the customize fields tab that need to be changed.  For any Password Lists that are linked to a Template you only need to make the change to that Template.  To do this you’ll need to navigate to Administration->Password List Templates, select the Template and click on its name in the Password List field.

Once you’ve made your changes and clicked Save, the changes are cascaded to all Password Lists that have been linked resulting in enormous savings in time!

Implications on Linking Password Lists to Templates

So you ask, what’s the downside?  You can only make individual changes to a Password Lists that isn’t linked.

To unlink the PeopleSoft Password List, from the Enabled for Password Resets Template in our example, we’ll need to click on the Action icon for that Template and select Linked Password Lists,

From there you’ll be able to select the Password List (PeopleSoft) and click on the << button and then click on Save.

Please be aware, ‘Unlinking’ Password Lists that contain any non-compatible Generic Field Types, will cause those values to be cleared in the database.  The same is true when ‘Linking’ a Password List to a Template.  You’ll be presented with a dialog box presenting you with this warning and requesting confirmation before performing the action.

How do I Find What Password Lists are Linked to Templates?

To identify which Password Lists are linked to which Templates simply look at the Linked Password Lists column in the display grid for Password List Templates.  You can click on the Linked Password Lists column to sort it based on Highest to Lowest or Lowest to Highest.  Then open the Template you’re interested in and it’ll show the names of all the Password Lists linked to that Template.

Have Feedback? We’d love to hear it and you can send it through to support@clickstudios.com.au

Mobile App Settings

We recently published a blog on Reporting on Mobile Client Usage.  Since then, a number of the Technical Support team members have asked what we’ve published on how to configure the Mobile App.  Looks like there isn’t much outside of the official documentation so we’ve produced this week’s blog.

Control Who Has Access

The native Mobile Apps for iOS and Android Smartphones incorporate Biometrics Support for application access.  They provide an offline mode allowing access to an encrypted cache of credentials the user would normally have access to, all with full auditing of access that is synced back to your Passwordstate instance. 

While the apps are free and available from the Apple App and Google Play Stores you may want to control who has access to that functionality.  This is really no different in principle to the Browser Extensions feature, where you set the permission for the user, or preferably the Security Group, that you want to enable access for.

To set the permission for those users that can access the Mobile App navigate to Administration->Feature Access->mobile and click on the Set Permissions button,

From here, you’ll select the User or Security Group that you want to apply permission for.  In the example below we’re setting the permission for one of our users, Abagail, to be able to access the Mobile Native App feature.  Once you’ve selected all your Security Groups and Users click on the >> button and click Save,

Specify Settings for the App

You can now set the global mobile access options for those users that have been granted access.  To do this navigate to Administration->System Settings->mobile access options.  The first section relates to the Mobile App Settings,

Here you can make settings for;

Brute Force Dictionary Attacks:  Just like protecting your Passwordstate instance, you can specify the maximum number of failed login attempts before the active session for that mobile client is locked out.  In the image above we’ve kept the default at 3.

Enable Mobile Access Permission on Password Lists: You can choose to enable Mobile Access by default when adding permissions to Passwords Lists.

Passwords Masked or Visible:  You can specify if the passwords are masked or visible in the Mobile App.

Password Strength Policy for the Master Password:  Set the Password Strength Policy you want to use when users set their Master Password for the Mobile App authentication.

Cache Life:  Set the number of days the offline cache can live for before the user must re-authenticate.  Re-authentication occurs when entering their email account and Master Password and also when they resync their cache on the device.

The second set of settings relates to the Mobile App URL and Security,

URL for the Passwordstate App Server:  Set the URL for your Passwordstate App Server.

Reset the Pairing Secret for the App Server.

SSL Public Key:  Query and save the Public Key for the SSL Certificate.  This mitigates against Man-in-the-Middle attacks.

Once done save the settings by clicking the Save button.  Please note, if you change the App Server URL or your SSL Certificate you will need to clear then re-query and save the SSL Public Key.

Users Preferences and their Master Password

Lastly each user sets their Master Password for the authentication from the Mobile App to the Passwordstate App Server.  To do this they must navigate to Preferences->mobile access options as per the image below;

Here they will set the Master Password which generates a QR Code.  This QR code needs to be scanned in on the Mobile App that has been installed on that user’s smartphone.  The user can also set their preference for the home page search to be based on a Password List Search or Password Search.

If you’d like to provide feedback, please send it to support@clickstudios.com.au.

Reporting on Mobile Client Usage

The Passwordstate native Mobile Client apps for Android and iOS were introduced in V9 Build 9000.  These replaced the old Mobile Client support providing remote access to managed credentials while away from your normal place of work (desk). 

The native apps are designed to work with the Passwordstate App Server, which brokers the connectivity between the client device and your Passwordstate instance.  It allows for storing password records that a user is authorized to access, locally on the smartphone, within an encrypted cache.  Users have the ability to use the biometric capability of the smartphone when accessing the data within the encrypted cache.  All authentication and access of credentials is audited and synced back automatically with Passwordstate on next connection.

But how do you know when your users are using the offline copy of their passwords.  How do you ensure that they are using them when and where required?

We Have a Report for That!

Passwordstate has over 100 different Audit events, including those relating to usage of the Mobile Apps.  As stated above all access to stored credentials within the encrypted cache, and all synchronizations of credentials between your Passwordstate instance and a Mobile Client, are audited.  These audit records are uploaded automatically each time the Mobile App successfully synchronizes with the App Server. 

This ensures you can report on the activity of your users that have been setup for Mobile Client usage.  To be able to do this Navigate to Administration->Reporting 

And select the Activity Report called Mobile Client Activity,

You can now filter the report based on User Account, Site Location and Duration in terms of the reporting period you select from the drop-down list,

and once you’ve clicked Run Report button the audit records matching the selected filters will be shown within the display grid.   

You can now export the results to Excel for further manipulation as required,

Make the report a Scheduled Report

Don’t forget you can setup the Mobile Client Activity report as a scheduled report and have it emailed through on a regular basis.  Simply navigate to Reports->Scheduled Reports and add a report like in the image below.

If you’d like to provide feedback, please send it to support@clickstudios.com.au.

How to Rotate Your Encryption Keys

Click Studios uses Symmetric Data Encryption within Passwordstate to protect your sensitive data.   It does this using 256bit AES (Advanced Encryption Standard) data encryption to encrypt (cipher) and decrypt (decipher) information. At a high level the process of encryption and decryption looks like this;

AES is the first and only publicly accessible cipher approved by the US National Security Agency (NSA) for protecting top secret information. 256bit AES is practically unbreakable by brute force based on current computing power, making it the strongest encryption standard available.  In short, by using symmetric encryption algorithms, data is converted into a form that cannot be understood by anyone not possessing the secret key to decrypt it.

NIST the National Institute of Standards and Technology, recommends that Symmetric Data Encryption Keys be changed every 2 years, or earlier based on an organization’s risk factors.  Your Passwordstate Encryption Keys shouldn’t be “set and forget”, they should be managed and rotated on a regular basis.

But Before You Start…

Make sure you have a backup of your Passwordstate Database and take a copy of your Web.config file.  The built-in Backup functionality is perfect for taking a backup and you can do this by navigating to Administration->Backups and Upgrades->Backup Now

If you’ve never used the built-in functionality, you’ll need to configure settings first under Administration->Backups and Upgrades->Settings.  Information on how to do this can be found here https://www.clickstudios.com.au/documentation/ for both Domain and Workgroup implementations.

Follow the Bouncing Ball…

Now that you’ve taken a backup of your Passwordstate database and have a copy of your Web.config file you’re ready to get started.  And it really is as easy as following the bouncing ball! 

Under Administration->Encryption Keys you’ll find 2 buttons, Export Keys and Key RotationExport Keys allows you to create a password protected Zip file containing your Encryption keys and we’ll cover more on that later.  First, we’re going to focus on Key Rotation.  To get started click on the Key Rotation button,

You’ll now be prompted to ensure you have a backup of your Passwordstate Database and a copy of your Web.config file.  Take the time to read through the information before clicking on the box next to I have read the notification above and understand some action is required of me before and after the key rotation.  If this check box isn’t ticked then you won’t be able to proceed with the Key Rotation.  Once you’re ready, and you’ve ticked the check box, you can click on the Begin Key Rotation button,

As you can see in the image above, The Encryption Key Rotation screen lists all of the tables, the number of records in each table and the Status for each.  To commence the rec-encryption process click on the Re-Encrypt Data button.

The status symbol of a Clock means that table hasn’t been re-encrypted yet.  The status of a Tick means the table has now been re-encrypted and the Flashing Blue Squares identifies the current table being re-encrypted.  A Status message of Please Wait… is shown at the bottom left-hand-side of the display grid listing the tables. 

As the tables are re-encrypted, they will cycle off the first page of the display grid and be replaced by tables awaiting to be re-encrypted.  When there are less tables awaiting to be re-encrypted, than take up the full display grid, you’ll start to see those tables that have been completed (shown by a status of Tick) moving back up the display grid.  Once complete you’ll be taken to the Key Rotation Complete Screen.  Again, take the time to read through the information before clicking the Start Passwordstate button.  This will log you off and you will need to log back into Passwordstate.

Don’t Forget… Take a copy of your New Encryption Keys

Now, cycling back to the Export Keys button.  Once you’ve successfully rotated your encryption keys it’s good practice to take a copy of them.  This can be done by navigating to Administration->Encryption Keys and clicking on the Export Keys button.  You’ll be taken to the Export Encryption Keys screen which tells you that the split secrets that make up your Passwordstate Encryption Keys are exported via a Password Protected ZIP file.  To begin the export process, click on the Export Keys button,

This will pop up the Password Protected Zip File dialog, which will require you to supply a password for the Zip file.  You will also be required to check the box stating that you cannot use the native Windows Compression to extract the contents of the Zip file.  Once that’s done you can click on the Export Keys button to create the Zip file containing the exported encryption keys.

The process of rotating your Passwordstate Encryption Keys is that simple and the effort required to rotate them is minimal.  There really is no reason not to be managing them appropriately.

We’d love to hear your feedback, send it to support@clickstudios.com.au.