Correct handling of passwords after implementing SAP Single Sign-On

Passwords are seen as the key to our information and should, therefore, be selected and handled with care. They accompany us in everyday life and are often used when accessing the operating system or when logging on to company applications such as SAP.

For good reasons, securing access data is very important from an IT security perspective because credentials are seen as the primary gateway for most kinds of threads leading to compromised systems.

In their day-to-day work, users are faced with more and more accounts for different systems and applications. For each application, it is best to remember a secure and complex password and to renew it regularly.

This cannot work, overwhelms many users and has no advantages from an IT security perspective, this ball usually goes backward and weakens overall security.

Single Sign-On (SSO) has the potential to solve many of the problems associated with passwords. But still, there are lots of companies not using SSO at all, which is a bad idea. Others are still have passwords despite using SSO and consequently never deactivated the passwords for their Sap users. Possible, but also a bad idea, as this should only be the case for some exceptions.

This principle also applies in the SAP environment: “Avoid passwords whenever possible and use SSO”.

“Single Sign-On (SSO) is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. With one set of credentials, (single or multi-factor authentication) you can enable and disable user access to multiple systems, applications, and resources”

Complexity | Integration | Centralization

Meanwhile, SAP landscapes have become significantly more complex than one decade ago. They consist of a wide variety of different systems that interlink closely with existing IT components and extend into the cloud. Applications running within this hybrid SAP environments are made to be consumed from anywhere and on any device. And this requires authentication.

Due to its multi-system landscape and decentralized password management, the SAP landscape is an ideal environment for SSO, helping to significantly reduce the total number of passwords required for several systems and to eliminate password logons.

Using SSO outsources authentication to a central system that verifies your identity and based on that issues a security token. Once you got that you can access your various SAP applications. Such a central system can be secured much better than each SAP system itself. The access to the respective SAP system is then only possible using security tokens such as X.509 certificates, a Kerberos ticket or a SAML assertion or JWT. This meant that the user had to identify himself beforehand once, which under some circumstances may require the use of multi-factor-authentication.

The security tokens themselves are cryptographically protected and of course, do not contain any credentials such as passwords. With SSO gone are the days when users had to remember dozens of passwords for different systems or had to change them frequently. An additional advantage is the ability to quickly lock out certain users like when an employee leaves the company.

In the best-case scenario, having no access to the Active Directory (as your central system) also means that access to on-premise SAP applications and integrated cloud applications such as SAP Ariba or SuccessFactors is no longer possible.

Besides the efforts and costs related to password-reset-calls, there are also security issues. Nobody wants to be a victim of phishing emails. And nobody intentionally uses a very simple password so that hackers have a particularly easy game using a dictionary or brute-force attack.

Most users are familiar with the current regulations and recommendations for secure passwords yet using passwords still is a prone process. However, if the company does not provide an SSO solution, the secure handling of access data ultimately remains with the user, and yeah!

CORRECT HANDLING OF PASSWORDS AFTER IMPLEMENTING SSO FOR ALL SAP SYSTEMS AND APPLICATIONS

The goal of a complete SAP Single Sign-On implementation is to increase security by confidentiality, integrity, and authenticity. No unencrypted connections are allowed to that system (exceptions possible) and there are only a few accounts left having a password at all and permission for password-based access.

Unfortunately, this does not happen in many cases and so passwords continue to exist in the SAP systems and are forgotten soon. If they still exist and SNC+SSO is not enforced, users and adversaries can easily bypass security and (try) perform direct system logons. Password policies, therefore, remain active and regular password changes are also required. The transition to a password-free user can then be carried out automatically and planned by the SAP system over a certain period. Alternatively, users can be involved in the process and delete their password using a kind of self-service procedure.

If all users are enabled for SSO on all required SAP systems and there are no other reasons against it, the users’ passwords can be deactivated in this system. All applications on this system, consumed via the DIAG, RFC or HTTP protocols are taken into account and configured accordingly. In this case, it is recommended to configure the profile parameter login/password_change_for_SSO = 3 (the password is deactivated without a message). Users no longer see a password change screen. A positive side effect – if the passwords are deactivated, there are no password hashes in the database.

NO RULES WITHOUT EXCEPTIONS!

