Emergency Access Password – What is it and how do I find it?

Click Studios designed a secure Emergency Access login to Passwordstate back in the early days of Passwordstate 5. The Emergency Access account is a separate built-in account with ‘Security Administrator’ rights that allows login to Passwordstate when other accounts are locked out, or inaccessible for any reason. This account doesn’t allocate a license from your available license pool and is not intended for use in day to day operations. It should be regarded as an account of last resort.

An organization would typically only use their Emergency Access account under select scenarios such as;

  • You have issues authenticating to Passwordstate due to the Authentication Option you have selected no longer working.
  • All Security Administrator accounts have been accidentally disabled or deleted, with no other accounts being able to administer all settings for Passwordstate.

To login via the Emergency Access account you must browse to the URL HTTPS://<Your Passwordstate URL>/Emergency. You are then presented with the following login screen,

As stated in the image above, there is increased auditing associated with the Emergency Access account. In browsing to the login screen you will trigger an audit event. The following applies to attempted and successful logins using the Emergency Access account;

  • Browsing to the Emergency Access URL will generate an audit record. The details for the event, including the IP Address the access was initiated from, is subsequently emailed to all Security Administrators.
  • On successful and unsuccessful login, details for the event including the IP Address the login attempt was initiated from is emailed to all Security Administrators.
  • On successful login you must specify a reason why you need access and these details are added to the auditing data.

Once you’ve logged in with this account, you will have access to the Administration area of Passwordstate.

Auditing of Emergency Access

The auditing details below relate to Click Studios internal Passwordstate Instance and show an attempted access to the Emergency Access Login Screen (for the purpose of creating the blog entry). As this is our Production Instance please understand that I’ve redacted the account details, names of the Security Administrators and their email accounts from the screenshot below,

Setting the Emergency Access Password and Permitted IP Ranges

If you need to change the Emergency Access password navigate to Administration->Emergency Access->emergency access details.
Here you can set the Password and print it out for safe storage if required,

Whilst you can always RDP directly to your Passwordstate Server, you can further lock down the ability to login over the network, via the Emergency Access login screen, by specifying Allowed IP Ranges. Using this feature, you can specify individual IP addresses as well as allowed IP address ranges. To set Allowed IP Ranges navigate to Administration->System Settings->allowed ip ranges and add the relevant entries under Emergency Access Allowed IP Ranges. Remember to add only one specific address or IP ranger per line,

Recover the Emergency Access Password

If you ever lose the printed copy of the Emergency Access Password, or if it’s been reset by someone and not recorded anywhere, you can contact Click Studios and ask us to recover it for you.

In these instances we’ll need email approval from line management before proceeding. Once we have approval, we’ll require;

  • The most recent version of your Web.config file. This should be located in the root directory of your Passwordstate installation or C:\inetpub\passwordstate.
  • The values for EA_Password, Secret3 and Secret4 from your Passwordstate Database, located in the Passwordstate table. To extract these, you’ll need to use Microsoft’s SQL Management Studio tools to connect to your database server and execute the following query;

    USE Passwordstate

    SELECT EA_Password, Secret3, Secret4 FROM SystemSettings

We’ll then recover the Emergency Access Password for you using our in-house support tools;

We’ll then email the password details back to you. Once you receive the email we suggest the first thing you do is change the Emergency Access Password, record it, print it out and store it somewhere safe! We also encourage you to rotate your encryption keys, refer to Section 2.12 Encryption Keys here.

That’s it for this week. Any suggestions or feedback are welcome and you can send these through to support@clickstudios.com.au.

Creating New Private Password Lists for New Users

Passwordstate allows teams of people to access and share sensitive password credentials through the concept of Shared Password Lists. This enables your organization to implement granular control over who has access to your privileged account credentials through Role Based Access Control. This in turn enables built-in auditing and compliance capabilities to track who has accessed credentials and when.

Equally important is the concept of Private Password Lists, where individuals can securely record and manage credentials that are used for private use. The ability to create and use Private Password Lists is free and provided as part of the named User Licensing Model that Passwordstate uses. But what does this mean? It means that if a user has access to login to Passwordstate, they are enabled and have a Named User License automatically applied to their account, license count permitting.

