Passwordstate Build 7580 New Features

In build 7580 of Passwordstate, we’ve introduced a few new features, most noticeably many changes in how encryption now works. Below is a summary of the more notable changes and features.

Encryption Changes
In consultation with an external company who specialises in web-based application security, we’ve made several changes to how encryption works within Passwordstate. Most of these changes are not noticeable in daily use, but they do further strengthen the security of Passwordstate. A summary of the changes are:

  • Random Initialisation Vectors are now used for every encrypted field and record – previously, the one Initialisation Vector was used for all encrypted data
  • HMAC-SHA512 Hashing algorithm has now replaced the previous method of validating tampering of data directly in the database – hashing of expected values, with a stronger algorithm, is now used to ensure data integrity
  • Every install of Passwordstate now uses two unique keys to perform the encryption, instead of previously it only used one
  • Encryption Keys now use Secret Splitting to mask their identity, and the secrets are stored in the web.config file (which can also be encrypted) and also in the database
  • A new Secret Key Rotation feature has now been added to allow regular encryption key rotation
  • And encryption keys can now be exported to a password protected zip file for disaster recovery purposes

With these encryption changes, it is very important that you have the following for disaster recovery purposes:

  • A copy of your database
  • And a copy of your web.config file, or of the exported encryption keys (split into secrets) in the password protected zip file.

Without these two items, it will not be possible to restore your Passwordstate instance in the event of a disaster – even with the Help from Click Studios. You must keep a copy of these encryption keys.

Most of these changes are transparent in day-to-day usage, except for the exporting of encryption keys, and encryption key rotation which we will cover below.

Exporting of Encryption Keys
There is now a new menu item in the Administration area called ‘Encryption Keys’. From here you can Export your encryption keys using the appropriate button, at which time you will be presented with the popup dialog for you to enter the zip file’s password. Note: Exported encryption keys adds a relevant audit record.

It is recommended you export your encryption keys immediately after upgrading to Build 7580, as well as take a backup of your database. Any time you perform encryption key rotation as well, you will be required to export your encryption keys again.

Encryption Key Rotation
Performing encryption key rotation is a very simple process, but it is very important to back up your encryption keys and database before performing this task – in the event some sort of error was to occur during the re-encryption, you need your previous keys to perform a restore. Please follow the on screen instructions for preparing for key rotation, as per the screenshot below.

Once key rotation starts, it will cycle through each of the relevant tables, and re-encrypt data as appropriate. The schedule in which you perform key rotation is a decision your Passwordstate administrators would need to make. Auditing records are also added for encryption key rotation.

One-Time Password Two-Factor Authentication
We’ve also introduced a new two-factor authentication option, for both the web interface and mobile client, called One-Time Password.

With this authentication option, you can use either hardware or software tokens which are compatible with the TOTP or HOTP algorithms – TOTP is Time-Based, and HOTP is Counter-Based.

On the screen Administration -> System Settings -> Authentication Options tab, you will see the following settings for this new authentication option. A brief description of these settings are:

  • Time-Based Clock Drift – as hardware tokens age, they can lose time. This setting allows you to specify what is the maximum clock drift which is allowed for a user’s hardware token – effectively it will look ahead (x) number of seconds to try the time based authentication. If a match is found, and the clock on the user’s token appears to have ‘drifted’, then the time differential is stored as part of the user’s preferences for this authentication option
  • Time-Based Default Time Step – most TOTP tokens work on either 30 or 60 seconds intervals, and you can specify the default time step for new user accounts in Passwordstate here
  • Counter-Based Look Ahead Window Size – each time the user generates a new One-Time Password when using HOTP, the counter increases on their token. When a successful authentication attempt is made in Passwordstate, this counter value is also stored as part of the user’s preferences for this authentication feature. As tokens may be used for different systems in additional to Passwordstate, we need a look-ahead window size to determine what the actual value of the counter is for the user’s token
  • Counter-Based Default Number of Digits – HOTP generally uses passwords of 6 digits in length, but you can configure the default for all new user accounts added into Passwordstate if required

User’s Preference Settings for One-Time Password Authentication
In the user’s Preferences screen, they can select either of the Time-Based or Counter-Based authentication options, and then settings as appropriate. They must also specify their Base32 Secret Key, which will be provided with any hardware tokens you purchase (this key should be 32 characters in length). If using software tokens, you can generate a random Base32 key here, and then use it for your software token.

Note: If the user neglects to specifying these settings, and a Security Administrator of Passwordstate were to enable One-Time Password authentication for them, then they will be given the opportunity to specify their settings when they next try and access Passwordstate.

One-Time Password Authentication Screens
And when you browse to Passwordstate to authenticate, you will see one of the following screens depending on which authentication option has been applied to your account.

