SECURE INSTALLATION AND CONFIGURATION

The Secure Installation and Configuration consists of following topics:

This chapter provides an overview of the architecture of the deployment and describes the installation and configuration procedure for Oracle Banking Digital Experience.

Please note that this is only a guide to securing the Oracle Banking Digital Experience application and does not replace periodic reviews of the security architecture of the entire ecosystem of multiple applications maintained by the customer. The guidance provided in this document must always be augmented by specific understanding of the security considerations of the specific deployment architecture.

Architecture Diagram

Security

Installing WebLogic

Installation of Weblogic Server can be done by referring to the documentation published at https://docs.oracle.com/cd/E24329_01/doc.1211/e24492/toc.htm

Configuring SSL

One way SSL between the presentation tier and the application on WebLogic server is supported. The detailed configuration is explained below:

Note: Procure an external CA signed certificate before proceeding further. Follow the instructions below to install the certificate once the certificate is available.

Execute the following command:

keytool -import -trustcacerts -alias sampletrustself -keystore SampleTrust.jks -file SampleSelfCA.cer.der -keyalg RSA 
keytool -import -alias `hostname -f` -file `hostname -f`.cer -keystore <JAVA_HOME>/jre/lib/security/cacerts -storepass changeit -noprompt

Security

Field

Value

Custom Identity Keystore

Absolute path of the custom keystore

Custom Identity KeyStore Type

JCEKS

Custom Identity KeyStore Passphrase

<Passphrase>

Confirm Custom Identity KeyStore

Passphrase

<Re-enter the same Passphrase>

Enter the passphrases that were used while creating the custom Identity Keystore and certificate.

Security

Enter the following details in the Identity section

Field

Value

Private Key Alias

<Alias>

Private Key Passphrase

<Passphrase>JCEKS

Confirm Private Key Passphrase

<Re-enter passphrase>

Security

Disable SSLv3

By default, SSLv3 should be disabled.

Specifying the weblogic.security.SSL.protocolVersion system property in a command-line argument that starts the WebLogic Server lets you specify the protocol that is used for SSL connections.

The following command-line arguments can be specified so that WebLogic Server supports only TLS connections.

-Dweblogic.security.SSL.protocolVersion=TLS1

Note: If you don’t specify the above property, weblogic assumes SSLv3 by default.

HTTP Response Header Configurations

The following are some HTTP Response Headers that mitigate certain vulnerabilities.

Vulnerability

HTTP Response Header

Clickjacking

X-Frame-Options

XSS

Content-Security-Policy

X-XSS-Protection

Cookie hijacking

Protocol Downgrade attacks

Strict-Transport-Security

Retrieving Sensitive data from browser cache

Cache-Control

The sections below specify how to configure these response headers in the httpd.conf file of the web server.

X-Frame-Options

Header always append X-Frame-Options SAMEORIGIN

Content-Security-Policy

Header set Content-Security-Policy "default-src 'none'; img-src 'self' 
data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 
https://fonts.googleapis.com 'unsafe-inline'; object-src 'none'; frame-src 
'none'; font-src 'self' https://fonts.googleapis.com/
https://fonts.gstatic.com/ data:; connect-src 'self' 
https://fonts.googleapis.com/ https://fonts.gstatic.com/ http://<OAM 
Server>:<OAM Port>; manifest-src 'self'; child-src 'self'"

Please note that the policy mentioned here is for the base product. If the product gets customized and content from different URLs needs to be allowed to be executed by the browser, then this policy will have to be modified accordingly.

X-XSS-Protection

Header set X-XSS-Protection “1; mode=block”

Strict-Transport-Security

Set this for your top level domain. The header directive needs to be included inside the VirtualHost directive

<VirtualHost *:443>
Header always set Strict-Transport-Security “max-age=31540000; includeSubDomains”
</VirtualHost>

Consider submitting your website to be included in the HSTS preload list of websites maintained by Google Chrome at https://hstspreload.appspot.com/.

Other browsers like MS IE 11, MS Edge, Firefox and Opera also refer to this list maintained by Google and therefore the security offered by this mechanism will extend to other browsers too.

Cache-Control

Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires 0

Password Policy Guidelines

Our recommendations for setting a password policy are in line with the latest recommendations from NIST as of July 2017.

Password Policy Configuration

The password policy can be maintained in the Oracle Banking Digital Experience database or you can also set it in the LDAP user repository, if one is being used.

You need to specify your preference in the property shown below

Security

A value of “true” in PROP_VALUE indicates that the password policy set in the local database needs to be applied.

A value of “false” in PROP_VALUE indicates that the password policy set in the LDAP user repository needs to be applied.

When PROP_VALUE is set to “true”, the password policy must be set in the database table DIGX_UM_PWD_POLICY. The following table lists the columns of the table and significance of each column:

Column Name

Significance

PASSWORDPOLICYID

Unique Identifier for the password policy.

PWD_POLICY_NAME

Human friendly name given to the policy.

PWD_MIN_LENGTH

Minimum length of the password.

PWD_MAX_LENGTH

Maximum length of the password.

CHAR_ALLOWED

Characters allowed in the password

1

Upper Case Letters

2

Lower Case Letters

9

Numbers

-1

Special Characters

FIRST_CHAR_ALLOWED

Characters allowed as the first character of a password.

LAST_CHAR_ALLOWED

Characters allowed as the last character of a password.

NBR_UPPER_CASE

Minimum number of upper case characters required in the password.

NBR_LOWER_CASE

Minimum number of lower case characters required in the password.

NBR_NUMERIC_CHAR

Minimum number of numeric characters required in the password.

NBR_SPECIAL_CHAR

Minimum number of special characters required in the password.