Even with the use of SAP Single Sign-On, you cannot avoid passwords at all. Basically, there are user accounts that still require a password like those exceptions for transport imports and other maintenance tasks or for interfaces used for system-to-system communication (S2S).

In addition to a few dialog users (exceptions), there are usually many service and system users. The security level for the test and development systems differs from the security level for production systems. Under no circumstances, it should be allowed to use the same password on the different SAP systems. All the more important is the correct technical and organizational handling of these user types & passwords and to make use of the most secure hash method possible in your SAP system.

The SAP systems should not generate backward compatible hash values (BCODE, PASSCODE). It is recommended to configure the systems only using Code Version H (PWDSALTESHASH). This is implemented using the profile parameter  login/password_downwards_compatibility = 0. 

Based on this parameter, the following hash encoding method is used in SAP NetWeaver as standard: RFC2307, algorithm = iSSHA-1, iterations = 1024, saltsize = 96

You can add additional security by using more recent hash methods such as SHA-256 and a 10 times higher number of iterations. This massively increases the resources and time required to calculate (attack) SAP password hash values using tools such as oclHashcat and the likes.

GOODBYE TO REGULAR PASSWORD CHANGES SAYS BSI

After implementing and enforcing SNC/TLS and SSO normally 98% of all users in the SAP system no longer have a password. Nevertheless, a proper password policy has to be implemented. This is especially important for those users who have to continue working with passwords (exceptions).

The German Federal Office for Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) is publishing the IT-Grundschutz Catalogues annually each February. It is a compendium that covers technical, organizational, infrastructural and personnel aspects and is to be seen as a systematic approach to information security (ISO/IEC 27001 compatible). Many of the recommendations and guidelines outlined there are influencing the SAP world as well.

In its current edition of the “BSI Grundschutz Compendium Feb 2020”, there is a section which is now advising against regular password changes. A forced regular change of passwords is therefore outdated. Unfortunately, the 2020 edition is not yet available in English.

Better to set a separate and secure password for each SAP system. This is perfectly fine and still best protects against so-called credential stuffing or password spraying and also “brute force” attacks. An increase in user awareness of the subject “passwords” can be supported by the use of SSO. The number of required passwords is reduced to a minimum, making IT systems easier to use again.

With over 800 pages, the BSI work is not an easy meal. It contains security requirements for SAP systems as well. Like in APP.4.2.A31 in that a securely configured single sign-on is recommended or APP.4.2.A18 in which it is advised to switch off any unsafe communication and enforce the use of SNC and TLS and thereby enables the use of various SSO methods.

So check them out and update your SAP password policies and authentication strategy to reflect the newest recommendations!

CONCLUSION

The use of single sign-on offers many advantages such as increased productivity and security and creates greater acceptance by end-users and system operators. If the risk of abuse in the SSO environment is classified as high, SSO is no longer considered sufficient for the risk classification. In these cases, multi-factor authentication can be used.

Different MFA methods in the form of hardware and software tokens are supported both in the environment of various identity providers and with the SAP on-premise and cloud solutions such as SAP SSO 3.0 and SAP IAS.

If an adversary gets in possession of access data, the gates are open for further attacks based on that credential pair or the password-schema. They will then try it for other accounts or systems as well. Thanks to AI & machine learning, there are very complex algorithms that already predict future passwords, the keyword is “Password-Guessing Machines”.

If the past has shown us one thing, it is that we cannot rely on the fact (or wish) our credentials on various IT systems are secured in the best possible way. Hence, it is best not to work with passwords at all. Use a well-secured SSO architecture whenever possible. Especially when working on cloud applications, no passwords should be used for authentication. Instead take advantage of SAML 2.0 and outsource the authentication to a central and trustworthy identity provider.

IN THIS CONTEXT, FINALLY, A FEW RULES:

• Use passwords only if there is no way to set up a more secure authentication method.
• Always use encrypted connections to your SAP systems (SNC+TLS).
• Enforce encryption and authentication with security tokens.
• Make sure the procedures and algorithms are state-of-the-art (e.g. Hashes!)
• Use a different and strong password for each system.
• Create long and complex passwords using a generator.
• Use a password manager (…and write down the master password on a piece of paper).
• Use two-factor authentication for critical systems or privileged accounts.
• Include your corporate authentication into your SAP security strategy

Have a peaceful day!

(Cross Posted Content | Original Source here)