Miscellaneous Features
We’ve also added various other features based on requests for customers, and they are:

  • There is now a System Setting for blocking brute force dictionary authentication attempts to all authentication screens in Passwordstate. The default setting is 5 failed login attempts, at which time the user’s session in IIS will be locked out. This setting can also be customized to how ever menu failed login attempts you want
  • On the screen Administration -> System Settings -> API Keys tab, there is now a setting to prevent users from specifying API Keys within the QueryString of an API Call, instead forcing them to include the API Keys in the header request – which is more secure as the API Key is encrypted in the SSL tunnel
  • In Build 7476 we introduced a new feature to prevent the creation of Password Lists or Folder beneath other Password Lists. We did this primarily because it was causing confusion for customers in relation to the permission model, but also when trying to search for password records. We had several requests from customers to allow this type of nested, so we’ve now added a System Setting where you can turn this restriction off. You can find it on the screen Administration -> System Settings -> Password List Options tab, and the setting is called ‘Allow users to nest Password Lists and Folders beneath other Password Lists’

We hope you like these changes in Build 7580, and please keep the feature requests coming J

Click Studios

Passwordstate Permission Model Changes

In build 7476 of Passwordstate, we introduced a new Permission Model which customers have been requesting for a while. You can now set a top level folder to propagate it’s permissions down to all nested Password Lists and Folders.

The traditional model of setting permissions at the individual Password List level is still available, and if you do not wish your users to use this new model of propagating permissions down, you can disable it on the screen Administration -> System Settings -> Miscellaneous tab -> Enable the ‘Propagate Permissions Downwards’ feature for top level Folders.

Things to note about this new Permissions Model:

  1. You can only apply permissions to a top level Folder in the Root of ‘Passwords Home’
  2. You can only make changes to permissions on the Folder at top of the tree – nested Password Lists and Folders will have controls on the Permission pages disabled
  3. If you drag and drop a Password List, or a Folder containing Password Lists into another Folder structure with propagating permissions, it will ask you to confirm you wish to make this change as permissions will change
  4. Private Password Lists cannot be nested beneath a Folder which is propagating permissions down
  5. The ‘Bulk Permissions’ feature cannot be used for any Password Lists which are inheriting permissions from a top level Folder
  6. A couple of System Settings options for applying permissions to newly created Password Lists will be ignored
  7. When adding or editing a Password List, the options to clone permissions from other Password Lists or Templates will be disabled

How to use the new permissions model on a new Folder Structure:

  1. Ensure you have these two settings set to ‘Yes’ in Administration -> System Settings -> Miscellaneous:

  1. Create a Folder under Passwords Home. In this example we’ve called it “Windows Desktop Machines”
  2. When creating the Folder, ensure you tick ‘Manage permissions manually for this folder’ and ‘Enable the Propagate Permissions Downwards
  3. Once saved, you’ll notice a slight change to the Folder Icon. The brown triangle on the right hand side indicates it is now propagating permissions, and anything nested below it will inherit those permissions.

  • Next highlight the Folder and select Folder Properties.


  • Click the View Permissions Button and use the Grant New Permissions button to set permissions. This can be an individual users or Security Groups

Now any new Password Lists or Folders you create or drag into this Folder will automatically inherit those permissions.

How to convert an existing Folder structure to use the new permission model:

  1. Select your top level Folder and select ‘Folder Properties’
  2. Ensure you have ‘Manage permissions manually for this folder‘ selected
  3. Click the ‘Convert Permission Model‘ button
  4. Run through the three step Wizard:

    Step 1: Review what changes are about to happen
    Step 2: Review existing Permissions, and modify them to suit
    Step 3: execute the conversion

That’s it! Now when you make a change to the permissions at the top level folder, they will cascade all the way down the folder. Any existing Password Lists will inherit these permissions and new ones created under here will be forced to use the same permissions.

NOTE: As mentioned earlier, the new Propagating Permissions Model can only apply to a Folder in the Root of Passwords Home. If you have an existing Password List structure under your ‘Passwords Home’, you will need to create a new Folder first, move the Password Lists into the folder, and then apply the conversion.

Passwordstate Build 7393 New Features

Build 7393 introduce quite a few changes to the Password Reset, Discovery and Validation processes, which we’ll cover in this blog post in some detail. Once again, thanks to our fantastic customers who continue to provide feedback on how we can improve our software.

Password Reset Changes
Depending on the password reset script used, previously you may have needed to associate a Privileged Account Credential with a password reset script so a remote connection to the host could be made to perform the password reset. This is no longer the case, instead now you associate the Privileged Account Credential with the password record itself. This provides greater flexibility, because you can now use the same password reset script, but using different Privileged Account Credentials if required.