Organizations that don’t allow the use of Private Password Lists for their users typically struggle with enforcing the use of Shared Password Lists. This is understandable as you are in effect stating that credential management is only important for business use and not personal use. On the other hand, organizations that adopt and promote the use of Private Password Lists typically build a healthy cybersecurity awareness in their workforce with employees embracing credential management for both personal and organizational use.

So how do you minimize the impact on Security Administrators having to setup Private Password Lists for all your employees.

Automatically create Private Password Lists for New Users

To reduce the workload on your Passwordstate Security Administrators, and make life easier for your users, you can automatically create Private Password Lists for all new user accounts as they are added to Passwordstate. This is done by enabling the option to automatically create a Private Password List for new users. To do this navigate to Administration->System Settings->password list options and click the Yes radio button underneath When a new User Account is added to Passwordstate, automatically create a Private Password List for the user option. You can also specify the name of the Private Password List using the variables FirstName and Surname shown below,

In doing this all new users that are added will have a Private Password List created in the root of the Passwords Tab. If you decide to not use the variables in the name then all Private Password Lists will look to have the same name, however they will all have a unique PasswordListID that is used to identify them at a system level. And of course, each Private Password List will only have Administrator permissions assigned to the appropriate user.

Customize Private Password List Fields with User Account Policies

It is possible to create all Private Password Lists with additional fields that the user may want to use. For example, these could be fields for a support email, PIN for 2FA, a phone number, or an address. By default, automatically created Private Password Lists include the URL field, however they aren’t based on any of the templates located under Administration->Password List Templates.

In order to add specific additional fields, you’ll need to create a User Account Policy for all users, that references a custom Password List Template. First, you’ll need to create a template that contains the fields that you want to provision for new users. To do this navigate to Administration->Password List Templates and click on Add New Template,

Give the template a Name, Description, choose an image and define the required Password Strength Policy, Password Generator Policy and any Additional Authentication you require. Then select the customize fields tab and specify the additional fields you want to provision. In the example below I’ve created the following text fields email, PIN, Phone Number and Address,

Now create a User Account Policy that will use the new Password List Template. In my example I’ve named it “Private Password Lists”. Navigate to Administration->User Account Policies and click on Add to create a new User Account Policy,

Supply a Policy Name, Description and on the password list options tab, for Setting ID E4, select the name of the Password Lists Template you wish to reference,

Then click Save. Now click on the Actions icon and select Apply Policy to Users, selecting All Users and Security Groups,

Now every time a New User is added to Passwordstate they will have an automatically created Private Password List with all the Fields that you’ve selected. Each individual user will be the Administrator of their Private Password List and will be able to edit it as desired.

Don’t forget, we welcome your feedback via support@clickstudios.com.au.

How to use your Phone for Google Authenticator and Passwordstate

We often receive support requests asking how to enable Two-Factor Authentication (2FA) in addition to AD Authentication. This is a straight forward process and the 2FA options can be used with Single-Sign-On (SSO), Manual AD Authentication and even with Local Passwordstate Accounts.


There are a couple of approaches that can be used to set this up. For the examples in this week’s blog I’m going to be using the Google Authenticator App from an iPhone and a Local Passwordstate Account. These examples will work equally well with AD Accounts, the only difference being the required Authentication Options under Administration->System Settings->authentication options->Choose Authentication Option.

I normally choose SSO (Passthrough AD Authentication) for the System Wide Authentication setting, as I quickly jump in and out of my Passwordstate Sandpit environment. For the purpose of doing this blog I’ve dropped back to Manual AD Authentication as I’m logging into Passwordstate with 2 accounts from the same computer.

Create a User Account Policy for 2FA with Google Authentication

Using a User Account Policy is a great way to both test the 2FA configuration as well as making it easier to rollout across your intended users.

Navigate to Administration->User Account Policies and click Add to create a new Policy. Give the policy a name and description and select the Authentication method you want to assign at A6. In the example blow I’ve used Manual AD and Google Authenticator, then click Save at the bottom of the page,

Apply the User Account Policy to Users

Next, you’ll need to apply the newly created User Account Policy to Users. Select the Action button next to the Policy Name, click and select Apply Policy to Users,

Now select the users you want to apply this User Account Policy to. In the below example I’m using a single account for testing purposes. Once you happy it’s working you can go back in and apply it to Security Groups as required

