Passwordstate Permission Model Changes

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

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

Things to note about this new Permissions Model:

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

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

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

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

  • Next highlight the Folder and select Folder Properties.

 

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

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

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

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

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

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

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

Passwordstate Build 7393 New Features

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

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

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

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

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

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

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

Script Name

Privileged Account Required

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

Passwordstate Remote Session Launcher

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

Overview & System Requirements

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

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

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

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

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

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

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.



Passwordstate Now Fully Integrated with Remote Desktop Manager

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.

  1. Select the Passwordstate Credential type

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

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

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

 

Creating a Remote Connection Entry in RDM

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

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

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

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

 

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

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

Regards
Click Studios

Choosing Good Passwords

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

Article Source – 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

Passwordstate Now Fully Integrated with AuthAnvil Multi Factor Authentication

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

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

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

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

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

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

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

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

Regards
Click Studios

Two-Factor Authentication Using Email and Pin Code

In Build 6215 we introduced another two-factor Authentication option in addition to what was already possible with RSA’s SecurID or Google Authenticator. If you’d also like to watch a video demonstrating this feature, you can do so here – Watch Video

This two-factor authentication option allows you to specify an email address where a temporary pin code can be emailed, which is used as the basis for the authentication. Instead of just using your email address associated with your Passwordstate user account, we provide the option to specify a different email address so you can send it to a personal email account none of our work colleges may have access to, so you can receive the email on your mobile device, or so you can send to an SMS gateway. In addition to using this authentication method for accessing Passwordstate, you can also configure Password Lists to use this option as an additional authentication step which is required each time a user wishes to access password records in the Password List.

Before we get into how it works, let’s cover off on some of the settings for this feature.

In order to start using this feature, you need to first select the Authentication Option on the Preferences screen, and also specify the email address of where you want the temporary pin code to be sent. It’s possible your Security Administrators of Passwordstate may select this authentication option for you as well, and they can do this as a System Wide setting, or possibly configure a User Account Policy for you.

 

The Security Administrators of Passwordstate can also configure a couple of settings for this feature, including the minimum length of the pin code and how long the pin code will be active.

 

Now your Preferences and System Settings are configured, you will be presented with the following screen when you attempt to authenticate. You will notice initially the login screen reminds you which email address the Pin Code is being sent to, and then it shows a countdown timer indicating when the temporary pin code will expire.

 

And below is a screenshot of an example email you will receive – simply enter the pin code before it expires, and the authentication step will be complete.

 

 

Mobile Client Support in Passwordstate

In the upcoming release of Version 6.2 of Passwordstate, we will have Mobile Client support for iOS, Android, Windows 8 Phone and Blackberry. In this blog post, we will run through some detail for User and System Preferences for the Mobile Client, as well as the features available in the Mobile Client itself.

User Preferences

On the ‘Preferences’ screen on the main Passwordstate web site, you will find various settings which control how the Mobile Client will behave for you. Below is an explanation of each of these settings.

Default Home Page You can either choose your default home page to browse/filter all the Password Lists you have access to, or go straight to a screen where you can search for the password record you require
Limit the Number of Records to As cellular/mobile networks are typically slower than local networks, it’s recommended you limit the number of records returned to help with performance.
Mobile Pin Number The Pin Number you will use to authenticate with when using the Mobile Client – this is in conjunction with your UserID for Passwordstate

 

System Settings

The Mobile Access Options tab on the screen Administration -> System Settings allows you to specify multiple settings for how the Passwordstate Mobile Client behaves for your users.

Allow Mobile clients to access Passwordstate:
If you do not wish to allow Mobile Access to passwords, you can disable access altogether by selecting this option.

  • Note 1: If you choose to disable Mobile Access, it is recommended you set the option below to ‘No’, and then go to the screen Administration -> Passwords Lists -> Mobile Access Bulk Permissions, and then disable Mobile Access for all permissions
  • Note 2: Even if this option is enabled, your Firewall/System Administrators still need to configure external DNS and allow access through the firewall for anyone to access the Mobile Client web site

 

When adding new permissions to Password Lists, enabled Mobile Access by default:
When adding new permissions to a Password List, you can use to enable/disable Mobile Access by selecting the appropriate option here.

The Mobile Access Pin Number for user authentication must be a minimum length of:
You can choose the length of the Mobile Access Pin Number the users must use to authenticate with. When the users specify their own Pin Number on the Preferences screen, or use the option to generate one, it must meet the minimum length requirement of this setting.

The Inactivity Timeout for Mobile Access is (mins)
If the user forgets to log out of the Mobile session, this setting will automatically log them out after the set period of inactivity, and also clear their authenticated session.

Protect against brute force dictionary authentication attempts by locking out an active session after the following number of failed login attempts:
As the Mobile Access web site is generally externally accessible from your internal network, this setting will mitigate against any brute force authentication attempts by locking out authentication attempts when this setting has been reached.

 

 

