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.
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.
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