To avoid potential security threats, customers operating DIVAdirector must be concerned about authentication and authorization of the system.
These security threats can be minimized by proper configuration and by following the post installation checklist in Appendix A.
This chapter includes the following information:
The critical security features that provide protections against security threats are:
Ensures that only authorized individuals are granted access to the system and data.
Access control to system privileges and data. This feature builds on authentication to ensure that individuals get only appropriate access.
TLS 1.2 is implemented for Oracle DIVAdirector API, and the DIVAdirector Web Interface. This has been accomplished by upgrading the framework to .Net 4.6.2, which uses TLS 1.2 by default.
DIVAdirector now uses the PBKDF2 algorithm with an injectable hashing function which is currently set to SHA512. Salts are randomized, provided on a per password basis, and the iteration count is progressive (based on year) with a minimum of 10000 hashing iterations. Passwords are stored with their hash and iteration count in the database with a history of previous passwords to ensure that the complexity requirements are met. The old MD5 hashing algorithm still exists within the code base exclusively to provide a path to reset passwords using the new algorithm.
Customers are required to use a domain account for securing connections to remote proxy storage, IIS, and PostgreSQL. The installer still creates a dd5-user account by default. However, this account must be changed immediately using the steps outlined in the Oracle DIVAdirector Installation Guide. There are two reasons for this change:
It centralizes and simplifies the operating system permissions required to perform application tasks.
It is required to configure PostgreSQL to use SSPI connections.
You can set up PostgreSQL SSPI Pass-Through Authentication after DIVAdirector is upgraded if you are using the same domain user account to run all DIVAdirector services, the IIS application pool, and PostgreSQL. This configuration removes the need to have plain text user names and passwords in the connection strings.
Follow the instructions at https://wiki.postgresql.org/wiki/Configuring_for_single_sign-on_using_SSPI_on_Windows to enable SSPI for PostgreSQL.
After you complete the instructions, you must update the configuration files for each of the following DIVAdirector services. You must modify the configuration files in the following default locations:
C:\Program Files(x86)\DIVAdirector 5\www\Web.config
C:\Program Files (x86)\Divadirector 5\TaskManager\Oracle.DIVAdirector.TaskManager.exe.config
C:\Program Files (x86)\Divadirector 5\Api\Oracle.DIVAdirector.Api.exe.config
C:\Program Files (x86)\Divadirector 5\Tools\DDServices\DIVADirectorServices.exe.config
In each of the services the key will be the same:
<connectionStrings>
<add name="DIVAdirectorContext"
connectionString="Server=localhost;Database=DIVAdirector;User Id=postgres;Password=MANAGER;" providerName="Npgsql"
/>
</connectionStrings>
You must modify the connection string parameter as follows:
connectionString="Server=localhost;Database=DIVAdirector;Integrated Security=true;Include Realm=true;"
You can secure your connections using SSL as follows:
connectionString="Server=localhost;Database=DIVAdirector;Integrated Security=true;Include Realm=true; SSL Mode=Require;"
Due to security concerns with the implementation of the file viewer on the Archive page, a new feature allows the manipulation of files on connected sources. To secure these connections DIVadirector authenticates user log ins, group configuration allows only specific access, and session timeouts log out unattended sessions.
Flat File Export allowed users to export database tables into csv files and download them through the Web Interface. The option to export database tables as flat files through the DIVAdirector interface has been removed due to security concerns. Oracle is currently reexamining use cases for this functionality to determine whether to re-implement it in a different form on a per use case basis in such a way that you are not exposed to the same risk.