Mobile Client Permissions

In addition to enabling Mobile Access for your users on the System Settings screen, access is also granted via applying permissions at the Password List level.

As you’re able to apply permissions at the Password List level, this means you don’t need to expose all passwords via the Mobile Access Client if you don’t want to.

Enabling/Disabling Mobile Access when Adding New Permissions
When you add new permissions to a Password List, you can choose to enable/disable Mobile Access using the ‘Mobile Access’ option on the screen.

Enabling/Disabling Mobile Access for Existing Permissions
With the permissions already applied to your Password Lists, you can choose to enable/disable Mobile Access by selecting the ‘Enable/Disable Mobile Access’ option under the ‘Actions’ dropdown menu.

 

Enabling/Disabling Mobile Access Permissions in Bulk
If you would like to enable/disable Mobile Access permissions for more than one Password List at a time, then you can do so via the page Administration -> Password Lists -> Mobile Access Bulk Permissions.

 

Mobile Client Usage

This following information provides instructions for how to use the Mobile Client itself. The following features are currently available in the Mobile Client:

  • Authentication
  • Browse/Search Password Lists that you have access to
  • Browse/Search Passwords within a selected Password List
  • Search for an individual password record, across all the Password List you have access to – similar to searching on the ‘Passwords Home’ page on the normal Passwordstate web site
  • View password records


Mobile Client Authentication
To authenticate using the mobile client, you need to specify your account’s UserID and the Pin Number associated with it.

Note: If using the AD Integrated version of Passwordstate, it’s not necessary to specify the UserID in the format of Domain\UserID – you can simply type just the UserID. The only exception to this would be if you had multiple Active Directory domains registered in Passwordstate, and there were duplicate logon names in AD.

 

Browsing/Filtering Password Lists
After you have authenticated, the default home screen is the one below which allows you to browse all the Password Lists your account has been given access to. A couple things to note about this screen are:

  1. The number of records displayed may be limited by the setting ‘Limit the Number of Records to’ on your User Preferences screen
  2. When searching/filtering Password Lists, you can search by the Title of the Password List, and also the Tree Path of the Password List in the Navigation Tree (the Tree Path is the logical structure/path of where the Password List is positioned in the Password List Navigation Tree on the main web site)

Browsing/Filtering Passwords for the selected Password List
After you have tapped on the appropriate Password List, you will be directed to the screen below which allows you to browse all the passwords in the selected Password List. A couple things to note about this screen are:

  1. The number of records displayed may be limited by the setting ‘Limit the Number of Records to’ on your User Preferences screen
  2. When searching/filtering passwords, you can search across all of the fields which can be configured for a Password record i.e. Title, Description, UserName, URL, Generic Fields, etc. The only fields you can’t search are the one’s which are encrypted i.e. the Password field, and any Generic Fields set as type ‘Password’

 

Viewing a Password Record
When you tap on one of the Password records on the screens above, you will be directed to the screen below where you can view the details of the password record. A couple of things to note about this screen are:

  1. An auditing record will be added, as you have viewed the details of this password record. If enabled in the main web site settings, any other users who have access to this password record will receive an email notification informing them you have accessed it
  2. Most mobile devices allow you to copy details to the clipboard if required, and majority of fields on this screen will allow you to copy their details
  3. If there are any ‘One-Time Access’ permissions enabled for this password record for your account, your access will automatically be removed after you have viewed the record

 

Password Search Home Page
If you have selected ‘Passwords Search’ as your default home page on the User Preferences screen, you will be directed to the screen below after you have authenticated. From here you can search for a password record across all of the Password Lists you have been given access to. This is a similar search feature which you will find on the ‘Passwords Home’ in the main web client.

 

When searching for Password records this way, a little more detail is shown on the screen so you know which Password List the password record belongs to.

 

Logging Out of the Mobile Client
When you tap on the ‘Exit’ button on the top right-hand side of the screen, you will be directed to the screen below and your Mobile Access session will be ended. If your leave your session inactive longer than the setting specified on the System Settings page, you will also be automatically logged out and directed to this screen.

 

 

Passwordstate 6.0 New Features

Hello Everyone,

Before we go into any detail about the new features of version 6, we just want to say a huge thanks to all our wonderful customers for their suggestions of what they would like to see in Passwordstate, and also for helping us test the various beta versions. It’s amazing how people will take time out of their day to provide feedback, and spend endless hours testing with us. Thanks Guys If you’re wanting to upgrade your beta install to this production release, please follow these instructions – http://www.clickstudios.com.au/forum/showthread.php/365-Upgrade-Instructions-for-Production-Release-(Build-6080) J

Now on to the features. We’re very pleased to finally release version 6 of Passwordstate. This is probably one of the biggest releases we’ve had to date, and it’s been 8 months in the making. We’ll go into some detail here for the major changes in version 6.