We’ve also made some changes to any reset tasks that may fail. It is now possible that a failed reset can be “rolled back” in Passwordstate, so the value of the password stored still matches what is in use on the Host. When this occurs, appropriate auditing data is added, Password History updated, and in the email you receive informing you of the failure, it has a status column indicating whether a rollback was performed. As it is possible to link a single password record to many host records, a rollback may not always be possible – for example, 45 Windows Workstations had their local administrator account password successfully changed, but 5 failed due to them being turned off. In this instance, there is a retry schedule you can set, as per the screenshot below.

We now have some options for also changing password reset options in bulk for password records – e.g. if you wanted to change the schedule when resets occurred on Windows Workstations, then you can do this with the new ‘Bulk Update Password Reset Options’ feature.

The process for this is relatively simple, with screenshots below:

  • Search for the password records you want to change
  • Modify various fields if required
  • Change Reset and Heartbeat options as required

The following table also describes which Reset Scripts require a Privileged Account to be associated with it, and certain notes for specific configurations which are required:

Script Name

Privileged Account Required

Reset Cisco Enable Secret


Reset Cisco Host Password Priv 1


For Privilege Level 1 type accounts
Reset Cisco Host Password Priv 15


For Privilege Level 15 type accounts
Reset COM+ Component Password


Reset Dell iDRAC Account Password


Reset F5 BIG-IP Account Password – AS


Accounts in BIG-IP appliances can be configured with Terminal Access of type ‘Advanced Shell’ or ‘TMSH’. You need to select the appropriate BIG-IP reset script to use, depending on the Terminal Access type for the Privileged Account Credentials you have associated with the Password Reset Script
Reset F5 BIG-IP Account Password – TMSH


Accounts in BIG-IP appliances can be configured with Terminal Access of type ‘Advanced Shell’ or ‘TMSH’. You need to select the appropriate BIG-IP reset script to use, depending on the Terminal Access type for the Privileged Account Credentials you have associated with the Password Reset Script
Reset HP iLO Password


Reset IBM IMM Account Password


When resetting passwords on IBM IMM cards, you must know the LoginID of the account you wish to reset passwords for. In order to use this script, you must configure a Generic Field for the PasswordList with the name of ‘LoginID’ and this is where you can store the value for each account you wish to reset passwords for
Reset IIS Application Pool Password


Reset Linux Password

Yes or No

  • If you do not associate a Privileged Account Credential with this script, you will SSH to the host using the account you wish to reset the password for
  • If you specify a Privileged Account Credential, you can SSH with this account, and then reset a password for a different account
  • If you want to reset the ‘root’ account password, then you need to specify a Privileged Account Credential to SSH with, and then the root account can be reset – generally most environments do not allow you to SSH in using the root account
Reset MySQL Password


Reset Oracle Password


Reset Scheduled Task Password


Reset SQL Password


Reset VMware ESX Password


Reset Windows Password


Reset Windows Service Password


Testing Scripts Manually
We’ve now added the ability to test each of the Reset, Validation and Discovery Scripts right within the Passwordstate user interface. Simply add one or more Hosts on the screen, specify various other field parameters as well, the hit the ‘Run Script’ button.

Account Heartbeat
In addition to the reports which can validate passwords are in sync between Passwordstate and the Hosts, there is also now a regular Account Heartbeat feature which can be enabled for password records which are configure for resets. Simply select the appropriate Password Validation Script, and the time of the day you wish to perform the validation.

The “rolled up” status of all linked Hosts records is then visible in the Passwords grid.

And when you view the linked Hosts to the password record, you can see the status of individual machines.

Host Heartbeat and Treatment
There is also a Host Heartbeat process in this build, and this can check on regular basis if your Hosts are available on online on the network.

The schedule for the Heartbeat poll which occur once a day, and is randomized between the hours set for each of the different Operating System types – which can be changed on the screen Administration -> Host Types & Operating Systems. Being able to set the hours in which the poll will occur is useful for desktop operating systems where machines may be turned off during the night.

And we have several options for how we treat Host records if the Host has not been seen on the network for some time. This is again useful for workstations and laptops which may have been decommissioned.

Simplifying Discovery Process
We’ve also simplified and made various changes to the 3 different types of Discovery Jobs we have – discovering Hosts in Active Directory, Local Administrator Accounts, and various Windows Resources which may be configured to run under the identity of a domain account. Some of the changes are:

  • Host Discovery – You can now also discover Linux hosts which have been added to Active Directory. The field we query in AD is the OperatingSystem attribute, and the values we query for this can be changed for each Operating System on the screen Administration -> Host Types & Operating Systems
  • Host Discovery – You no longer copy permissions to new Hosts from an existing Password List, instead there is a ‘Permissions’ tab on the Discovery Job screen which you can configure
  • Host Discovery – If a Host is no longer found in any of the OUs specific for the Job, there are options now for setting the Host to ‘Unmanaged’, or you can delete it if preferred
  • Local Admin Accounts – You no longer need to select the Password Reset script to associate with these discovered accounts, and you can also Include/Exclude certain named accounts from the discovery if required
  • Windows Resource Accounts – When discovering Windows Services, IIS Application Pools and Scheduled Tasks, you no longer need to select the Password Reset Scripts you wish to associate with these discovered accounts

