Implementing strong security procedures

Standards are great. You know where you are when you have standards. Security standards are even better. Not only do you know where you are with security standards, but they also help you to keep your data safe too! However, somebody is always left to implement those standards, and when it comes to implementing your company’s password policy on a HANA database, that job often comes down to me. If you are in the unfortunate state that the job has fallen to you, then read on.

Before we start on hardening the password policy of the HANA, consider if you actually need to. If all of your users are authenticating using kerberos or SAML, then the HANA database isn’t responsible for the password policy. If this is the case, then ensure that your password policy is applied to directory service.

Let’s now turn our attention to what a password policy may entail. Here’s a list of common password requirements:

• Minimum password length
• Password complexity
• Password lifetime
• Password reuse
• Force new users to change the initial password

HANA has configurable settings for all of the above and more. Now let’s imagine we have the following policy.

• Passwords must be at least 10 characters long
• Passwords must contain a lowercase, uppercase, numeric and special character
• Initial passwords must be changed on the first login
• Passwords must be changed every 30 days
• The previous 7 passwords may not be reused
• Accounts will be locked following 5 incorrect password attempts
• Each of the above can be tackled within HANA’s configuration. As always, it is better to configure HANA using SQL
• statements as these are easier to audit and maintain.

Another important point is that the systemdb store’s password configuration details in nameserver.ini, whereas tenant databases store them in indexserver.ini. The examples in the blog are for tenant databases. To use the examples on a systemdb, simply replace indexserver.ini with nameserver.ini.

Minimum Password length

ALTER SYSTEM ALTER CONFIGURATION(‘indexserver.ini’, ‘SYSTEM’) SET (‘password policy’,’minimal_password_length’) = ’10’ WITH RECONFIGURE;

The minimal_password_length parameter is used to set the minimum number of characters a password can be.

Password complexity

ALTER SYSTEM ALTER CONFIGURATION(‘nameserver.ini’, ‘SYSTEM’) SET (‘password policy’,’password_layout’) = ‘aA1?’ WITH RECONFIGURE;

This one may not be immediately clear. The value to the key ‘password_layout’ describes what types of characters MUST be present in the password. For example, if the value were ‘a’, this means all passwords must contain at least one lowercase alphabet character, therefore the password ‘PASS123!!!’ would not be allowed. The value ‘aA’ means that at least one lowercase and uppercase character would need to be present in the password, and so on. What is also interesting is that the order of the characters isn’t important. In addition, the characters values are not important either. Therefore, the system interprets ‘aA1’ the same as ‘9fW’ as the same thing.

Password Change Required on First Logon

ALTER SYSTEM ALTER CONFIGURATION(‘indexserver.ini’, ‘SYSTEM’) SET (‘password policy’,’force_first_password_change’) = ‘ture’ WITH RECONFIGURE;

Setting ‘force_first_password_change’ to true forces the user to change their initial password on their first login.

Maximum Password Lifetime

ALTER SYSTEM ALTER CONFIGURATION(‘indexserver.ini’, ‘SYSTEM’) SET (‘password policy’,’maximum_password_lifetime’) = ’30’ WITH RECONFIGURE;

The key ‘maximum_password_lifetime’ sets the maximum age of the password is days. The user would be forced to change their password every 30 days.

Number of Last Used Passwords That Cannot Be Reused

ALTER SYSTEM ALTER CONFIGURATION(‘indexserver.ini’, ‘SYSTEM’) SET (‘password policy’,’last_used_passwords’) = ‘7’ WITH RECONFIGURE;

To ensure that passwords are not be too frequently reused, the parameter ‘last_used_passwords’ can be used to force users to choose new passwords. The value must be a positive integer. Setting the value to 0 allows passwords to be reused.

Number of Allowed Failed Login Attempts

ALTER SYSTEM ALTER CONFIGURATION(‘indexserver.ini’, ‘SYSTEM’) SET (‘password policy’,’maximum_invalid_connect_attempts’) = ‘5’ WITH RECONFIGURE;

The key ‘maximum_invalid_connect_attempts’ controls how many unsuccessful login attempts will trigger the user account being locked. The value needs to be a positive integer. By default, the account is locked for 24 hours and then unlocked again. If required, you can set the period of time the user will be locked for with the key password_lock_time, the value to should be a positive integer representing the number of minutes the account should be locked for.

Other considerations HANA offers even more options for password security, check SAP documentation for full details.

Password blacklists

In addition to rules that govern password length and complexity, it is also possible to blacklist certain passwords or strings. This can be used to disallow passwords that may be easy to guess. For example, many people use names within passwords. The password blacklist can prevent a user from using simple names within the password.

In HANA, passwords are blacklisted by adding them the table “_SYS_SECURITY”.”_SYS_PASSWORD_BLACKLIST”. This table has three columns:

To add a password to the blacklist an authorised user can simply insert a new record. For example, to blacklist the string ‘brian’ anywhere in the password regardless of the case, the following statement can be executed.

INSERT INTO “_SYS_SECURITY”.”_SYS_PASSWORD_BLACKLIST” VALUES (‘brian’, ‘TRUE’, ‘TRUE’);

If you have a large list of passwords you want to blacklist then its a lot quicker to prepare a single file containing all the individual SQL statements. Also, if using hdbsql, it is also quicker to set autocommit off and commit all the statements together at the end. I did try iterating over passwords one at a time in a shell script, unfortunately, this meant making and tearing down a SQL connection for each statement and took much longer.

If you’d like to find out how you could benefit from a further understanding of SAP HANA security, get in touch with Centiq for a chat.

Conclusion

Out of the box, HANA’s password policy is weak. If HANA is used to authenticate users, then some time should be spent to implement a strong password policy. For maximum portability, create the policy using the appropriate SQL statements rather than using GUI tools.

Creating a policy is usually an easy step. Deploying the policy across the HANA landscape, including all system and tenant databases across all environments is not as easy. Ensuring that the systems remain compliant over time is even more taxing.

Centiq specialises in deploying, managing and maintaining HANA systems for many customers with a strong focus and automation and compliance. If you’d like to find out how you could benefit from our expertise in SAP HANA, get in touch with Centiq for a chat.