How to Create a Password to Make Your SAP System Secure?

An old topic, as old as a worn-out jacket after two hundred security meetings. A familiar topic, as familiar as the most popular password on the web (123456(?)). A topic already as stretched as... a thin layer of butter on a large slice of bread... However, it returns like a boomerang and not because it is popular and well-liked, but because it is important and critical to security.

How do we most often create passwords?

Imagine a scenario where SAP kernel settings for password parameters are the default.

The user enters his new password: a.
The message reads:  'The password is not long enough (minimum length: 6 characters).'

The user enters another password: aaaaaa.
Another message resounds: 'The first three characters of the password must be different from each other.'

The user replied: ababab.

Finally!

Both the user is satisfied because the system has stopped making his life difficult, and the system is "satisfied."
The question now arises (and if it doesn't arise, it should):

Is it enough for us, as system administrators, to have this kind of security?

Length matters

What is there to write. The longer the password, the better. Nevertheless, this rule is deliberately broken or simply ignored, as the user downplays the use of long passwords. It's supposed to be short, quick and to the point.
What can be done to "motivate" the user to use longer passwords, but on the other hand not "torment" him with the monotony of typing 40 characters?
Change the default value of the parameter 'login/min_password_lng'.
What value to choose? At least 12 characters.
The parameter allows a range of 3 to 40 characters. In extreme cases from 0 to 8 characters in combination with another parameter.
But remember, the longer the password, the more secure it is.

The power of the password

As it appeared later in the text, we have no doubt that a long password is not everything.
The user enters a new password, where this time he must "paste" a minimum of 12 characters: ababababab.
Looking at the new password, we find that fortunately our user is a fictional character and any resemblance with real users is coincidental.

What can we as administrators do about it?

We have another three parameters available:

login/min_password_digits

login/min_password_letters

login/min_password_specials

The first of the parameters defines for us the minimum number of digits (digits from 0 to 9) that the user must use when entering a new password. It can be up to 40, but in combination with the other two parameters the maximum is 36 digits.

The second parameter forces you to enter a minimum number of letters, again up to 40 characters (A to Z; a to z). That leaves special characters. After all, what's a strong password without a semicolon or parenthesis 😉 But to the point, we have something to show off using the available special characters, which will not be letters and numbers:

!”@ $%&/()=?’`*+~#-_.,;:{[]}\|

We have sewn up a solid set of characters to help secure the system. After all, the password: il1k3indianaj0nes;) is already really something more difficult to break.

Password quality

How about adding to the stove and raising the quality of passwords? Can it be done? It can be done!

With help come the additions of two parameters whose names indicate at a glance what the variety is all about:

login/min_password_lowercase

login/min_password_uppercase

The first parameter is responsible for the minimum number of lowercase letters in the password.
The latter for the minimum number of capital letters in a password.

Now it's just magic! A satisfied user enters the password under the new rules: A9#CgeGG8ea].

Administrators happy. Only... how to remember it...?

Is there anything else we can do?

Yes. It's worth considering additional safety-enhancing parameters that support those listed above.

Certainly, administrators would like to see the changes take effect if not immediately, then just a tad later.

Parameter 'login/password_compliance_to_current_policy' is important in the context of the above, as it forces a password change against the new policy immediately after logging in.
Setting the parameter with a value equal to 1 means that a check of the user's password against the current password security policy will take place. If at least one of the parameters is not met, a password change will be forced.

In order to easily remember passwords, many users use their own templates. When it comes time to change the password they then substitute one or two characters. This means that the core, or a large "chunk" of the password remains unchanged.

In order to make such activities more difficult and keep the complexity of passwords high, we can use the parameter 'login/min_password_diff'. The value of the parameter (from 1 to 40) indicates how many characters in the new password relative to the old one must be changed.

A related issue to the above is that the user should not use the same passwords too often. Such a feature is guaranteed by the parameter 'login/password_history_size'. It stores from 1 to the last 100 passwords used by the user. If we set this parameter to 5, it means that five cycles must pass before the user can use password No. 1 again.

Recommendation

Implement. Do not leave the door open to anyone who just wants to enter the system. Keep in mind that testing should be done before implementing a solution, especially if your system connects to systems with lower versions.
Who would like to end up with a blocked production system? Hand in hand.

And most importantly: Users are not allowed to write passwords on pieces of paper and stick them to monitors, carry them in a computer bag or leave them on a desk. After all, it's like scratching out/carving/rubbing the PIN to the payment card on the ATM we use. Such a user should be admonished.