| Oracle® Retail Predictive Application Server and Applications Security Guide Release 14.1.1 E61143-01 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server and Applications Security Guide Release 14.1.1 E61143-01 |
|
Previous |
Next |
This chapter discusses security for the RPAS Classic Client.
The RPAS Server handles the authentication for all users connecting via the Classic Client. The connection between the server and client does not time out and it is SSL protected, so the password is always encrypted when transmitted. Passwords are hashed using a configurable, de-optimized algorithm and stored in the user's private metadata database.
Users created via the batch-load functionality in usermgr will receive a temporary password that is applied to all users who are part of that batch load. This temporary password expires after the first time the user logs in. Any account that is not going to be claimed immediately should be locked by the administrator after user load.
Users can change their password at any time via the File->Change Password option. If they forget their password, the RPAS administrator can change their password either through the Edit User template or the usermgr utility. The users' password history prevents them from reusing a password within a certain time interval. However, when the password is changed via one of the administrator interfaces, the history is ignored. This allows RPAS administrators to reuse temporary passwords.
This section covers options concerning password security.
Using the Password Policy Measures Settings view, administrators can configure password complexity and settings in order to ensure the account security of users and other administrators. With this view, administrators can set the required password complexity, the number of allowable password attempts, the expiration time of a password, and the length of time a user is locked out of the system after failed password attempts.
Most companies have their own password policy, which the configurable parameters in the Password Administration Template should accommodate. If you need to create your own password policy, here are some guidelines to follow:
Password security is directly related to password complexity. Requiring lowercase, uppercase, symbolic and numeric characters help to prevent common-use passwords and reduce the effectiveness of dictionary attacks.
Increasing the minimum password length exponentially affects the number of attempts needed to derive a password. This is typically set to either six or eight, with eight being recommended for more secure environments.
Password reuse and history settings work in conjunction to reduce the amount of time that an unknowingly exposed password can be exploited. Typical settings for these fields are forcing customers to change their passwords every three to six months. The history threshold should be enough to ensure that the user must have at least 6-12 unique passwords. (Example: If users must change password every three months, the history threshold should be set to 18-36 months).
The severity of the security policy should be related to the security of the environment and the data under the application's control. The end-user experience should also be taken into consideration when designing the policy. A password policy that is so strict that users are going to write their passwords down and keep them on their desk will do more harm than good.
These parameters can be set in the Password Administration Policy Workbook.
More information can be found in Chapter 6: System Administration in the RPAS Administration Guide for the Classic Client.
Accounts may be configured to automatically lock out after a certain number of failed logon attempts. A domain administrator can configure the number of failed logon attempts and the duration of the lockout using the Password Policy Administration workbook.
Accounts may be marked as requiring the user to change the password. When this is set, users are prompted to change their password the next time they log in. Users cannot proceed using the RPAS client unless they successfully change their password. This is useful for new accounts that are created with a stock password. The domain administrator can set or clear this setting using the User Management utility or the Edit User workbook.
Password expiration may be enabled for the domain. The domain administrator may set the number of days after which passwords expire. After this time passes, users are prompted to change their password the next time they log on. Users cannot proceed using the RPAS client unless they successfully change their password.
A password reuse time can be set for the domain. This is often used in combination with password expiration to ensure that users do not change their password to a recently used password after the current one expires. The domain administrator may set the minimum number of days that may pass before users can reuse a previous password using the Password Policy Administration workbook.
In a global domain, passwords and the password policy are centralized in the master domain. The administration templates are not available in the local domains, and any attempt to add users to a local domain on the back end will result in an error. These settings are specific to the application domain, and cannot be shared with other domains.
The Classic Client has no intrinsic authorization process. However, connections made from the Classic Client to instances of the RPAS Server must successfully complete an authorization process before the client may interact with that server instance. Information on RPAS Server authorization can be found in the Securing the RPAS Server section.
RPAS Classic Client can be started with a command line option -loglevel {level} to control the logging granularity. The log file for the client is created under the same directory where the executable "Foundation.exe" resides, and named "Client.log". This log level is also passed to the RPAS Server and controls the logging granularity of the session on the server side. The RPAS Server log level cannot be set below its minimum logging threshold in this manner (See RPAS Server Auditing for details).
