Sybase Users

1. Enforce account password complexity and lockout.

   Enforce the use of strong passwords for Sybase accounts. ASE 12.x has a number of excellent features for ensuring user password security.

   You can specify that an account should be locked after some maximum number of failed login attempts.

   To set the limit globally:

    sp_configure "maximum failed logins", 5 

   To set the limit for a user:

    sp_addlogin test, "foobar432", maxfailedlogins = 2 

   To set the limit for a role:

    create role test_role with passwd "test432", max failed_logins 5 

   You can use sp_modifylogin to set the limit for a user after an account has been created, or "alter role" to set the limit for an existing role.

   You can ensure that all (new) passwords have at least one digit, using the statement

    sp_configure "check password for digit", 1 

   You can specify a minimum password length globally, using the statement

    sp_configure "minimum password length", 4 

   Or you can set the length for a specific user like this:

    sp_modifylogin "test", @option="min passwd length", @value="9" 

2. Remove privileges from the default sa account.

   You might want to remove privileges from the default sa account, and instead set up a number of separate, role-based database administration accounts (that have either the sa_role or sso_role). The reason for this is that attackers are generally aware of the existence of the sa account and will specifically target it. Attackers may not have access to a mechanism that allows them to retrieve all users' usernames, so this can be a helpful lockdown step.

3. Use (at least) one user per web application.

   If you have multiple web applications connecting to your Sybase server and executing queries, use a separate user for each application. In fact, if you can possibly get away with it, separate out the "roles" required by the web application and use a different user for each role in each applicationso for example, the part of the application that displays only data should have only select permissions, the part that updates the data should have only update permissions, and so on. This improves security in a number of ways:

   • If a specific part of an application is vulnerable to SQL injection, the only actions that can be carried out by the attacker are the actions corresponding to that specific part of the application. For example, the attacker might be able to retrieve a specific subset of the data in the database but not change it.

   • If the password for a specific part of an application is compromised, the attacker gains access only to a small portion of the available data.

   • If you use the same account for all of your web applications, your data is only as secure as your least secure web application.

4. Do not give users unnecessary privileges.

   In Sybase this advice generally affects table and other object permissions, role membership, and possibly the decision to install certain additional components , like enabling Java support or access to the filesystem via CIS. Broadly speaking, the less an account can do, the better protected your data is.