Further Password Reset Support
We’ve also added a few more Password Reset Scripts, for the following systems:

  • F5 BIG-IP Load Balancers – thanks for your help on this Oscar J
  • Dell’s iDRAC out of band management cards
  • IBM’s IMM out of band management cards

Passwordstate Remote Session Launcher

In version 7 of Passwordstate, we have introduced a new feature called the Remote Session Launcher. This feature allows you to perform RDP, SSH, Telnet or VNC remote session connections directly from the Passwordstate web site, without having to manually enter any authentication credentials. This post will detail the system requirements, installation instructions and usage information for this feature.

Overview & System Requirements

The Passwordstate Remote Session Launcher allows you to perform RDP, SSH, Telnet or VNC remote session connections directly from the Passwordstate web site, without having to manually enter any authentication credentials.

To use the Remote Session Launcher feature, you must be using a Windows Desktop/PC, and have PowerShell 3.0 or above installed.

During the installation, the PowerShell script ‘PSLauncher.ps1’ will be installed to the destination directory, allowing you to customise this script if required. Putty and VNCViewer are also installed to this path as well.

Also during the install, 4 custom new protocols will be added to your registry, which are:

  • HKEY_CLASSES_ROOT\psrdp (for RDP sessions)
  • HKEY_CLASSES_ROOT\psssh (for SSH sessions)
  • HKEY_CLASSES_ROOT\pstln (for Telnet sessions)
  • HKEY_CLASSES_ROOT\psvnc (for VNC sessions)

These custom protocols allows to execution of the PSLauncher.exe utility directly from within your Browser.

Once the Remote Session Launcher utility is installed, it will log connection attempt both in the Auditing section of Passwordstate, and also to a log file called ‘PSLauncher.log’ located in the Remote Session Launcher utility folder. Additional debug logging can be added to this file if needed, by modifying the file ‘PSLauncher.ps1’

Installation Instructions

To Install the Passwordstate Remote Session Launcher Utility, please follow these steps:

  • Within the Passwordstate web site, navigation to your Preferences screen, and then on the ‘API Keys’ tab, create a Remote Session Launcher API Key, and then click one of the Save buttons
  • Now click on the HTML link you see on this screen for installing the Remote Session Launcher Utility – the path to the files is https://<mypasswordstateurl/remotesessionlauncher/passwordstatelauncher.exe
  • At the ‘Welcome’ screen, click ‘Next’
  • At the ‘Destination Folder’ screen, change the path if needed and click ‘Next’

  • At the ‘Remote Executables Path’ screen, change any paths if required, enter the URL of your Passwordstate web site, and click Next

  • The click the ‘Next’ button, and finally the ‘Finish’ button
  • Restart your Browser if it is currently open

Browsers and Launching External Applications

The Passwordstate Remote Session Launcher feature uses ‘Custom Protocol’ browser support in order to launch external applications.

Before you can start to use this feature, your browser needs to be configured to accept these custom protocols, and this can be done in Passwordstate by going to the page Preferences -> Remote Session Credentials, and then clicking on the ‘Configure Browser Support’ button. By clicking on this button, you will be shown a window like the screenshot below.

From here, your browser will present you with an additional popup window when you click on the appropriate protocol type – as per the following screenshots. Click the option to remember this setting, and then close all windows.

 Internet Explorer



Hosts & Remote Session Credentials

Now the Remote Session Launcher utility is installed, you need to add the required number of Hosts to Passwordstate, and apply permissions to them for the users who wish to launch remote sessions to – please refer to the Passwordstate User Manual for instructions on this.

There are several different ways in which you can authenticate your Remote Session to Hosts, and they are:

By Creating One or More Remote Session Credential Queries
Remote Session Credentials can be located in Passwordstate under the Preferences menu. Within this screen, you can create on or more ‘queries’ which allows the use of different credentials for different types of hosts.

As per the screenshot below, you build up the query based on different criteria, and then link the query to a saved Password record in Passwordstate. It is the UserName and Password of this Password record which is passed as the credentials to the Remote Session client.

Once you have created one or more Remote Session Credential queries, all you need to do is click on one of the Hosts on the Passwords Home page, or the dedicated Remote Session Launcher page (found under the main Tools menu), and the appropriate remote session will launch – as per the screenshot below.

  • Note: When launching a Remote Session connection, if there are no matching saved Credentials you will be prompted to manually type the UserName and Password. If there are more than one matching saved Credentials, you will be prompted to select which Credential to use.

