Siebel Security Guide > Security Adapter Authentication >

About Password Hashing

This topic describes the password hashing options available with Siebel Business Applications. User passwords and database credentials passwords can be hashed for greater security. Hashing passwords is recommended.

Unlike encryption that involves two-way algorithms (encryption and decryption), hashing uses a one-way algorithm. A clear-text version of a password is hashed using a Siebel utility, then stored in the database or in an external directory such as LDAP or ADSI. During login, a clear-text version of a password is provided (such as by a user), which is then hashed and compared to the stored hashed password.

The password hashing options available with Siebel Business Applications are as follows:

• User password hashing. When you are using security adapter authentication (including database, LDAP or ADSI, or custom security adapters), user passwords can be hashed.

  A hashed password is maintained for each user, while the user logs in with an unhashed (clear-text) version of the password. This password is hashed during login.

  Password hashing is a critical tool for preventing unauthorized users from bypassing Siebel Business Applications and logging directly into the Siebel database using an RDBMS tool such as SQL*Plus. It also prevents passwords intercepted over the network from being used to access the applications, because an intercepted hashed password will itself be hashed when login is attempted, leading to a failed login.

• Adding salt values to user passwords. In the current release, if you are using an LDAP, ADSI, or a custom security adapter you can choose to prefix a user's password with a salt value (a random string) before the password is hashed. The result of the hash function and the salt value are then stored in the security adapter directory. During authentication, the user password supplied is prefixed with the stored salt value and hashing is applied. If this computed value matches the hash value in the directory, then the user is authenticated.

  NOTE:  Adding salt values to user passwords is not supported if you are using Web Single Sign-On or database authentication. The SaltUserPwd parameter is ignored if the SingleSignOn parameter is set to TRUE.

  Adding salt values to user passwords provides protection against dictionary attacks on the hashed passwords. By making passwords longer and more random, salt values lessen the likelihood that the hashed passwords can be deciphered. For additional information on the SaltUserPwd parameter, see Parameters for LDAP or ADSI Authentication.

• Database credentials password hashing. When you are using security adapter authentication other than database authentication (LDAP, ADSI, or custom security adapters), or if you are using Web SSO authentication, database credentials passwords can be hashed.

  A hashed password for a database account is maintained in the database, while an unhashed (clear-text) version of the password is stored in the external directory. This password is hashed and compared during database login.

  Credentials password hashing prevents users from being able to log into the Siebel database directly using a password obtained through unauthorized access to the external directory because the unhashed password in the directory will not match the hashed version stored in the database.

• Password hashing utility. Siebel Business Applications provide a password hashing utility called hashpwd.exe which uses the RSA SHA-1 hashing algorithm by default. For existing customers, the Siebel proprietary hashing algorithm (the mangle algorithm) is also available as an option for the hashpwd.exe utility.

  NOTE:  New customers are required to use RSA-SHA1, and existing customers are strongly recommended to migrate to RSA-SHA1 promptly.

For information about managing encrypted passwords in the eapps.cfg file, see Encrypted Passwords in the eapps.cfg File. The password encryption mechanism described there is unrelated to the password hashing mechanism described in this topic.

Login Scenario for Password Hashing

This topic describes the login process for a Siebel application user when password hashing has been implemented. A user is logged into the Siebel application by the following process:

1. The user logs in with user credentials that include the unhashed password.
2. The Application Object Manager receives the user credentials, and passes them to the authentication manager.
3. If user password salting is enabled, then the authentication manager retrieves the salt value associated with the user password from the LDAP, ADSI, or custom security adapter directory and prefixes it to the user provided password.
4. The authentication manager hashes the password, according to the configuration of the security adapter.
   • In a database authentication environment:
     • The authentication manager passes the user credentials (user ID and hashed password) to the database security adapter.
     • The database security adapter verifies that the hashed password matches the hashed password stored in the database for the user. It validates the credential by trying to connect to the database server. The security adapter confirms to the Application Object Manager, through the authentication manager, that the credentials are valid.
   • In an LDAP or ADSI authentication environment:
     • The authentication manager passes the user credentials, including the hashed password, to the LDAP or ADSI security adapter.
     • The LDAP or ADSI security adapter verifies that the hashed password matches the hashed password stored in the directory for the user, and then returns the database account and the Siebel user ID to the Application Object Manager through the authentication manager.
5. The Application Object Manager initiates a Siebel application session for the user.

Related Topics

Process of Configuring User and Credentials Password Hashing

Running the Password Hashing Utility