Now when I log into Passwordstate for the first time after the policy has been applied, I’ll be presented with a normal login screen,

And on clicking on logon will be presented with,

I now need to use the Google Authenticator App and select the + symbol to add an Authenticator, pick Scan barcode and place the QR code that is presented above within the onscreen frame. This will then setup the Authenticator and present back the PIN code that needs to be entered.

Simply enter this in the Google Verification Code and click Login.

Once you’re happy you can Apply the User Account Policy to the required Security Groups to rollout the policy.

Using SSO with 2FA & Google Authentication

As stated at the beginning you can use 2FA with both SSO (Passthrough AD Authentication) and Manual AD Authentication. The only differences being that with SSO you only need to ensure your System Wide Settings under Administration->System Settings->authentication options->Choose Authentication Option is set to Passthrough AD Authentication, and the Authentication Option you specify at Setting A6 in your User Account Policy is set to just Google Authenticator as per the below image;

This will in effect Prompt for your Google Authenticator credentials during the Passthrough Process. It is highly recommended that you don’t roll this configuration out to all users as it defeats the purpose of having SSO. Rather you should reserve it for those users that have access to highly privileged password credentials or those accounts associated with considerable impact if the credentials were stolen or misused.

As always, we welcome your feedback via support@clickstudios.com.au.

How to Change your Passwordstate URL

At installation time some customers elect to customize aspects of their Passwordstate installation. By default, Passwordstate will use the Host Name of the Webserver that it is being installed on. Alternatively, you can specify a custom URL (Uniform Resource Locator) to make it easier for users to remember the system (in case they haven’t book marked it in their favourites) or simply if you want to brand your installation.

Creating an appropriate DNS Record

In order to be able to use a custom URL you will need to create a CNAME DNS entry. You should never try to use host files for name resolution as they do not work with Windows Authentication in Microsoft IIS (Internet Information Services).

In the following example I will be creating a custom URL for my “Sandpit” Passwordstate Instance. This instance is used for testing out new releases, producing the blog entries and basically familiarising myself with the functionality, new and existing, in Passwordstate. First, connect to your Windows Server hosting your DNS settings and start DNS Manager;

under Forward Lookup Zones select your Domain and create a CNAME (Canonical Name Record or Alias) as per the image below. Note your Alias name and Fully Qualified domain name (FQDN) will be different to prbpasswordstate, and the taget host is your Passwordstate web server;

Modify your IIS Bindings

Next, you’ll need to modify the bindings in IIS to match the URL that was set in DNS Manager. To do this login to the Webserver that your Passwordstate instance is hosted on and start Internet Information Services (IIS) Manager;

Under your Webserver, navigate to Sites and select Passwordstate from the Left-Hand pane. In the Right-Hand pane click on Bindings… as per the image below;

When you click on edit to supply the details it’s worthwhile ensuring you use port 443 as you’ll no longer need to append the port number to the end of your URL (your Web Browser automatically adds 443 silently to your URL making it easier to remember).

Generate a new Certificate

Next, you’ll need to create a new Certificate and there are a number of options for this;

  • The Self-Signed Certificate that Passwordstate installs 
  • An internal Certificate Authority
  • A purchased Wildcard Certificate from a Certificate Authority (best option)

If you elect not to use a purchased SSL Certificate from a Certificate Authority you can still generate a more secure certificate to use on your Passwordstate website. This will be generated by using an Internal Certificate Authority. Please see this forum post on how to first setup an Internal Certificate Authority.  Once done you can then follow these instructions on how to generate a new Certificate from your Internal Certificate Authority.

Creating a new Self-Signed Certificate is straight forward. On your Webserver, Run PowerShell ISE as an Administrator and ensure your PowerShell version is at least V 4.0. To confirm what version you are running type $host into the console and you should see a response similar to below;

Next copy the following code into your Powershell ISE console, changing the URL in the second line to be your new URL (in my example it’s prbpasswordstate.halox.net) and run the script. it will create a new Self-Signed certificate for you;

# Begin script
$URL = “prbpasswordstate.halox.net”