Remote Session Launcher with These Credentials
Under each ‘Actions’ menu item for individual password records, there is a menu item called ‘Remote Session Launcher with These Credentials’, as per the screenshot below. When you select this menu item, it will allow you to search which Host you wish to connect to, and then authenticate with the selected password credentials.

Manual Credentials for Remote Session Launch
Another option is to select the ‘Manual Credentials for Remote Session Launch’ Actions menu item for one of the Hosts, as per the screenshot below. This will present you with a dialog which allows you to manually type the Username and Password to connect to the Host.

Passwordstate 7.0 New Features

Hi Everyone,

We’re sorry for being so quiet for the past few months, but we’ve been busy working on this biggest release of Passwordstate since its initial release in 2004. We’re getting close to finishing it, with only a couple more features left to code and test. In total there about 80 updates in version 7, and below are some of the major features coming.

New Vertical Navigation Menu
In version 6 of Passwordstate we introduced a new Horizontal menu system at the bottom of the page. While this was well received by most customers, some customers didn’t like it. So in version 7 you will have the option of either a horizontal menu at the bottom of the screen, or a new vertical menu on the left-hand side of the screen.

There are 3 ways in which you can choose the Menu System to use – 1. It can be applied System Wide for all users, users can choose it as part of their Preferences, or you can create a User Account Policy and apply the setting to specific users or security groups.


Different Colour Themes
So you probably noticed a different shade of blue above J Yes, we’ve finally added in colour themes for version 7, and they can be applied the same way as the menu option above can be applied – System Wide, User Preferences or User Account Policy. Believe it or not this took quite a bit of work, as we needed to figure out how to change the colours applied to the Telerik ASP.NET Ajax Controls –


Browser Extensions for Form-Filling Web Site Logins
We’ve had a lot of customers requesting this feature, so we’re very excited we can finally offer it. Initially we will be releasing the extension for Chrome, and once we and our customers are happy with the functionality of it, we will provide extensions for Internet Explorer and Firefox as well.

Most of you are probably familiar with this sort of extension, and it will be similar to the functionality provided by LastPass, RoboForm, or any of the other offerings. Basically it allows you to save all your web logins into a Password List of your choice, and then every time you visit the site the extension can login for you automatically, without you needing to type in your username and password.

Discovery Different Windows Hosts on the Network, and Manually Add or Import Linux/Routers/Switches, etc
In itself, this feature doesn’t provide any real functionality, but is a pre-requisite to two other major features in version 7. You have the option to import Hosts via a CSV file, or we’ve added a ‘Discovery’ process which can query your Active Directory environment for Windows Hosts, and automatically import them into Passwordstate.

Access to each of the Hosts within Passwordstate are also permission based, so once imported you need to apply permissions for users who wish to make use of the new features which rely on the Hosts records. Below are a couple of screenshots of the Hosts screen, and the Discovery screen.

Reset Passwords Just About Everywhere
One of the major features in version 7 is the ability to change passwords automatically on various remote systems. The following will be supported when V7 is released:

  • Active Directory Accounts
  • Local Windows Accounts
  • Windows Services
  • IIS Application Pools
  • Scheduled Tasks
  • Cisco network equipment (routers, switches, etc)
  • Linux/Unix Accounts
  • Microsoft SQL Server and MySQL Server accounts

The Password Reset, Password Validation, and Resource Discovery features, are all achieved via the use of PowerShell scripts (we’re calling Windows Services, IIS App Pools and Scheduled Tasks ‘Resources’ in version 7). In the early planning stages, we were a little undecided whether to build our own ‘agents’ to be deployed to hosts to allow the password resets, or whether to use PowerShell scripts. In the end, it made much more sense to use to use PowerShell scripts, as it gives our users a lot more flexibility if they need to modify a script themselves, and some customers already use PowerShell heavily for managing their Windows environment. Unlike any solution for accessing and make changes to remote hosts, there are some system requirements for this functionality – primarily the Windows hosts will require PowerShell 2 or above installed, and PowerShell Remoting enabled. We provide full documentation for what’s required here. This functionality also works for non-trusted Active Directory Domains, so if you look after a lot of different client environments, all you need is functioning DNS, and domain account credentials with privileges to make the change. Below is a screenshot of the default scripts we provide, as well as a screenshot of one of the scripts. You can modify these scripts, restore the default script, or add your own.

As an example of the flexibility of this feature, when a password is updated in Passwordstate, you can also execute a PowerShell scripts to run any of your own custom MS SQL or MySQL scripts, say to update data in a table. The possibilities are only limited by your scripting skills J