New User Interface
The first thing you will notice when using v6 is the new user interface. The main change is how the old navigation tabs in version 5 have now been moved to the bottom of the screen as a horizontal popup menu. This provides a little more screen real-estate, which is useful when the majority of your time is spent clicking around in the navigation tree, and access passwords in each of the different Password List screens. We’ve also had quite a few beta testers comment on the new version appearing to run much faster.

Two-Factor Authentication with RSA’s SecurID
Version 6 now has 9 different authentication options, which can be used when you first access the site, or as an additional authentication step when you need to access certain Password Lists. One of these new authentication options is two-factor authentication with RSA’s SecurID tokens – these can be physical or software based tokens. There’s obviously quite a few versions of the RSA Authentication Manager, and in our testing we’ve used version 7.1 SP4 Patch 22. RSA assures us that prior and new releases should work just fine. Read more here – http://www.clickstudios.com.au/blog/two-factor-authentication-with-rsa-securid/

Two-Factor Authentication with Google Authenticator
Can’t afford the investment for RSA’s SecurID solution, then use two-factor authentication with Google’s Authenticator. Google Authenticator is a software based solution, which can be installed on the majority of mobile clients. Read more here – http://www.clickstudios.com.au/blog/two-factor-authentication-with-google-authenticator/

Application Programming Interface (API)
With the new API built into Passwordstate, you can integrate your other applications and do away with hard coded passwords in scripts, etc. Data can be returned in either JSON or XML format.

It’s possible to perform the following API Calls:

  • Retrieve a Password record
  • Update a Password record
  • Add a new Password record
  • Retrieve all the history for changes to a Password record
  • Retrieve all Passwords records in a specific Password List
  • Retrieve all Passwords records across all Shared Password Lists
  • Search for Password records, based on various search criteria
  • Generate one or more random passwords
  • Retrieve details and settings for a Password List

For each Password List which you enable for the API (create and API Key), you can also configure which of the API calls above is allowed, or not allowed, as per the following screenshot:

 

Linking Password Lists to Templates
Password List Templates where introduced in version 5, which allowed you to specify some default settings which could then be applied to a Password List. With version 6, we’ve now introduced the feature whereby you can link a Template to one or more Password Lists, and manage the settings in one central location – the template itself. Read more here – http://www.clickstudios.com.au/blog/linking-password-lists-to-templates/

User Account Policies
User Account Policies allows you to specify various settings for how Passwordstate appears or behaves for users. Once you’ve created a policy, you can apply permissions based on user accounts, or security groups. You can even apply more than one policy to the same user. Examples of how this would be used are:

  • Specify a different Authentication Method for users who have higher privileges to systems i.e. Domain Administrators
  • You don’t wish for any of the charts to appear for your users – simply disable them with a policy
  • Allow only a certain number of users to use the ‘Auto Generate New Password’ feature when adding new passwords

Read more here – http://www.clickstudios.com.au/blog/user-account-policies-in-passwordstate/
More Generic Fields and Different Data Types
There are now up to 10 different Generic Fields you can choose from for your Password Lists, and each field can be configured as one of the following data types – Text Field, Free Text Field, Password Field, Select List, Radio Buttons or Data Picker. Read more here – http://www.clickstudios.com.au/blog/generic-field-improvements/


Allowed IP Ranges
Need to restrict which networks can access the Passwordstate web site or API? If so, then you can use the ‘Allowed IP Ranges’ feature, where you can specify individual IP Addresses, or a range of IP Addresses. Read more here – http://www.clickstudios.com.au/blog/allowed-ip-ranges-in-passwordstate/

Backups and In-Place Upgrades
Version 6 now has an automated backup feature built into it, where you can set a schedule for automatic backups of all the web files, and copies of the database. You can specify at what time of the day the backups should begin, how often they should be run, and how many copies to keep on disk. In addition to automatic backups, we now have In-Place Upgrades, which means no more uninstalling/reinstalling Passwordstate to get to the latest version – simply upgrade right from within the web site. You must have your automatic backups configured and working prior to using the In-Place Upgrades feature. Read more here – http://www.clickstudios.com.au/blog/backups-and-in-place-upgrades/

Active Directory & Windows Actions
When a Password List is configured to synchronize password changes with Active Directory, or local accounts on Windows Servers, you can now enable the feature ‘Active Directory & Windows Actions. With this feature you can perform certain account related tasks, such has unlocking account, disable accounts, etc. Read more here – http://www.clickstudios.com.au/blog/active-directory-actions/

Automatic Password Rotation
Again, when a Password List is configured to synchronize password changes with Active Directory, or local accounts on Windows Servers, you can take advantage of the ‘Automatic Password Rotation’ feature, which allows you to specify a set and forget schedule for automatically updating and synchronizing passwords when they expire. Read more here – http://www.clickstudios.com.au/blog/automatic-password-rotation/

Regards
Click Studios