2.2 Broken Authentication and Session Management
In Oracle Banking Trade application session interval will be validated against the session interval stored in the configurable file fcubs.properties file. Validations are added to check the maximum time limit for the inactive session from being expired. Java API method javax.servlet.http.HTTPSession will set the max time out period for the session.
A maximum limit is imposed on the value passed to set the maximum limit of session interval. The maximum limit is a positive practical value. This validation is required to prevent long running sessions that can be actively targeted.
The default value for session time out is 30 minutes and it is configurable in properties file.
The session used for login authentication will be invalidated (destroyed) and a new session will be created once the user logged-in successfully to the application. And the new session will be used to store the required variables.
A session attribute IsAuthenticated set to “Y” on successful login to the application. A new random token (Cross-site request forgery) also generates and same is available in the session attribute.
The entire subsequent request within the session will be having the Authenticated and Cross-site request forgery tokens. Every request send to the application from the browser is validated against the IsAuthenticated attribute and Cross-site request forgery token.
A hidden form is used to submit the logout request to the server, with the response resulting in a 302 redirect instead of client initiated redirect to the login page.
Session get expire once user log off from application or if idle for its maximum limit.
Cryptography used
PCI council defines Strong Cryptography as:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum doublelength keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).
Encryption algorithm: The application leverages AES encryption algorithm to store sensitive information into properties file. This algorithm uses 256 bit secret key for encryption and decryption which would be stored at property file.
Hashing algorithm: Oracle Banking Trade Finance leverages SHA-512 hashing algorithm for user password authentication. This algorithm generates a password digest for the user password by using the SALT (Random number generated using SHA1PRNG algorithm) and the iteration number available in the property file.
Session storage
Oracle Banking Trade Finance application does not store Http Session objects.
A unique sequence number generates and stored in current user table for the purpose of mapping server-side sessions with the entries in the current user table.
During session expiry (triggered by the container), the session listener provides the application with the sequence number of the session. The application makes checks as to whether the entry in current user table contains the same sequence number. Only in such a case should the entry be deleted.
When authentication of credentials (involving an incorrect user ID) is unsuccessful, the user id should not be logged in the audit logs (database table). The following possible scenarios will be accounted for:
Session logging
Unsuccessful attempt to login is stored in the database with terminal’s ip address and timestamp. Invalid and expired session IDs submitted to the application are categorized as authentication failures and the same are logged in the database table.