Discovery Windows Services, IIS App Pools and Scheduled Tasks
As mentioned above, it’s possible to perform password resets for Windows Services, IIS Application Pools, and Scheduled Tasks which are configured to run under the identity of a domain account. While you can manually add these ‘Resources’ into Passwordstate, we’ve provided a feature where by you can automatically discovery them on your network, associated them automatically with the appropriate host, and also add the domain account used to a selected Password List if it doesn’t already exist in it.

Launch RDP, SSH, Telnet and VNC sessions to Remote Hosts
This is another new feature which takes advantage of adding/importing hosts into Passwordstate. Once you have installed out Remote Session Launcher utility (Windows only), and created one or more ‘Remote Session Credential Queries’, then you can launch a remote session to Hosts without having to enter your credentials to authentication – it logs you in automatically, and adds appropriate auditing records to reflect the action. The basic process use this functionality is:

  • Install the Remote Session Launcher utility (Windows only, and requires PowerShell to be installed)
  • Make sure you have all your Hosts added/imported into Passwordstate
  • Create one or more Remote Session Credential queries, and link it to a password you have stored in Passwordstate – screenshot 1 below
  • Now when you click on a Host in Passwordstate (screenshot 2 below), if the Host matches one of your saved “credential queries”, then it will launch the remote session without you needing to enter your Username and Password. There’s also an option to specify your login details manually if needed.

We also have provided a dedicated ‘Remote Session Launcher Screen’ which will allow you to use this feature all day long without being automatically logged out of Passwordstate if you are inactive for a period of time.


