Security Considerations

Applies to Collaborator 14.5, last modified on April 18, 2024

Collaborator administrators need to be aware of several security issues and options which affect the overall security of the system. This section covers those issues.

Built-in Administrator Account

Each Collaborator server has a built-in administrator account – admin. By default, its password is admin. You must specify your own password for the built-in administrator account in the Users category of Collaborator settings, or using the following command-line:

ccollab login http://your_collabserver admin admin
ccollab admin user edit admin --password newpassword

File System Security

Collaborator relies on the underlying operating system as a foundation for overall system security. Several potentially sensitive items are stored in the local file system, including database credentials, LDAP credentials (if used), and file contents. Care should be taken to maintain system security of the server’s operating system, so this information is not compromised. SmartBear does not have any specific security expertise, so we recommend you follow the guidance from vendor of your operating system.

HTTP Transport Security

By default, the Collaborator server operates over regular HTTP. This means that all communications between clients and servers are unencrypted on the wire. So, it is possible for someone with access to the network to use network sniffing tools to gather information from that traffic. Some things that are available over the wire are file contents, user conversations, and even authentication credentials (usernames and passwords). If wire-level security is a concern, administrators should configure the server to use secure http (HTTPS). Enabling HTTPS, also adds the Secure attribute to the browsers session cookies, that is, they can only be transmitted over an HTTPS connection.

There are two cookies that store user login and session information (CodeCollaboratorLogin and CodeCollaboratorTicketId respectively). The expiration date of the session cookies is so far in the future that they will never expire, but there is a server setting that overrides that expiration date and controls the length of time that the session is valid. This setting is called Login Ticket Time-To-Live and can be configured by the Collaborator admin. This setting is not an idle timeout – it is an absolute time the ticket will remain valid after it is created.

The application server-managed session cookie, JSESSIONID, is only valid during the session and it is used to identify the session, but it does not contain any user information. We also store some WebUI preferences locally, but that data also does not contain any user information.

All session cookies have the HTTPOnly attribute set, which means that these cookies can only be used by web browsers, and cannot be accessible via scripts or by other means.

Obfuscate Database Passwords

Some environments dictate that sensitive passwords stored in configuration files be obfuscated. In the case of Collaborator, this most commonly occurs in conjunction with the database connection information stored in <Collaborator Server>/tomcat/conf/Catalina/localhost/ROOT.xml.

Starting from Collaborator 8.4.8403, obfuscating the database password has preliminary support as a post-install operation. Three forms of obfuscation are supported: base64-encoding, base64-encoded AES 128 bit and base64-encoded AES 256 bit. AES obfuscation uses ECB mode with a fixed key and PKCS#5 padding.

Starting from 13.7.13700, obfuscation can be performed using either Database Connection Pool v.2 (DBCP2) or Java Database Connection Pool (JDBC).

Of the three forms, base64-encoding is the recommended process, if sufficient, as it is simpler.

Note: To use the AES-256 bit obfuscation, additional files are required.

Due to the import restrictions of some countries, Java SE have built-in restrictions on available cryptographic strength. Cryptographic strength can be configured via jurisdiction policy files that can be downloaded separately. In order to use AES-256 bit obfuscation, you will need to download and install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle web site: Java Cryptography Extension for JRE 7 and Java Cryptography Extension For JRE 8.

Base64 obfuscation using Database Connection Pool v.2

AES-128 obfuscation using Database Connection Pool v.2

AES-256 obfuscation using Database Connection Pool v.2

Base64 obfuscation using Java Database Connection Pool

AES-128 obfuscation using Java Database Connection Pool

AES-256 obfuscation using Java Database Connection Pool

Obfuscate LDAP Passwords

Starting in Collaborator 8.5.8501, LDAP passwords may be obfuscated in a similar fashion to the database password above. Three forms of obfuscation are supported: base64-encoding, base64-encoded AES 128 bit, and base64-encoded AES 256 bit. AES obfuscation uses ECB mode with a fixed key and PKCS#5 padding.

Of the three forms, base64-encoding is the recommended process, if sufficient, as it is simpler.

Note: To use AES-256 bit obfuscation, additional files are required.

Due to the import restrictions of some countries, Java SE have built-in restrictions on available cryptographic strength. Cryptographic strength can be configured via jurisdiction policy files that can be downloaded separately. In order to use AES-256 bit obfuscation, you will need to download and install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from the Oracle web site: Java Cryptography Extension for JRE 7 and Java Cryptography Extension For JRE 8.

Base64 obfuscation

AES-128 obfuscation

AES-256 obfuscation

See Also

Configure HTTPS
Platform-Specific Notes
Admin Tasks

Highlight search results