$PowershellVersion = $host.version.Major
 # Create the SSL Certificate, using different commands depending on which version of Powershell is installed.  Preferably Powershell 5, as this allows us to set a longer expiry date on the certificate
    if ($PowershellVersion -eq ‘4’)
        $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My    
    if ($PowershellVersion -eq ‘5’)
        $StartDate = ’01/01/’ + (Get-Date).Year
        $EndDate = ’01/01/’ + (Get-Date).AddYears(5).Year
        $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My -FriendlyName $URL -NotBefore $StartDate -NotAfter $EndDate
    $rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList Root, LocalMachine


Now navigate back to IIS, go to the bindings… for the site, double-click on the https binding, and select the new SSL certificate you’ve just created from the drop-down list and click OK;


Modify Passwordstate Base URL

Lastly, you’ll need to specify the new base URL to reflect the new custom URL that you’ve set. To do this open your Passwordstate instance and navigate to Administration->System Settings->Miscellaneous Tab and update your Base URL as per the image below;

Note that this URL is used for
links in the emails, permalinks etc.

That’s it for this week and as always, your feedback is welcome via

Passwordstate One-Time Password Authenticator

A One-Time Password (OTP) is a password that is valid for only one login session or access transaction. OTPs, used as part of 2FA (Two-Factor Authentication), offer an advantage in that they’re not vulnerable to replay attacks. This means a potential intruder, who manages to record an OTP already used, will not be able to abuse it as it’s no longer valid.

Passwordstate utilizes the TOTP standard, where time is an important part of the password algorithm in addition to the Issuer and Secret keys.

Setup One-Time Password Authenticator

First, I’ve created a Shared Password List based on the One-Time Password Authenticator template by right clicking on a folder, in this case our Windows Team, and progressing through the Add Shared Password List Wizard

Next, I’ve created a Password Record for logging into Gmail for one of our staff members,

You’ll note, that by using the One-Time Password Authenticator template, the highlighted section above is automatically added to the Password Record. In the event that you want to add the One-Time Password Authenticator to an existing record, in an existing Password List, simply go to that Password List, click on List Administrator Actions… and select Edit Password List Properties,

Then under Password List Settings, click on Enable One-Time Password Generation, and click Save & Close

Now you can configure the One-Time Password Authenticator. You can do this via either a QR code provided by your Issuer, or by entering the Issuer details manually. To enter a QR Code simply click on the icon of a QR code and either browse to the location of your QR Code by clicking on the select button, or, drag the QR Code over the Drop Image Here

Alternatively, you can add the details manually. To do this you must provide both the Issuer and Secret as provided by your Issuer. Make sure to cut and paste the Issuer and Secret into the correct fields;

You’ll notice that every time you now access that Password Record a new One-Time Password is generated for you, and refreshed based on your Valid Period (specified in seconds).

That’s all there is to it! As always, your feedback is welcome via

Update to Remote Session Launchers

Passwordstate has two first-in-class Remote Access Solutions, typically referred to as Remote Session Launchers, a Browser Based Launcher and a Client Based Launcher. The Remote Session Launchers are provided as part of the core Passwordstate product, with source files located in your Passwordstate install directory. Details on the differences between the two launchers can be found here.

As of Passwordstate build 8844 we’ve introduced an Automated installation for the Remote Session Launcher Gateway. For detailed instructions please refer to the Remote Session Launcher Install Guide.

Overview and Automated Installation Changes

Let’s talk about whether this is an automated or semi-automated installer first. As long as you’re performing the installation on your Passwordstate Server, and are using the default installation directory, then it’s fully automated. In the event you wish to install the Gateway on another server, or wish to change default settings, then you’ll need to perform some steps outside of this process (it then becomes a semi-automated installation). For the steps associated with a semi-automated install please refer to the Remote Session Launcher Install Guide above.

Source files for the “Browser Based Gateway” are included with your Passwordstate installation. They are downloaded by default and are typically located in c:\inetpub\passwordstate\hosts\gateway.

Once the installation is completed all SSH and RDP sessions will be tunnelled through the Gateway, and you won’t be required to perform any client installs. All future RDP and SSH sessions will be initiated through your HTML5 browser, from any device that can access your Passwordstate Website.