Two-Factor Authentication with Dou Security
We’ve had quite a few requests recently to support Duo Security Two-Factor Authentication (, so we’ve added support for this to the Web User Interface, and the Mobile App

More improvements to the API
We’ve also made some improvements to the API in version 7, specifically:

  • You can now add Folders and Password Lists through the API
  • We’ve made it more secure by allowing the API Key to be specified in the Request Header instead of the querystring
  • Private Password Lists can now be queried in the API, but only when using the Password List’s API Key, not the System Wide one.


And Various other Features
As mentioned, there are 80 updates in total, and below are a few more mentions:

  • New Dashboard Layout for Password Home and Folder pages – allows you to choose which panels to display, and where
  • New Favorite Password Lists feature, whereby favorites can be easily filtered in the Navigation Tree
  • New “Self Destruct Message” feature for sending time-bombed messages to other users
  • Added the ability to encrypt any one of the Generic Fields you can select for Password Lists
  • Auditing data for the High Availability instance is now maintained if the HA site is accessed
  • Added option to Password Lists to ensure passwords are not visible or can be copied to clipboard
  • Added option to force users to use the Password Generator associated with a Password List
  • User Account Policies can now dictate what Template to be used when creating Shared or Private Password Lists
  • Added the ability to generate random passwords based on a pattern of alphanumeric characters
  • Added the ability to exclude certain characters from a generated password
  • Filtering in the Navigation Tree can now also filter on Folders names
  • Users password, when using Forms based authentication, will now expire after a set period, and password reuse is prohibited
  • Email alerts from the High Availability instance of Passwordstate are now queued, instead of being sent real-time
  • Added the ability to see all Private Password Lists on the screen Administration -> Password Lists. Only features available with this is deleting the Password List, or changing settings
  • Moved all ‘Administration’ navigation menu items to their own Navigation Tree
  • It’s now possible to send specific email notifications to a generic email address


Quite a log post, but we have been busy J We hope you all like version 7 when it’s released in a month or two’s time.

Passwordstate Now Fully Integrated with Remote Desktop Manager

Not so long ago we have the privilege of working with the team at, to fully integrate Passwordstate with their awesome software Remote Desktop Manager ( If you are not familiar with Remote Desktop Manager, we strongly recommend you check it out as it is a very capable tool for ‘remoting’ into a large range of IT systems.

The beauty of the integration between Passwordstate and Remote Desktop Manager (RDM) is you no longer need to input your authentication credentials to remote into other systems – simply create a Passwordstate credential in RDM which links to a password within Passwordstate, then create a Session in RDM and select the credential. Let’s walk through how you would do this.

Creating a Passwordstate Credential in RDM

First you need to create a ‘New Entry’ in Remote Desktop Manager, and this can be done in a multiple of ways – right click in ‘Navigation’, or press the Insert key, or use the button at the top of the screen.

  1. Select the Passwordstate Credential type

  1. Give it a name, provide the API URL of your Passwordstate web site, as well as the API Key – the API Key can be one which is associated with a single Password List, or you can use the System Wide API Key to return all Password Lists

  1. Click on the eclipse button next to ‘Password List’, and select the appropriate Password List

  1. Now click in the eclipse button next to ‘Password’ and select the account you wish to use as the credentials. After this credential has been created, you can now associated it with as many Remote Connection Entries in Remote Desktop Manager as you want


Creating a Remote Connection Entry in RDM

In this example, we will create a simply RDP connection to a Windows Server 2012 server, and associate the Passwordstate credential above to it.

  1. Create a new Entry, and select ‘Microsoft Remote Desktop (RDP)’ entry type – look how many different remote connection types there are J

  1. Now specify the host name you want to RDP to, select ‘Credential Repository’ for the Credentials, then select the credential you created above

  1. Now the Remote Desktop Connection is created, click on ‘Open Session’ and you will be automatically logged into your server


That’s pretty much it for logging in remotely to your server, without ever having to type in those long annoying admin passwords J

If you haven’t yet come across Remote Desktop Manager, we strongly encourage you to download the trial and give it a run – it certainly makes your daily Sys Admin life a lot easier.

Click Studios

Choosing Good Passwords

We stumbled across the following article recently regarding Choosing Good Passwords, and thought it was definitely worth sharing. It’s from 2009, but all the guidance is still valid today. We strongly recommend you create one or more Password Generator Policies within Passwordstate, which encourage your users to use complex passwords.

Article Source –

How hard is it to choose a good password? Most people believe that choosing a good password is easy. After all, how is somebody going to guess my wife’s maiden name?
In reality, people usually choose poor passwords. In 1990 [Klein 1990] an attempt to crack a large password database revealed over three hundred passwords in the first fifteen minutes! One fifth of all password were obtained in the first week and approximately one quarter were cracked by the end of the search. More than half of the cracked passwords were six characters or less and some accounts didn’t even have a password.

An intruder only needs one password!

Choosing a good password is a trade-off between something that is difficult to guess versus something that is easy to remember. While@G7x.m^l is probably a good password, nobody will remember it and it is certain to appear as a sticky note attached to a terminal. Conversely, your first name is very easy to remember, but it is also trivial to guess.

Some simple rules of thumb

Some simple guidelines that will help you choose better passwords are:

  • A password should be a minimum of eight characters long.
  • Try to include some form of punctuation or digit.
  • Use mixed case passwords if possible.
  • Choose a phrase or a combination of words that make the password easier to remember.
  • Do not use a word that can be found in any dictionary (including foreign language dictionaries).
  • Do not use a keyboard pattern such as qwertyui or oeuidhtn (look at a Dvorak keyboard).
  • Do not repeat any character more than once in a row like zzzzzzzz.
  • Do not use all punctuation, all digit or all alphabetic.
  • Do not use things that can be easily determined such as:
  • Phone numbers.
  • Car registration.
  • Friends’ or relatives’ names.
  • Your name or employment details.
  • Any Date.
  • Never use your account name as its password.
  • Use different passwords for each machine.
  • Change the password regularly and do not reuse passwords.
  • Do not append or prepend a digit or punctuation mark to a word.
  • Do not reverse words.
  • Do not replace letters with similar looking numbers. For instance, all of the letters i should not be blindly replaced by the digit 1.

    Cracking passwords

    The principle behind password cracking is quite simple: take a large word list, encrypt each word and check if the encrypted string matches the user’s password. Word lists that are used frequently include English and other language dictionaries, common names, pet names, television and movie characters, character patterns on keyboards (for example, qwerty) and jargon or slang terms.

    To allow for the case that the user has not chosen a word in your word list, an intruder can and usually will apply a large number of simple rules to each word in the word list and check if any of these encrypt to the user’s passwords. Typical rules include appending and prepending digits and other punctuation characters to words, reversing words, capitalising words, converting words to all upper or all lower case, substituting letters or digits for other letters and naturally many combinations of these. Since computers are fast, applying these rules and encrypting the resulting guess doesn’t take much time and a lot of guesses can be made in a very short time.

    In addition, a CD based database is supposed to have been produced that contains every word in a large dictionary plus many rule based permutations of these words encrypted in every possible manner. This reduces password cracking to a simple (and fast) database lookup.

    How long is a good password?

    The simple answer to this is that in general the longer the password the better.

    Assuming that you’re using a reasonable selection of characters for your password, say letters and numbers, then the following table presents the number of passwords possible for the various choices of length. It also includes an estimate of how much time would be required to crack the password using a brute force attack.

    The cracking time field is derived from a report in September 1993 that claimed the record for the speed of cracking passwords. The claim was that 6.4 million passwords per second could be tested. Given that computer speeds are increasing continuously, the following times are almost certainly over estimates of the actual time required.

    Number of passwords for each length

    Number of Passwords

    Number of passwords

    Cracking Time



    Not nearly enough

    Try this by hand



    Three thousand

    Almost no time



    One quarter of a million

    Less than one second



    Fourteen million

    Two seconds



    Almost one billion

    Two and a half minutes



    Fifty six billion

    Two and a half hours



    Three and a half trillion

    One week



    Two hundred trillion

    One year



    Thirteen quadrillion

    Seventy years



    Eight hundred and forty quadrillion

    Forty centuries




    A quarter of a million years



    Even more

    Sixteen million years

    Having said that longer is better, it is important to note that many machines artificially restrict the length of the password usually by silently truncating what you enter to their maximum length. Since this length is often eight characters under Unix, the rest of this article will assume that an eight character password is being used.

    What characters should a good password contain?

    The previous section assumed that passwords consisted of upper and lower case letters and digits. What happens if this character set is increased or decreased? The following table presents some of the options for eight character passwords:

    Number of eight character passwords
    Type of Password

    Number of

    Number of

    Cracking Time

    7-bit ASCII



    Three hundred and fifty years

    Printable Characters



    Thirty three years

    Letters and Numbers



    One year

    Letters only



    Ninety six days

    Lowercase with one Uppercase



    Three days

    Lowercase only



    Nine hours

    English words: eight letters or longer



    Less than one second

    So clearly, the richer the character set being used, the harder it will be to crack passwords. You should attempt to include as a minimum both upper and lower case characters and if possible, you should also include some digits, punctuation symbols and/or control codes in your password.

    Rarely used passwords and secure storage

    There is one situation where writing down your password is a good idea – protecting something important that doesn’t require credentials very often. For instance, the root password on a server probably doesn’t need to be used every day.

    In a case like this it is a good idea to create a long, very complex password that is hard to remember, write it down and store the password in some kind of secure storage (like a safe). On the rare occasion that the password is needed it can be retrieved from storage and used (and the password then returned to storage). The password should still be changed regularly.

    Balancing Risk

    Of course, situations vary. If you find that you (or your users) have a tendency to forget passwords and start making simpler, less secure passwords it may be better to use a complex password and write it down.

    Just remember that if anyone gets a hold of the written down version they have a free pass into the system. Any written down passwords should not be kept on or near your computer and preferable should not be kept near any information that identifies you. Store it securely – a locked drawer is much better than your wallet.

    Examples of how to construct good passwords

    So now that typical bad passwords have been discussed, how is a good password constructed? Try combining two or more words together or taking the first (or second or last) letter of each word in an easily remembered phrase. Then mangle the result by adding capitals, digits and punctuation characters. As an extra measure, control characters can also be introduced.

    Some examples of using multiple words with punctuation

    Here is a pair of good examples of using multiple words:

  • gOt%L0st! – got lost!
  • heLP4me$ – help for me (money)

    And here is a bad one:

  • T0gether – to get her

    Some examples of using a phrase

    Here are three good examples of using phrases:

  • rsKf0myH – Raindrops keep falling on my head.
  • wru2rxy? – Who are you to ask why.
  • bWiIso3! – Beware the ides of March!

    And here is a bad one:

  • Aaaaaaaa – Always assert an ambiguous axiom and argue aggressively.

    Passwords to never, EVER use

    There is a very handy list of the worst 500 passwords over at What’s My Pass? In addition to that, all the sample passwords listed in this article are now known, and should not be used by anyone.


    KLEIN 1990

    Klein, D.V.; “Foiling the Cracker”: A Survey of, and Improvements to, Password Security, (revised paper with new data) Proceedings of the 14th DoE Computer Security Group, May 1991.

    What’s My Pass?

    The Top 500 Worst Passwords of All Time, November 2008

Article Source –

Passwordstate Now Fully Integrated with AuthAnvil Multi Factor Authentication

We have some great news for customers who already use, or would like to use, Scorpion Software’s AuthAnvil Multi Factor Authentication solution – Passwordstate is now fully integrated, providing a fourth two-factor authentication option.

As per the other authentication options in Passwordstate, AuthAnvil two-factor authentication can be used in the following ways:

  • Initially authenticating to Passwordstate – using just your AuthAnvil Username and Passcode, or Active Directory account details and AuthAnvil Username and Passcode
  • As an authentication option for the Passwordstate mobile client
  • As an authentication option if Passwordstate is accessed from an IP Address which is not specified in the ‘Allowed IP Ranges’
  • As an additional authentication step prior to accessing passwords in a Password List

In order to use this authentication option, there are a couple of settings/steps which needs to be looked at first:

  1. On the screen Administration -> System Settings -> Authentication Options tab, you need to specify your AuthAnvil URL and various other settings
  2. The user must specify their AuthAnvil Username on the Preferences screen – by default it is populated with the same Username as used in Passwordstate, but can be changed if require

Once these settings are configure, then you’re ready to start using this new authentication option. As always, audit records are added for authentication attempts, which can be reported against on the screen Administration -> Auditing.

A couple of screenshots of AuthAnvil’s software token, and an authentication screen in Passwordstate, plus for the mobile client:

We’d like to personally thank the Scorpion Software team, as they were a pleasure to work with, and provided us with great support while we were integrating the two products.

Click Studios