This excerpt comes from Dr. Juergen Schneider's article, 'Lessons for Establishing Rock-Solid Authentication and...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Single Sign-On Practices' in the July/August 2001 issue of SAP Professional Journal http://www.sappro.com).
There are several ways a user like our friend Sally Smith can provide her SAP user ID and password to an SAP system.
- She can type her SAP user ID and password information into the tried-and-true SAP GUI for Windows.
- She can use an HTML logon page that is made available to her, thanks to the SAP Internet Transaction Server (ITS) in her Web browser.
- In the SAP Web Application Server, Sally can be prompted for her SAP user ID and password directly via the HTTP protocol, which is called Basic Authentication in Web terminology. When a Web server asks for Basic Authentication, the Web browser displays its standard user ID and password pop-up. The user ID and password information that Sally types in is transferred directly to the SAP Web Application Server in the HTTP Basic Authentication protocol header.
In all three cases, Sally's SAP user ID and password information is sent to the SAP system and compared against the value stored in Sally's user master record in the SAP database (table USR02)*. If the logon information is verfied, the system grants access. If not, access is denied. (Note that when system administrators assign new passwords to users, the new password is marked as initial. Users have to change their initial passwords at first logon.)
There are a number of password protection options (listed below) you can use to bolster the security of this initial authentication process. It's the manner in which you exercise these options that defines the password policies for the SAP systems used in your organization**:
- The login/min_password_lng parameter -- To make passwords safe from guessing, you can enforce a minimum password length of three to eight characters. For a productive system, we recommend a minimum length of at least six characters.
- Prohibiting certain passwords in table USR40 -- The SAP system won't permit the use of certain passwords, nor will it allow a password to contain three identical characters in sequence. Via table USR40, you can also prohibit the use of certain passwords.*** You might, for example, want to prohibit the use of simple passwords that you know are apt to be widely used among your users. These types of passwords often include the name of your company, weekdays, months or seasons, person names, or simply things like 'pass1,' 'pass2,' 'init,' 'initial', etc.
- The login/fails_to_session_end parameter -- To prevent so-called 'dictionary attacks,' where thousands of words from a given dictionary and variations are tried as passwords, the SAP system aborts a user's logon session after a certain number of invalid logon attempts. The usual default is to allow three attempts to provide the correct password before the logon screen disappears and the user has to start a new session.
- The login/fails_to_user_lock parameter -- In addition, a counter of consecutive invalid logon attempts is kept per user and the user account is locked in the SAP database after a certain limit is reached. For a productive SAP system, you can choose to reduce the default number of 12 invalid logon attemps in a row, before a user account is locked. The user lock can be automatically removed per default at midnight, or you can configure the system so that the account is locked until the system administrator removes it. In a productive SAP system, you may want to have account locks removed only by your system administrator.
- The login/password_expiration_time parameter -- To reduce the risk that passwords get compromised or that compromised passwords can be used for a long period of time, passwords do expire. Once a password has expired, the user has to change it during the next logon. The SAP system stores the hash values of each user's last five passwords so that users can't reuse those either. In a productive SAP system, a typical value for password expiration is four to eight weeks.
TIP: To achieve top-grade security, behavioral practices must be in lock step with your technical password policies. Hashing, minimum password lengths, password expiration policies and so on will all be in vain if users jot down their passwords and then paste them to their monitors. So don't put users in a position where they feel they have to resort to methods like these. Don't saddle them with overly complicated, constantly changing passwords and/or lots of them. Try to establish a single sign-on instead, so that one password logon to a central system is sufficient to access applications in other systems as well. Another thing to be mindful of is the all-too-common practice among users of disclosing their passwords to colleagues or sharing them with an assistant. Obviously, you want to discourage this and similar practices.
*In the SAP database, only hash values of the user ID and password information are stored using a slighly modified MD5 hash algorithm. The password itself isn't stored and thus can't be stolen from the database. As part of the logon process, the SAP user ID and password provided by the user are hashed and the hash value is compared against the value stored in the BCODE field of table USR02.
**You'll find the documentation and default values for all mentioned SAP profile paramters using SAP transaction RZ11 in your SAP system. See also the 'SAP Security Guide,' which provides additional information and recommendations, at http://service.sap.com/securityguide.
***Additional password rules enforcing combinations of letters, digits and special symbols are currently available in the SAP Web Application Server.
To subscribe to SAP Professional Journal, visit its Web site at http://www.sappro.com.