Attention Security Administrators! New password rules are on their way!

[Former Member]

Gone are the times where passwords had to be 8 characters or less and only UPPER CASE. This weblog post describes the new password rules for SAP NetWeaver 2004s ABAP stacks and SAP ERP '05.  Password rules are used to enforce the use of "good passwords",  that is:  not easy to guess passwords. Usually a password rule comprises password length, characters that have to be used (letters, numbers, special characters etc), rejection of further logon attempts after a configurable amount of unsuccessful logons to prevent brute-force-attacks where a script is executed using a user ID and a password generator that’ll try a whole dictionary, etc...  So what is the news? What will the new password rules and enhancements allow?  Passwords can be up to 40 characters long now, they support case-sensitivity (which means that you can use upper and lower case characters), they use a SHA1 algorithm for hashing instead of MD5 and allow for the following rules:  You can configure a time frame after which an unused password will get rejected. What is an unused password? After your administrator rolls out a new password to a user (either because the user was newly created or her password had to be reset) that is what we call an initial password or password reset. When the user logs on with this initial password, the user is forced to change it. If this never happens, because the user never logs on and changes his or her password, we call this an unused password. The following profile parameter (maintainable via transactions RZ10/RZ11) defines the time frame after which an unused password will become invalid and thus rejects any logon attempts thereafter. The parameter is: login/password_max_idle_initial. The maintainable values are from 0 – 24,000 days. Default is 0.  You can also configure passwords that are productive to become invalid. That is, the user has logged on and changed the initial password or password reset, but never logged on again or kept the user ID unused for too long time a period of time. You configure this behavior with the following profile parameter: login/password_max_idle_productive. The maintainable values again are from 0 – 24,000 days. Default is 0.  The profile parameters login/min_password_lowercase and login/min_password_uppercase provide the definition of the number of required upper and/or lower case characters. You can choose any value from 0 – 40, the default value is 0. With a setting of 0 any enforcement is currently deactivated.  In lower releases users could only change their passwords once a day. You can now configure this waiting period to a longer time via the following profile parameter login/password_change_waittime. The range is from 1 – 1,000 days with the default being 1, which represents the former system behavior.  The password history is configurable now. In lower releases this was a static list of the last 5 used passwords, that users were not allowed to use. Via the following profile parameter you can configure now how many of the last used passwords you would like to exclude: login/password_history_size. So you could configure this to be stricter than 5, let’s say 10, or make it less strict, let’s say 3. We would recommend though, that you do not use any of the profile parameters to make password rules easier, but stricter for your own system security. You can choose any value from 1 – 100. The default is 5, as was the system behavior before.  Now how do you enforce those new password rules? Any new users created after you changed your password rule, will have to stick to the new rules. But what about your large and already live user base that is flying along with passwords created according to outdated password rules? Do you have to wait until their next scheduled password change which could be up to 6 months from now depending on your policies? No you do not have to wait that long at all! There is a new profile parameter that you can configure to check all passwords at user logon for whether they abide to the new rules or not and thus have them change their password according to the new rules. To configure this you use the profile parameter login/password_compliance_to_current_policy. If you set this profile parameter to 1 the system will check whether the password of a user complies with the new rules or not. So most likely at the next logon your user will be prompted to change his or her password according to the new rules. 0 means that this check is not enforced. So if you want your users to stick to the new rules at their next logon you had better change this profile parameter to 1.  How should you configure your password rules anyway? Try to make the user use a specific amount of upper case and lower case letters as well as special letters and numbers. This insures that users cannot come up with passwords that can be guessed easily. I confess, that I was guilty of this myself once and chose 1GERLI as a password. When it was time to change this password, guess which one I chose? I am a 100% sure that you guessed correctly. I chose 2GERLI. And then 3GERLI, thus nicely abiding to the password rules enforcing me to use at least one number, at least 6 characters and to have my password not use one of my last 5 passwords from the then static password history. Wasn’t a good idea though. In addition to your password rules, bear in mind that you can maintain a table (USR40) with words or word abbreviations that are forbidden for passwords. The USR40 table allows now for case sensitivity as well. You can type in whole words, that are forbidden. This is like a negative list. You can also use the wildcards * or ? at the end of a pattern. For instance Gerli* would forbid to use any password that starts with Gerli. When you force users to strenghten password rules, encourage them to use mnemonic aids. For example you could enforce a password rule with upper and lower case characters and numbers. So you could encourage your end-users to remember the password with a phrase: Hi2564nmotCc. Hawaii is 2564 nautical miles off the Californian coast. (Forgive me but my geography is not that excellent. So I am not sure if the statement is correct or not.)  And what about downward/upward incompatibilities with those new password rules? What about password resets in a CUA (Central User Administration) landscape, where I have lower and higher life forms as regards to releases? What about communication users created on a system with advanced password rules, but used for RFC logons to a system in a lower release? Well, there is another profile parameter! Who would have guessed that? login/password_downwards_compatibility allows to handle downward incompatibility of the just discussed new password rules. The settings that you can make here range in discrete steps from 0 to 5.   The setting 0 means that you only allow the creation of one new hash value for passwords according to the new password rules (up to 40 charcters, SHA1 as algorithm, case sensitive, etc). This setting is not downward compatible. What does this mean and what is the problem? Imagine that you are configuring an ALE communication from an R/3 4.6c system (which is a system on lower releases that does not support these new password rules) to an ERP 2005 system. The ERP 2005 system is configured to use passwords of length 12. You create a communication user on the ERP 2005 system now that has a 12 character long password. But how do you enter that communication user in the RFC destination on the R/3 4.6c system. The RFC destination only allows for input of 8 characters in the password field! This is where the settings 2 – 5 will help you. And we will discuss them in detail down below.  So coming back to setting 0, when do you want to use setting 0 then? You only want to use this setting if you live on higher life forms as regards to your release levels and/or if you do not have any ALE communications where you would need passwords for communication users on lower releases or dialog users in a CUA landscape with central and child systems in different releases as regards to the password rules.  But what can you do when you have systems in your ALE landscapes that do not support these new password rules? Again that is where setting 2 – 5 can be used. Let us look at the details.  Setting 1 is needed in a CUA landscape where your central system is on the higher release with the new password rules and some of the child systems are on lower releases.  Setting 1 will enforce that 2 hash values for the password are created. One hash is for lower releases, abiding to the old password rules (no case-sensitivity, 8 characters, etc) and one hash is for higher releases that allows all above mentioned password enhancements. To create the old password hash the system will shorten the password to 8 digits and convert any characters into upper cases, as would be done in lower releases. The hash value representing the old password rule is not used for authentication within the CUA central, but used to provision password resets or sending initial passwords to a CUA child system. The hash value representing the new password rules is used for authentication within the CUA central system.  The setting 2 means that your system will create 2 hash values according to old and new password rules. However, it will only allow the authentication with the hash value representing the new password rules. You will find in the log files (SM51) that the old password hash value was checked additionally and the protocol will inform you that under old password rules this password would have been accepted. The authentication with such a password will be denied though. You should use this setting if you want to find out which systems/users will have incompatibility problems. Let us assume that you have tons of RFC connections that should have been cleared up a long time ago and you are not even sure, which of these are used on a regular basis. Setting 2 is a nice way of finding out. Any RFC communication user (Or worse dialog user, that you should not have maintained in the RFC communication to begin with!) that is used from a system with a lower release communicating to your system with the new password rules, will be denied at logon, but you will know from the log files that this is due to password incompatibility. After a month or 2 (I have a hunch that you have the results after a week already) you should have a pretty decent overview about which of your RFC communications are used and where you accidentally used a dialog user. Also bear in mind that this setting will catch all hard coded RFC users in custom-developed programs, that should not have been hard coded in these reports anyway. I hope your findings will not be too troublesome.   Alright, let us assume that you deleted all unnecessary RFC communications and that you changed all dialog users to communication users in them. Let us further assume you shot all programmers in the foot that hard coded RFC users in their coding and made sure that they used SM59 to properly maintain an RFC communication. Unfortunately, due to setting 2 they still cannot log on to your system with the new password rules. This is where setting 3 helps. This setting means that you do as in setting 2, but now you allow the logon with a password hash according to old password rules (password gets shortened after 8 digits and gets converted into upper case.). If your system supports the new password rules you will accept a logon to this system with both old and new password rules.  Setting 4 is like setting 3 but without any protocol logs that inform you when an old password hash was used for authentication. This is a setting that you should use, when you only have a few RFC connections that are well maintained with communication users and you can forget about any logs or protocols. Happy Trusting!  Setting 5 is where you only create passwords according to the old rules. That is all passwords can only be 8 characters long and transferred to upper case. This might be a setting for those customers that know for a fact that they won’t be upgrading any of their current systems in their landscape soon and that the system which allows the new password rules will be the only system on this high release level for a long time. Well then why bother with all those settings and new password possibilities if 99.9% of your systems don’t allow it anyway.  So Settings 1 – 5 only make sense for systems where you have ALE communications either via RFC or for a CUA or for a Solution Manager etc and you could potentially run into password incompatibilities for those system-to-system communications. If you have many a systems, but you do not have any ALE communications whatsoever between them (makes one wonder though!), of course you are free to configure the new password rules in the highest releases and set the above mentioned profile parameter to 0 there.  To sum it up here is a table that lists all settings for the profile parameter login/password_downwards_compatibility: Setting               Result 0     Only new password rules 1     2 hash values, one hash for CUA Central with new rules, second hash gets provisioned to systems on lower release according to old rules 2     2 hash values, only the newer hash will be accepted, log 3     2 hash values, both will be accepted, log 4     Like 3 but no log 5     Only old password rules  For information on these new password rules you can check out SAP note 862989.   We hope that you enjoy using the new profile parameters and enhancements to password rules.  Let it not end as in the following excerpt of a communication between a Security Developer and a Security Product Manager that took place a couple of years ago. Security Developer: “I have a good password. I always use it. My password is secret.” Security Product Manager: “What? Your password is secret! I have a better password. My password is not secret!” Security Developer: “With or without underscore?” Security Product Manager: “Without underscore of course! And I’ll leave out the o. We only allow for 8 characters length with passwords! You should know this!” Security Developer smirks knowingly.