During the Installation the following changes will be performed (based on a default install on your Passwordstate Server);

  • Creates a logfile in the same directory where you execute the PowerShell script
  • Downloads OpenJDK 13 (approximately 200 MB) from Azul Systems and extracts this to C:\Program Files (x86)
  • Appends the file path C:\Program Files (x86)\OpenJDK\bin to the PATH Environment Variable
  • Adds a new Environment Variable called JAVA_HOME set to C:\Program Files (x86)\OpenJDK
  • Automatically exports your certificate from your https binding in IIS
  • Installs a Windows Service called Passwordstate-Gateway
  • Removes all temporary source files that were created during the installation

Download and Extract Files

As a general rule we’d recommend that you always grab the latest version of the source files. These can be obtained in a ZIP file here and should be saved to a temporary folder on your Passwordstate server. Once you’ve saved the file, you’ll need to extract the two files 7za.exe and Install-Gateway-Internal.ps1 as per the image below;

Running the PowerShell Script

Once this has been done, you’ll need to open a GUI that can run PowerShell scripts (files ending with an extension of .ps1). For the purpose of this blog I’m using Microsoft’s ISE (Integrated Scripting Environment). It’s important to start ISE with Run as administrator to ensure adequate privileges as per the image below;

Once ISE has loaded, you’ll need to open the extracted PowerShell script Install-Gateway-Internal.ps1 and then either press F5 or click the Run button shown;

This will install the Remote Session Launcher Gateway and you should see the successful completion messages as per the image below;

It’s as simple as that! All RDP and SSH sessions will now be initiated through your HTML5 browser!

As always, your feedback is welcome via

Reporting When a Sensitive Password has been Viewed

As discussed in last week’s blog https://www.clickstudios.com.au/blog/passwordstate-email-notifications-explained/, Passwordstate is designed to keep Security Administrators and users informed when different events take place. Building on from that, we’ll now setup a Scheduled Report that alerts an intended audience of a Password record being viewed within a preset timeframe.

You could look at using this approach for very sensitive password credentials where you want to closely monitor when they are being used and by whom.

Password Record being Reported:

We’re going to use the following account for this blog (don’t worry it’s a fake account). It does however provide an account to report against. We’ve specifically set up a description field that’s meaningful as per the screenshot below;

Setting up the Report:

Next, we’ll setup a Scheduled Report which runs once every 5 minutes.  This report will only generate and send an email if the password for ClickStudiosAccount has been viewed. If no one has viewed the password record then you won’t get an email – so no false positive emails. Note you can schedule the duration for any period of time you like.

First you’ll need to navigate to Reports->Scheduled Reports and click on Add Report as show below;

When creating the report, on the report settings tab give it a Report Name and a Report Description (if you wish), but importantly make sure you CC in a user or a mailbox of your choice in the CC Report To field.  The report will be sent to the person creating the Scheduled Report by default but it will also CC in the mailbox specified.  Ensure you tick the option to not send the report if no results are produced, and choose the report type as Custom Auditing Report:

Next, on the schedule tab, select the frequency of One Time, click on the Generate report and specify a frequency of 5 Minutes as per the screen shot below;

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

This report will now run every 5 minutes, and on finding any activities matching the type of Password Viewed will email the person that setup the Scheduled Report as well as the email addresses specified on the CC line.

As always, we welcome your feedback via support@clickstudios.com.au.

Passwordstate Email Notifications Explained

Passwordstate is designed to keep Security Administrators and users informed when different events take place. This is achieved through a combination of audit records, real-time monitoring and email notifications.

With over 50 different types of email notifications, Administrators and employees can be alerted to specific events happening within Passwordstate.  This can range from a simple event, such as a user copying a password to their clipboard, to License warnings being sent to all Security Administrators.  In order to use the Email Notifications, you’ll need to configure your email server settings under Administration->System Settings->Email Alerts and Options.

By default, all Email Notifications are enabled. If you’re not careful this can result in Passwordstate “Spamming” your users.  At Click Studios we understand how frustrating this can be and have provided the ability for you to control which emails your employees receive. This can be configured at the Security Administrator level, allowing control over which emails other users in the system receive.  It can also be controlled by users within their own preferences.

Controlling your own Emails:

To control your own individual Email Notifications, navigate to Preferences->Email Notifications as per the screen shot below:

Now select the Actions Menu for the notification you don’t want to receive, click it and select Toggle status – Enabled or Disabled. You’ll see the Enabled icon change from a green tick to a red cross. To change it back simply repeat the process again and you’ll see it change back to a green tick in the Enabled column.

