passwordstate Archives

Passwordstate Build 7721 New Features

August 2, 2016 by support Leave a Comment

In Build 7721, we’ve placed a large focus on simplifying the process of configure password records to perform resets on remote systems. In additional to this, it’s now a lot easier to search for accounts which belong to specific hosts, and we’ve also simplified the UI (User Interface) so it’s easy to see at a glance what the status is of the most recent password reset, and account heartbeat attempts. This post will also mention other notable changes as well.

Password Reset Changes

In this build, we have significantly simplified the process of configuring password records to perform resets on remote systems – either Active Directory, or accounts on any of the other 19 systems we currently provide scripts for.

This first screen shows how to configure Active Directory accounts – the main difference now is the ‘Domain’ has its own field, which is searchable in case you have more than one domain.

The next screen shows a Local Administrator’s account on a Windows 10 desktop. The main difference here is the Host Name field, where previously you had to link the password record to the host record on a separate screen – it can now all be done on the same screen.

On the Reset Options tab, you can also select the Password Reset Script from here as well – previously, this had to be done on a different screen as well.

You will notice that the ‘Failed Reset Options’ settings are gone as well. This is because of the new queuing system we’ve built (more information below), and now the Expiry Date field is not updated unless there is a successful reset.

We’ve also redesigned the Password List screen as well, to provide better visibility into the status of Resets and Heartbeats. As you can see from the screenshot below, you have the traffic like signals for the status, and clicking on the icon will filter all auditing data on that record. There is also a Dependencies column now as well, so if there are any related ‘dependant’ reset tasks as well, you can click on the hyperlink for the count, and it will take you to those dependencies. Dependencies are generally things like Windows Services, Scheduled Tasks, IIS Application Pools, etc. You can also have your own custom reset script as a dependency as well – it can perform any action you want, and doesn’t necessarily need to be associated with a Host record.

We’ve also built a new queuing system for the Password Resets. Whenever a password is updated for an account now, and password reset tasks are added to a queue. Only when the reset is successfully, will it update any data in Passwordstate – previously it use to update the password first in Passwordstate, and then try and perform the reset on the remote system. If there was an issue performing the remote reset, the changes where rolled back in Passwordstate.

From the screen Resets – Queued Password Resets, you can see at a glance all resets sitting in the queue – this will only show records your account has access to. It will also show a filtered view of auditing data for records sitting the in the queue as well – so you have a “time-lined” view of the reset process.

A large architectural change in Build 7721, is the previous one-to-many relationship between Password and Host records. Previously you use to be able to have the same password, linked to many hosts. This has now changed to a one-to-one relationship, primarily for the reasons of:

Best practice dictates you do not use the same password across multiple systems
The simplified design approach makes it a lot easier to search for accounts which below to specific hosts – you can now search for the Host’s name on any of the relevant password screens

Changes to Host Records

In previous builds of Passwordstate, you need to grant users permissions to Host records, so that they could configure password resets for accounts which belonged to Hosts, and also to use with the Remote Session Launcher feature. Permissions on Hosts have now been deprecated, greatly simplifying these two processes.

With the removal of permissions, this does mean any user has full access to the screen Resets -> Hosts – so they can add/edit/delete records. If you wish to restrict who is allowed to do this, it can be done in one of two ways.

On the screen Administration -> Menu Access. You can remove user’s permissions from the main Resets, or Hosts navigation menu items
If you still want you users to have access to the Resets -> Hosts menu, you can restrict who is allowed to make changes on this screen. This is done on the screen Administration -> System Settings -> Hosts tab, then click on the ‘Host Permissions’ button

Password Reset Support for HP and Juniper Devices

In this build, we’ve also added support for performing password resets, and account Heartbeat validation on the following platforms:

HP H3C routers and switches
HP Procurve routers and switches
Juniper Junos routers and switches
And Juniper ScreenOS firewalls

Changes to API Methods

With the changes to the Password Reset processes in this build, we’ve also updated our API so you can configure records for password resets as well. Specific changes to the API are:

When you Add/Edit password records, you can enable the options for password resets and heartbeat validation. Along with this, you can select appropriate scripts, privileged account credentials, and schedules
You can also add password reset ‘dependencies’ processes to existing accounts as well i.e. associate credentials with a Windows Service, or Scheduled Tasks, or IIS Application pool, etc
And now that Host records no longer require permissions to be associated with them, the ‘Add Host’ method has removed this requirement also

Performance Improvements

In this build, we made some performance improvements for customers who have hundreds of Folders and Password Lists visible in the Navigation tree – typically, it was our MSP customers who were experiencing this. Below are some before and after timings of these changes:

Testing Scenario

Create 350 Folders, with 5 Password Lists per folder, and 10 Passwords in each of the Password Lists – a total of 17,500 passwords
Applied permissions via a User’s account, and also 5 Security Groups the account was a member of. When there are ‘duplicate’ permissions like this because of Security Groups, we need to iterate through all those records and determine which Security Groups has the highest permission – so this has a performance impact as well for this many Password Lists

