GUIDANCE FOR IMPLEMENTATION TEAMS
The Guidance for Implementation Teams consists of following topics:
- CSRF Mitigation – Generating Nonces
- Indirect Object Reference Implementation
- Output Encoding
- Implementing a custom Cryptography Provider
- Implementing a custom 2FA mechanism
- Configuring Password Printing Securely
- Configuring User Session Invalidation
CSRF Mitigation – Generating Nonces
A nonce is a pseudo random number that may be used only once. If a nonce is sent across in every request from the client to the server and the server validates the sent nonce every single time, then it mitigates the risk of Cross Site Request Forgery (CSRF).
The product provides a REST Service to generate nonces – each nonce can be used only once to identify each request uniquely, for each session. The product also has an inbuilt framework that will validate the nonce sent in the request.
Therefore post a successful login you need to make a call to https://<Host>:<Port>/digx/v1/session/nonce before you make a call to any other service. This service will return back an array of nonces in the response header. You can pick up any one nonce from the array and use it to send across the nonce required in a subsequent request. A nonce can be used only once. You need to discard it after usage.
Please note that unless you send across a nonce, the services that are accessed post login will not work.
Indirect Object Reference Implementation
What it means
It is a good security practice to hide sensitive data objects from the end user. Although the system needs to play around with sensitive data objects, it is recommended to refer to these sensitive data objects via pointers – tokens that temporarily point to the sensitive data objects but themselves do not contain any sensitive data.
For example consider a credit card application on the web which offers the following 2 transactions:
- Credit Cards Summary – Displays a list of all credit cards the user owns.
- Credit Card Details – Displays the details of one specific Credit Card that the user selects.
The Credit Cards Summary page will typically list all credit card numbers in a masked format. Let’s assume that the end user holds 2 Credit Cards C1 and C2. When the end user hits the Summary link, the server returns back the following in its response:
- Masked Credit Card Number C1 (visible to the user)
- Masked Credit Card Number C2 (visible to the user)
- Token T1 (not visible to the user)
- Token T2 (not visible to the user)
T1 and T2 are random tokens – difficult to guess – which the server has generated as proxies for C1 and C2 respectively. The server has internally stored this mapping of C1-T1 and C2-T2 somewhere. Please note that T1 and T2 are tied to the current session. The moment the session expires, T1 and T2 get discarded. Next time the user logs in, the server generates different tokens T1x and T2x for C1 and C2 respectively.
Whenever the user clicks on say Credit CardA credit card is a payment card issued to users (cardholders) as a method of payment. Details for C1, the client sends T1 to the server instead of C1, as a request parameter. The server internally figures out that the request is actually for C1 and processes the request accordingly.
Thus we refer to sensitive data indirectly via tokens that are generated with different values for every session
How OBDX supports it
To implement the above mechanism the framework offers interception of both the request and the response. For the interception to work automatically, the sensitive fields holding the Personally Identifiable Information (PII) must be defined as a Java type, which extends the abstract class.
com.ofss.digx.datatype.complex.MaskedIndirectedObject.
The abstract class essentially exposes 2 fields, namely value and displayValue. The value field holds the indirected value which is used for data transmission. Whereas, the displayValue field holds the masked value of the data.
The following data types are supported out-of-box:
- com.ofss.digx.datatype.complex.Account - Account number
- com.ofss.digx.datatype.complex.Applicant – The unique identifier to identify an applicant. Typically a party ID.
- com.ofss.digx.datatype.complex.ApplicationId – The unique identifier of an application for account opening.
- com.ofss.digx.datatype.complex.ContentId – The unique identifier for content such as documents for a party.
- com.ofss.digx.datatype.complex.CreditCard – Credit Card Number
- com.ofss.digx.datatype.complex.DebitCard – Debit Card Number
- com.ofss.digx.datatype.complex.Email – Email ID
- com.ofss.digx.datatype.complex.Party – The unique identifier for a party
- com.ofss.digx.datatype.complex.PhoneNumber – Phone Number
- com.ofss.digx.datatype.complex.SSN – Social Security Number
- com.ofss.digx.datatype.complex.SubmissionId – The unique identifier for a submission containing 1 or more applications for account opening
To modify the existing/base product-masking pattern for any of the above data types, the following entries need to be copied/cloned from the table DIGX_FW_CONFIG_ALL_B to the table DIGX_FW_CONFIG_ALL_O and then modified as required in DIGX_FW_CONFIG_ALL_O.
Note: Please DO NOT MODIFY these entries IN DIGX_FW_CONFIG_ALL_B.
Data Type |
Category ID |
Property ID |
---|---|---|
Account |
MaskingPattern |
AccountNumberMasking |
MaskingPattern |
ApplicantIdMasking |
|
ApplicationId |
MaskingPattern |
ApplicationIdIdMasking |
ContentId |
MaskingPattern |
ContentIdMaskingPattern |
CreditCard |
MaskingPattern |
CreditCardNumberMasking |
DebitCard |
MaskingPattern |
DebitCardNumberMasking |
|
MaskingPattern |
EmailIdMasking |
Party |
MaskingPattern |
PartyIdMasking |
PhoneNumber |
MaskingPattern |
PhoneNumberMasking |
MaskingPattern |
SSNMasking |
|
SubmissionId |
MaskingPattern |
SubmissionIdMaskingPattern |
The characters allowed in the making pattern are as below:
N – Keeps the character transparent. Does not mask.
Any other character – Replaces the character at the location to the character specified.
For example: XXXXXNNNN will keep the last 4 characters in clear text and mask the first 5 characters using the character ‘X’.
Output Encoding
To To mitigate inline Cross Site Scripting attacks, the product provides a framework to encode the data sent in the response. In the previous versions up until OBDX 17.2.0.0.0 there was guidance in this section of the security guide on the steps needed to be followed to implement output encoding in your service response. However, in OBDX 18.2.0.0.0 this is something that is handled implicitly in the framework for all services, base as well as any custom services that you might write.
There is nothing that you need to do explicitly to achieve this.
Implementing a custom Cryptography Provider
The base product provides a symmetric key cryptography framework that enables the implementation team to implement its own custom symmetric key encryption/decryption mechanism. The product is shipped out with an out of the box Cryptography Provider that will be invoked if no custom implementation is found. If you wish to write your own custom Cryptography Provider, the required steps are as follows:
- Write the custom cryptography provider class such that it implements the interface com.ofss.digx.infra.crypto.spi.ICryptographyProvider
The interface defines methods as shown below:
- Implement the encrypt() and decrypt() methods to encrypt and decrypt the data passed to the methods, using the key passed along with the data.
- Implement the getVersion() method to simply return a number greater than 1. For example:
- Implement the method to simply return the symmetric encryption algorithm name. For example:
- You can leave the implementations of the other two methods blank.
- In the custom jar file that contains the custom Cryptography Provider, create a file with the name com.ofss.digx.infra.crypto.spi.ICryptographyProvider under the folder structure META-INF/services
- Open the file for editing.
- Type out the fully qualified class name of your custom Cryptography Provider class. For example:
Deploy your custom jar on the WebLogic server and you should be all set.
The Cryptography Provider will be invoked when the system invokes the encryption framework for the following actions:
- Encrypting the SMTP Server password entered by the OBDX Admin, before storing it in the Database.
- Encrypting the system generated password for first time users, before storing it in the Database. This is will be relevant to the function of Password Printing.
- Encrypting the Identification Number for the selected Identification Type (Driver’s License, Passport etc) during originating a loan application online.
Implementing a custom 2FA mechanism
- You will need to write your own Java class to implement your own custom factor of authentication.
- The class must be registered in the table DIGX_AU_AUTH_TYPE_MST. Choose a custom ID.
- The custom class must implement the interface:
com.ofss.digx.framework.security.authentication.provider.I2FactorAuthenticationProvider
- To configure your custom authenticator as an additional option available to the admin during the 2FA configuration of transactions, set the custom ID used in Step 2 in the table DIGX_FW_CONFIG_VAR_B.
- The configuration already seen in the above image suggests that an admin will have the option of setting one of OTP, Soft Token and Security Questions as an additional factor of authentication when configuring 2FA for user segments Retail, Corporate and Administrator.
- The PROP_ID that the system must look up in this table (DIGX_FW_CONFIG_VAR_B) is maintained in the table DIGX_FW_CONFIG_ALL_B against the PROP_ID SUPPORTED_AUTH_TYPE.
- If ${_PROPERTY_} is the value maintained against retailuser.SUPPORTED_AUTH_TYPE in the table DIGX_FW_CONFIG_ALL_B, then for retail users the application will look up the table DIGX_FW_CONFIG_VAR_B where PROP_ID = _PROPERTY_ to check what options are available to the admin.
Configuring Password Printing Securely
Banks need to provide new customers with system-generated credentials to enable them to login into the system for the first time. Some of the banks prefer to print the first time password on paper and then hand it over to the customer in person.
To enable banks to do this, OBDX has the “Print Password” function built out of the box. However, the base OBDX product will not provide an end-to-end solution since password printing is not something universal.
For the sake of this explanation, we are going to break up the process of Password Printing into 6 steps:
- Generate the password using a secure random number generation mechanism.
- Encrypt the password.
- Store the password in the Database.
- Retrieve the password for printing.
- Decrypt the password.
- Do the actual printing.
Steps 2 and 5 can be customized, but not mandatory.
Please refer to section 4.4. However, it is mandatory to implement Step 6. Here is how you can plug-in your implementation of printing the password:
- Write a custom class that will implement the interface com.ofss.digx.app.sms.user.printinformation.provider.IUserInformationPrintAdapter
- The interface defines a single method as shown below
- The DTO passed to the print() method will contain the password that is needed for printing.
- Also, add the following entry to the file Preferences.xml <Preference name="UserPrintConfig’" PreferencesProvider="com.ofss.digx.infra.config.impl.DBBasedPropertyProvider" parent="jdbcpreference" propertyFileName="select prop_id, prop_value from digx_fw_config_all_b where category_id = 'UserPrintConfig'" syncTimeInterval="36000000" />
- Run the following Database script Insert into DIGX_FW_CONFIG_ALL_B (PROP_ID, CATEGORY_ID, PROP_VALUE, FACTORY_SHIPPED_FLAG, PROP_COMMENTS, SUMMARY_TEXT, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATED_DATE, OBJECT_STATUS, OBJECT_VERSION_NUMBER) values ('USER_INFORMATION_PRINT_PROVIDER','UserPrintConfig','com.ofss.digx.app.sms.user.printinformation.provider.CustomUserInformationPrintAdapter','N',null,'Custom adapter for User Password Information Printing','ofssuser',sysdate,'ofssuser',sysdate,'A',1);
Configuring User Session Invalidation
From security point of view, OBDX provides the feature to invalidate user’s current active sessions i.e. user will be logged out automatically in either of below scenarios
- If user changes his/her password.
- If user is locked by admin.
- If channel access for the user is revoked by admin.
By default the behavior is disabled i.e. after changing the password or after admin locking the user or revoking the channel access, user session will not be invalidated i.e. user can continue with its present session.
As per business requirement Consulting/Implementation team can override this behavior by executing below steps:
- Run script : update digx_fw_config_all_b set prop_value = 'true' where prop_id = 'IS_SESSION_INVALIDATION_ENABLED';
- Restart server.
Once the default behavior of application is changed, UIUser Interface needs to be customized to provide provision to go on login screen from Change Password Screen instead of default behavior of going back to Dashboard. This can be achieved with below steps:
- Locate Change Password Resource file that resides at path channel\resources\nls\ change-password.js
- Replace gotoDashboard : “Go to dashboard” to gotoDashboard : “Click here to login again”