Once disabled you’ll no longer receive these notifications. Note that if you can’t toggle the Enabled or Disabled status then your Security Administrator has put in place settings that override your preferences.

Control which Emails are sent to specific users in the system:

As a Security Administrator you can use Email Notification Groups to specify which email notifications certain users receive, or don’t receive. This allows you to have certain notifications enabled for Security Administrators but disabled for standard user accounts in Passwordstate.

It is important to note that any Email Notification permissions you apply here for users will override their personal settings as set under their Preferences. It is also important to note that If you have more than one Notification Group created for a user, any disabled Email Notification will over-ride its enabled counterpart in the other Notification Groups.

To create an Email Notification Group, navigate to Administration->Email Notification Groups and click Add:

Give your Notification Group a meaningful name and description (as per the example below) and click Save:

Now from the Actions Menu, select View Notifications and disable the templates of your choice.  In this example, I’ll be disabling the Copy to Clipboard Notification only:

Navigate to the Password
Copied To Clipboard Notification Group, click on the Actions Menu and select Toggle status – Enabled or Disabled. You will see the Enabled icon change from a green tick to a red cross.

Then click on Return to Notification Groups. Next, we need to apply this to some users. In our example we’re applying it to a Security Group called IT Staff, and all the members in this group will be assigned to this Notification Group. Select the Actions Menu and click on View Permissions:

Then we assign the permission to the IT Staff Security Group by clicking on Security Group, searching for IT, selecting the Group from the Left Hand pane and clicking on >> then clicking Save.

With this Notification Group now active, all users contained in the IT Staff Security Group will no longer receive the Copy to Clipboard emails.

Disabling Emails globally:

Security Administrators can disable Email Templates at a global level preventing them from being used in Passwordstate.  This will disable Email Notifications even if users have them enabled under their own Preferences. It will also override any inclusions specified as part of an Email Notification Group.

To globally disable an Email Template navigate to Administration->Email Templates, choose the Email Template you wish to disable, click on the Actions Menu and select Toggle status – Enabled or Disabled.

Once you disable the email from here it cannot be sent to any user.

As always, we welcome your feedback via support@clickstudios.com.au.

Personal Password Management Best Practices

We’re often asked what are the recommended ‘Best Practices’ for personal password management, so we’ve put together a little guide which we hope you will find useful.

The following suggestions are also applicable to passwords which are shared amongst team members, and while there is reference to features specific to Passwordstate, they are also useful tips for any other password management system.

Create a Private Password List

First thing you will want to do in Passwordstate is create your own Private Password List. By creating a Personal Password List, it is hidden from all other users of Passwordstate (including Security Administrators), and permissions cannot accidently be granted to other users – the option to apply permissions to the Password List is disabled. It’s possible your Security Administrators of Passwordstate have disabled the ability to create Private Password Lists, so if the option is greyed out under the ‘Passwords’ menu at the bottom of your screen, please speak to one of your Security Administrators of Passwordstate. Below is a screenshot for adding a new Private Password List, and we’ve highlighted a few options which we recommend. Some of these options are covered further down in the blog post.

Caution – As you can see in the screenshot below, you have the option of specifying an ‘Additional Authentication’ step which is required before you can access the Password List. If you choose ‘Use Separate Password’, and forget this password, then the only way to restore access to the Password List is to have one of your Database Administrators restore a copy of the database prior to making the change. Security Administrators are able to reset your ScramblePad Pin Code, your Google Authenticator Secret Key, or your SecurID pin, but they cannot reset a personal password you apply to this list.

Encrypt Your Passwords
It goes without saying, but if your passwords aren’t encrypted in some way, then anyone can potentially gain access to your valuable resources. Passwordstate uses industry standard 256-bit AES Encryption (Advanced Encryption Standard), and this should be a minimum encryption standard to use. AES has been adopted by the US government, and is now used worldwide. In addition to encrypting your passwords, their values should be also ‘salted’ in the database. Salted means an additional input is used as a one-way function that hashes a password or passphrase. The primary purpose of salts is to defend against dictionary attacks and pre-computed rainbow table attacks. In addition, even if your database administrator is snooping around the raw data, no two encrypted values appear to be the same. There are other features in Passwordstate which further protect against theft of the database and decryption attempts, like the ‘Authorized Web Servers’ feature.