Performance Prior to any Code Changes

14 to 15 Seconds to Load the site
9 to 12 seconds to change Password Lists

Performance After Code Changes

6.7 seconds to Load the site
Almost instance to change Password Lists now

Miscellaneous

There are also various other features and improvements in this build. In particular, they are:

SQL Server 2016 Support
Perform reset on Local Admin Account Discovery
Scheduled Reports can now be run on a more frequent basis – multiple times per day if required
Internet Explorer Browser Extension is now out of beta
Remote Session Launcher Utility now supports the use of local Windows Accounts for RDP sessions

We hope you like this changes in this build. The password reset updates, and new queuing system, form the basis of some more exciting Enterprise Password Management features planned for version 8.

Filed Under: General Post Tagged With: Password Reset, passwordstate, Privileged Account Management

Passwordstate Build 7580 New Features

May 6, 2016 by support 4 Comments

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

Regards
Click Studios

Filed Under: General Post Tagged With: AES 256bit, encryption, passwordstate

Passwordstate Permission Model Changes

November 19, 2015 by support Leave a Comment

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:

You can only apply permissions to a top level Folder in the Root of ‘Passwords Home’
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
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
Private Password Lists cannot be nested beneath a Folder which is propagating permissions down
The ‘Bulk Permissions’ feature cannot be used for any Password Lists which are inheriting permissions from a top level Folder
A couple of System Settings options for applying permissions to newly created Password Lists will be ignored
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:

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

Create a Folder under Passwords Home. In this example we’ve called it “Windows Desktop Machines”
When creating the Folder, ensure you tick ‘Manage permissions manually for this folder’ and ‘Enable the Propagate Permissions Downwards‘
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:

Select your top level Folder and select ‘Folder Properties’
Ensure you have ‘Manage permissions manually for this folder‘ selected
Click the ‘Convert Permission Model‘ button
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.

Filed Under: General Post Tagged With: passwords, passwordstate, Permissions, Role Based Access

Passwordstate Build 7393 New Features

September 5, 2015 by support Leave a Comment

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	Notes
Reset Cisco Enable Secret	Yes
Reset Cisco Host Password Priv 1	Yes	For Privilege Level 1 type accounts
Reset Cisco Host Password Priv 15	Yes	For Privilege Level 15 type accounts
Reset COM+ Component Password	Yes
Reset Dell iDRAC Account Password	No
Reset F5 BIG-IP Account Password – AS	Yes	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	Yes	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	No
Reset IBM IMM Account Password	No	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	Yes
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	Yes
Reset Oracle Password	Yes
Reset Scheduled Task Password	Yes
Reset SQL Password	Yes
Reset VMware ESX Password	No
Reset Windows Password	Yes
Reset Windows Service Password	Yes

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

Filed Under: General Post Tagged With: Build 7393, Password Resets, passwordstate

Configure Passwordstate to use a Managed Service Account (MSA) to connect to the database

July 12, 2015 by support 2 Comments

As of Build 7301, it is possible to configure Passwordstate to use a Managed Service Account to communicate with the database server, instead of a SQL Login Account.

A Managed Service Account in Active Directory is a special type of account which self manages the automatic rotation of its own password every 30 days. Configuring Passwordstate to use an MSA account can be more secure, as you don’t need to specify the password for this account in the database connections string in the web.config file.

To create an MSA account, and configure Passwordstate to use it, please follow these instructions:

Create a Managed Service Account (MSA)

On your domain controller, open PowerShell console as an Admin, and execute the following commands
- New-ADServiceAccount -Name <MSAAccountName> -RestrictToSingleComputer -AccountPassword (ConvertTo-SecureString -AsPlainText “<password>” -Force) -Path “cn=<MyCN>,dc=<MyDC>,dc=<MyDC>” (replace the variables in <> as appropriate)
- Add-ADComputerServiceAccount -Identity “<MyWebServerName>” -ServiceAccount “<MSAAccountName> ” (The Web Server Name is where the MSA Account will be used)
On your Passwordstate Web Server, open PowerShell console as Admin, and execute the following commands:
- Add-WindowsFeature RSAT-AD-PowerShell (this role may already be installed)
- Import-Module ActiveDirectory
- Install-ADServiceAccount -Identity <MSAAccountName>

MSA Account and SQL Server

You now need to add a new Windows login within your SQL Server, and you can use the screenshots below as a guide – in our example, the MSA account is called passmsa, and whenever referencing an MSA account you must append the $ symbol to the end.

Create the MSA Login Account

Grant the MSA Account db_owner rights to the Passwordstate database

Configure Passwordstate IIS Application Pools

You need to open Internet Information Services Manager, and modify the “Identity” for both the Passwordstate and PasswordstateApps Application Pools so it uses the MSA Account. When specifying the MSA Account to use, you leave the password fields blank, as per the screenshot below.