SPECIAL_CHAR_ALLOWED

List of special characters allowed in the password.

NBR_REPEATED_CHAR

Maximum number of times a character is repeated in the password.

NBR_SUCCESSIVE_CHAR

Maximum number of times a character can be repeated successively in the password.

The following image shows the recommended values for the key columns of the database table DIGX_UM_PWD_POLICY.

Security

Note: 1) The password policy ID and name are at your discretion and no specific recommendations are being made for them.
2) A different password policy can be set for each user group that you define. The password policy applicable for a particular user group can be defined in the table DIGX_UM_PWD_GROUP_MAP. That’s where the password policy ID will come in handy.
3) If you want the same password policy to be applicable for all groups then you can simply define just one policy in DIGX_UM_PWD_POLICY. You can leave the mapping table DIGX_UM_PWD_GROUP_MAP empty.

Configuring 2FA for login

Oracle Banking Digital Experience supports a 2nd factor of authentication during login.

Security

Security

Security

Security

Security

Configuring 2FA attributes

This section covers some key attributes of the 2nd factor of authentication (re-authorization). Attributes like the maximum number of times a user is allowed to hit the “Resend” button after an OTP is generated, the pool of security questions etc are a couple of examples of 2FA attributes.

These attributes are seen in the database in the PROP_ID column of the table DIGX_FW_CONFIG_ALL_B (CATEGORY_ID = ‘authenticationConfig’). The following table lists down all possible attributes and their significance. Their values must be set in the column PROP_VALUE.

PROP_ID

Significance

OTP.EXPIRATION_TIME

Time in milliseconds after which an OTP will expire.

T_SOFT_TOKEN.EXPIRATION_TIME

Time in milliseconds after which a time based soft token will expire.

R_SOFT_TOKEN.EXPIRATION_TIME

Time in milliseconds after which a random soft token will expire.

SEC_QUE.EXPIRATION_TIME

Time in milliseconds after which answers to the security questions presented to the user will no longer be considered for re-authorization.

EXPIRATION_TIME

Time in milliseconds after which the re-authorization factor will expire. This is the default property that will be looked up in case factor specific expiration times are not maintained.

OTP.MAX_NO_ATTEMPTS

Max number of unsuccessful attempts of entering a valid OTP after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time.

T_SOFT_TOKEN.MAX_NO_ATTEMPTS

Max number of unsuccessful attempts of entering a valid time based soft token after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time.

R_SOFT_TOKEN.MAX_NO_ATTEMPTS

Max number of unsuccessful attempts of entering a valid random soft token after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time.

SEC_QUE.MAX_NO_ATTEMPTS

Max number of unsuccessful attempts of entering valid answers to security questions after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time.

MAX_NO_ATTEMPTS

Max number of unsuccessful attempts of entering valid 2FA after which all 2FA enabled transactions for the user will be locked for a "cooling period" amount of time. This is the default property that will be looked up in case factor specific Max Attempts are not maintained.

TFA_LOCK_COOLING_PERIOD

This is the cooling period in milliseconds after which 2FA transactions which were locked out because of exceeding MAX_NO_ATTEMPTS, are enabled once again.

OTP.MAX_ACTIVE_REF_NO

Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to OTPs.

This property is in place as a basic mechanism to protect the application against DOS attacks where the end user can keep generating OTPs by initiating transactions and making the system generate the 2nd factor of authentication, but not going through and completing the transaction.

T_SOFT_TOKEN.MAX_ACTIVE_REF_NO

Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Time Based Soft Tokens.

R_SOFT_TOKEN.MAX_ACTIVE_REF_NO

Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Random Soft Tokens.

SEC_QUE.MAX_ACTIVE_REF_NO

Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This one is specific to Security Questions.

MAX_ACTIVE_REF_NO

Max number of attempts to generate 2FA reference numbers for a transaction after which no more attempts can be made for EXPIRATION_TIME units of time for that factor of authentication. This is the default property that will be looked up in case factor specific Max Active Reference Number attempts are not maintained.

OTP.RESEND_COUNT

Max number of times a user can hit the “Resend” button in case of OTPs. After exceeding this count, the user will need to re-initiate the transaction all over again.

retailuser.NO_QUE_ANS

Number of security questions that a retail user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions.

corporateuser.NO_QUE_ANS

Number of security questions that a corporate user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions.

administrator.NO_QUE_ANS

Number of security questions that an admin user needs to setup (answer). During an actual transaction he will be asked a sub set of these questions.

NO_QUE_ANS

Number of security questions that a user segment needs to setup (answer). During an actual transaction he will be asked a sub set of these questions. This is the default property that will be looked up in case factor specific NO_QUES_ANS is not maintained.

Choosing a non blocking PRNG

OBDX uses Java’s random number generation capabilities internally. However the out of the box algorithm for PRNG configured in the JDK can block the thread after a certain time if there isn’t enough randomness available. This is because the default configuration uses /dev/random on Linux for PRNG.

Therefore we recommend that you navigate to <JDK_HOME>/jre/lib/security and edit the java.security file. Comment out the old property and change its value as shown below.

Security

This will ensure that the application uses /dev/urandom for PRNG.

Needless to say, make sure you make this change in the JDK that your weblogic server is going to be using.

Mobile App SSL Pinning Configuration

SSL Pinning has been implemented in the mobile apps, both iOS and Android. The public key certificate of the server needs to be imported into these apps for the connection to the server to be successful. The certificate needs to have an extension .cer and needs to be placed in mobile app workspaces as shown in the images below:

Security

The name of the certificate file needs to be configured in a property file. For iOS it is the app.plist file.

Security

For Android it is the app.properties file.

Security

Back