Backup Your Passwords
We have witnessed quite a few customers over the years who do not backup their Passwordstate database. Best practice recommends you backup all IT systems, regardless of their importance or sensitivity of the data. When we’ve queried these customers as to why they haven’t got a backup of the database, we generally receive one of two responses – 1. I’m not a DBA and don’t know how to, or 2. I didn’t know we needed to do that. As of version 6 of Passwordstate, you can now take advantage of the Automatic Backup feature. With this feature, you can set a regular schedule, and Passwordstate will perform the backups for you. It will back up all of the Passwordstate web files, and also a full copy of your database. There are a few steps required to configure Automatic Backups, and the following blog post will provide further detail – http://www.clickstudios.com.au/blog/backups-and-in-place-upgrades/.


Create Strong Passwords
The stronger the password, the harder it is to guess or crack. The issue with complex passwords is they’re difficult to remember, and often a pain to create. In Passwordstate we’ve provided a Password Generator, and this tool allows you to easily create complex passwords. There are numerous Alphanumeric and Special character options, as well as the use of a Word Dictionary which contains 10,000 words which can be inserted into your password phrase. The following article on our site also goes into some detail about choosing good passwords – http://www.clickstudios.com.au/articles/choosing-good-passwords.html

Once you’ve set the options for your Password Generator, any time you need to create a new complex password, you simply click on the following icon . And there really is no need to try and memorize these passwords when using Passwordstate – you can unmask the password at any time by clicking on the ****** value you see in the grids, or you can copy the password to the clipboard by clicking on the icon .

Reset Passwords on a Regular Basis
How often do you read on the Internet of some site’s user database being compromised, and all the user’s passwords being leaked – unfortunately it’s all too often? If you reset your password on a regular basis, then this becomes less of an issue. We have a couple of features in Passwordstate which will help with the reset task, and they all relate around the use of the ‘Expiry Date’ field. When you populate the Expiry Date field, you can see visually on the screen when a Password should be reset – if the Password has already ‘expired’, or will expire in the next 30 days, then the Expiry Date field will be highlighted in a Red color. In addition to this, we have the ‘Expiring Passwords’ report which you can choose to receive via email either daily, weekly or monthly. This email report provides you a list of all your Passwords which have already expired, or are about to expire in the next 30 days.


Avoid Password Reuse
And finally, one of the worst things you can do is reuse Passwords across different systems and web sites. We all do it, but it is probably one of the worst password management practices you can adopt. Any time one Password on a web site/system is compromised, then the hacker could potentially gain access to all your other systems – assuming they know your login ID. In the screenshot above for the Private Password List’s settings, you will notice we’ve highlighted the feature ‘Prevent Password Reuse’. By using this feature, Passwordstate will query the history of changes for the Password record, and prevent you from ‘reusing’ passwords based on the number you set.

We hope you find this a useful guide for Personal Password Management Best Practices.

Click Studios

How To Clone a Folder

Hi Everyone,

Today we released Build 5638 of Passwordstate, which includes a new feature where you can clone a Password Folder, and any Folders or Password Lists nested beneath it. This feature is very handy for keeping a consistent structure for storing all your passwords.

To clone a folder, you first need to click on it in the Navigation Tree, then click on the ‘Folder Options’ button at the top of the screen, and then you will see the ‘Clone Folder’ link. From here you have the following options available to you:

  • Specify the new name of the folder to be cloned
  • Choose whether you want to clone all Folders and Password Lists nested below the chosen folder, or just clone Folders only
  • Choose what permissions you would like to apply to the new Folders and Password Lists – either clone the current permissions, apply permissions just for yourself, or don’t apply any permissions at all

When you have finished cloning the folder, it will place the structure in the root of the Navigation Tree. Standard processing occurs when cloning folders i.e. appropriate audit events are logged, and email notifications are sent informing users they have access to one or more new Password Lists. We’ve also provided a ‘Save & Clone Again’ button, so you can quickly repeat the process. Below is a screenshot from version 6 of Passwordstate, showing the options available to you.

Note: Cloning Password Lists will not clone any of the passwords contained within them – only settings, customisations and permissions will be cloned.

Cloning Folders in Passwordstate

We hope you like this new feature, and please leave us some comments if you like.

Click Studios