Modify the Passwordstate web.config file

Open the web.config file in the root of the Passwordstate folder (open as Admin with notepad or equivalent)
Change the line:

<add name=”PasswordstateConnectionString” connectionString=”Data Source=<ServerName>;Initial Catalog=passwordstate;User ID=passwordstate_user;Password=<MyPassword>” providerName=”System.Data.SqlClient” />

to read like:

<add name=”PasswordstateConnectionString” connectionString=”Data Source=<ServerName>;Initial Catalog=passwordstate;Integrated Security=SSPI;” providerName=”System.Data.SqlClient” />

Save the file and exit notepad

Configure Passwordstate Windows Service

We now need to change the ‘Log On As’ property for the Passwordstate Windows Service to use the MSA Account.

When doing so, you may need to select the ‘Service Accounts’ Object Type in order to find the account in Active Directory, as per the screenshot below:

And also leave the password for the account blank, just like the Application Pools.

Now restart the Passwordstate Windows Service.

File System NTFS Permissions Considerations

The Passwordstate Windows Service can write to disk any new Custom Images or Logos that you may have uploaded into Passwordstate. It is possible that the MSA Account you’re using does not have modify rights to the Passwordstate folder, in which case we can do one of two things:

If you have configured the Backup and In-Place Upgrade account in Passwordstate on the screen Administration -> Backups and Upgrades, then this account will be used for writing images to disk, and you do not need to do anything further
If you are not using the Backup and In-Place Upgrade feature, you will need to manually add Modify NTFS permissions to the Passwordstate folder and all nested files/folders for the MSA Account.

If neither of the two options above is possible, images cannot be written to the disk, and appropriate event log entries on your web server will be added to reflect this.

Filed Under: General Post Tagged With: Managed Service Account, passwordstate, SQL Server

Passwordstate Remote Session Launcher

February 5, 2015 by support 4 Comments

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.

Logging
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

Chrome

Firefox

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.

Filed Under: General Post Tagged With: passwordstate, RDP, Remote Session, Remote Session Launcher, SSH, Telnet, VNC

Passwordstate 7.0 New Features

September 14, 2014 by support 8 Comments

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 – http://www.telerik.com/products/aspnet-ajax.aspx

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 (https://www.duosecurity.com), 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.

Filed Under: Development Tagged With: password management, password manager, passwordstate, Passwordstate 7

Passwordstate Now Fully Integrated with Remote Desktop Manager

March 20, 2014 by support Leave a Comment

Not so long ago we have the privilege of working with the team at http://devolutions.net/, to fully integrate Passwordstate with their awesome software Remote Desktop Manager (http://remotedesktopmanager.com/). 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.

Select the Passwordstate Credential type

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

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

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.

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

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

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.

Regards
Click Studios

Filed Under: General Post Tagged With: Devolutions, passwordstate, Remote Desktop Manager

Choosing Good Passwords

March 9, 2014 by support Leave a Comment

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 – http://www.auscert.org.au/render.html?it=2260

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
Length	Number of Passwords	Number of passwords	Cracking Time
1	62	Not nearly enough	Try this by hand
2	3844	Three thousand	Almost no time
3	238328	One quarter of a million	Less than one second
4	14776336	Fourteen million	Two seconds
5	916132832	Almost one billion	Two and a half minutes
6	56800235584	Fifty six billion	Two and a half hours
7	3521614606208	Three and a half trillion	One week
8	218340105584896	Two hundred trillion	One year
9	13537086546263552	Thirteen quadrillion	Seventy years
10	839299365868340224	Eight hundred and forty quadrillion	Forty centuries
11	52036560683837093888	Lots	A quarter of a million years
12	3226266762397899821056	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 Characters	Number of Passwords	Cracking Time
7-bit ASCII	128	72057594037927936	Three hundred and fifty years
Printable Characters	95	6634204312890625	Thirty three years
Letters and Numbers	62	218340105584896	One year
Letters only	52	53459728531456	Ninety six days
Lowercase with one Uppercase	26/special	1670616516608	Three days
Lowercase only	26	208827064576	Nine hours
English words: eight letters or longer	special	250000	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.

References

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 – http://www.auscert.org.au/render.html?it=2260

Filed Under: General Post Tagged With: good passwords, Password Generator, passwordstate, strong passwords

Passwordstate Now Fully Integrated with AuthAnvil Multi Factor Authentication

February 18, 2014 by support Leave a Comment

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:

On the screen Administration -> System Settings -> Authentication Options tab, you need to specify your AuthAnvil URL and various other settings
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.

Regards
Click Studios

Filed Under: General Post Tagged With: AuthAnvil, passwordstate, Scorpion Software, Two-Factor Authenticaiton

Overview & System Requirements

Installation Instructions

Browsers and Launching External Applications

Internet Explorer

Chrome

Firefox

Hosts & Remote Session Credentials

About this blog

Categories

Archives