NetX takes security very seriously. To this end, we provide a number of security layers, as well as a variety of configuration options to meet your specific security requirements.

Session key configuration

When users successfully log in to NetX, they are provided with a session key for access to data within the application. By default, user session keys are valid for 30 minutes; that duration is extended as long as the session key is being used to make calls back to the server. Administrators can modify this behavior to meet security requirements with the following properties:

PropertyDescriptionDefaultRestart required?


This property controls the length of time in minutes that the internal session keys remain valid. Please only change this value if you know what you are doing as it can affect the security of your installation. The default timeout is 30 minutes. 



By default, the UI "tickles" the session to keep it alive (every ten minutes); if "user.sessionInactivityTimeout" is set to zero, then the UI will have a session indefinitely. Conversely, if this is set to "true", then sessions will expire based on the value of "user.sessionDuration", regardless of user activity.



This is a directive to the UI. This is based on SOAP/RPC calls, but this ignores calls to setUserPreference() (which is used to "tickle" the session). So if  this set to a number (in minutes), and there is no SOAP/RPC activity, then the user  will be prompted to keep the session active. If there is no response, the Web client will expire the session (via logout() call) 1 minute later. This defaults to 1 hour (60); the value is measured in minutes. Please note that this property isn't currently respected by the HTML5 UI. To manage session expiration in HTML5, please use user.sessionDuration.


Login attempt restrictions

The first line of defense is blocking repeated login attempts. By default, accounts are locked after 10 failed login attempts; and locked accounts remain locked for 30 minutes. Both these can be adjusted as you see fit, with the following properties:

PropertyDefault ValueDescription
user.failedLoginAttemptThreshold10Any integer value is valid; setting this to zero will disable any login failure attempt blocking.
user.failedLoginAttemptTimeout30Any positive, non-zero integer value is valid; measured in minutes.

Additionally, any login attempt to a non-existent account is automatically locked in order to thwart any brute force attacks; in this way, the system can stop making database calls for these non-existent accounts.

Strict passwords

Know that augmented user control — including control over passwords — is easily gained by integrating authentication with either an external LDAP Directory Server, or an SSO system. But in lieu of those options, NetX has a number of password configurations. By default, passwords must be at least 8 characters in length. There are no further  default restrictions. Here are further password configurations that can tighten security:

sys.minimumPasswordLength8This property checks the minimum length required for passwords; the default value is 8 (characters). Does not require a restart.

This property value can be specified by providing a number and a letter, separated by commas. The number designates the number of instances of that character required; and the letter designates the type of character required. Letter designations are as follows:

  • N: number (0 - 9)
  • L: lower case ASCII character (a-z)
  • U: upper case ASCII character (A-Z)
  • S: special characters (see list below)

As an example, a valid value is: "2N,3U,2L"; this would require two numbers, three upper case, and two lower case characters in every password. Requires a restart to take effect.

The following are considered "special characters":

! @ # $ % ^ & * ( ) + = _ - { } ? : ; < > . | [

This property requires a restart before it will take effect.

Changing password restriction settings will not affect existing users until they (or an administrator) attempt the next password change on the account.

Password protection and encryption

Passwords are encrypted "over the wire" — between the client and the server — via SSL. Passwords are cleansed from any logging facilities on the backend.

Lastly, and most importantly, passwords are only stored as hashes in the NetX database. While many applications use SHA-256, NetX goes a large step further; we have recently switched our encryption hashing to use PKCS5 v2.0. Password-Based Key Derivation Function 2 (or "PBKDF2") is a key derivation function that is part of RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, also published as Internet Engineering Task Force's RFC 2898. 

In cryptography, a key derivation function derives one or more secret keys from a secret value such as a master key or other known information such as a password or passphrase using a pseudo-random function. Keyed cryptographic hash functions are popular examples of pseudo-random functions used for key derivation. To squeeze the most security out of a limited-entropy password or passphrase, there are two techniques that sound as if they come from a medieval torture chamber: salting and stretching. These are so simple and obvious that they should be used in every password system. There is really no excuse not to use them. The first is to add a salt. This is simply a random number that is stored alongside the data that was encrypted with the password. The next step is to stretch the password. Stretching is essentially a very long computation.  

PBKDF2 applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching. When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU speeds increase. NetX iterates 100,000 times! Having a salt added to the password reduces the ability to use precomputed hashes (rainbow tables) for attacks, and means that multiple passwords have to be tested individually, not all at once. 

For more information on PKCS5 v2.0, please see the following links:

Common security checklist

  • Password length, a minimum of 8 characters.
  • Password complexity, includes the use of alpha, numeric and special characters.
  • Maximum invalid account login attempts: just one.
  • Account lockout thresholds: 10.
  • Inactive session timeout: 30 minutes
  • Passwords are encrypted while in transit using standard cryptographic methods: SSL.
  • Passwords are encrypted or hashed in storage using standard cryptographic methods: PBKDF2.