authorized or unauthorized), until we accurately recreate those users and privileges as they existed previously. Add to this consideration that certain components, such as user and privileges information, is stored in certain internal databases and tables that vary among DBMSs, so unless we are certain which of those internal databases and tables are necessary for func- tionality, we may wish to consider a full DBMS backup of all databases and routines.
While a full DBMS backup can be a reliable solution for availability, for DBMSs with a lot of content, the file size of a full DBMS backup may be large.
If file size is a consideration, we may wish to create a smaller backup of only a specific database, a small set of databases, or only certain tables. We may also wish to use this approach if we will share a backup file with another party that should only have access to specific databases or tables. That way we can include only those databases or tables in the backup and not risk confidential- ity by sharing a complete DBMS backup that happens to include content the other party is unauthorized to access. We could even employ a backup solu- tion that uses the best of both approaches, such as a complete DBMS backup, say, every day, and of specific databases or tables more frequently, such as every hour. This may be particularly attractive if certain components, such as users and privileges, change infrequently, but user data in other databases or tables change more frequently.
be able to use that password to gain unauthorized access. Password expi- ration can also prevent potential future unauthorized use of a password that is in the process of being compromised, such as when an attacker issues a brute force password attack. For example, if an attacker needs on average one year to brute force compromise a user’s password, and the user’s password expires in 120 days, after that password expires and the user puts a second password into effect, should the attacker compro- mise the first password, it is no longer used and therefore of no value to the attacker. Essentially, password expiration reduces or closes the window of opportunity by which an attack can compromise and use the password for unauthorized access.
Password expiration values exist for each user as well as a system default.
Each user can have a unique expiration value, and that value is initially the system default in effect when the user account is created. After a user account is created, we can change the expiration value for that specific user without affecting the expiration values of other users.
To see the number of days for which a specific user account can use a password without changing the password, we can issue the SELECT state- ment whose general syntax is given in Figure 3.11 for MySQL or MariaDB DBMSs. Here we would replace username with the user name of the account, and hostname for an optional host specification for that account. We also specify single straight quotes (or alternatively left-quotes) around the user- name and hostname for reasons that we explain in Chapter 4. Note that smart quotes are not recognized as quotes in many DBMSs and may generate a syntax error if used.
SELECT password_lifetime FROM mysql.user WHERE user='username' AND host='hostname';
FIGURE 3.11 General syntax to show the password expiration for a specific user in MySQL or MariaDB.
This chapter contains some examples with general syntax and not with specific user accounts. Rather, these concepts for user password and account management are meant as a reference for now, and when we later create user accounts, you can refer back to these concepts and apply them to those accounts (or other accounts that you create) if you wish.
To change the password expiration interval for a specific user, we can issue the statement whose general syntax is given in Figure 3.12. We would replace ndays with the number of days in the expiration interval, and again replace username with the user name of the account, and hostname for an optional host specification for that account.
UPDATE mysql.user SET password_lifetime=ndays WHERE user='username' AND host='hostname';
FIGURE 3.12 General syntax to change the password expiration for a specific user in MySQL or MariaDB.
The default password expiration can vary across DBMSs. MySQL and MariaDB typically have a default of 0 days, which means no password expi- ration. To confirm the default expiration interval in days for those DBMSs, we can examine the default_password_lifetime global variable value, as demonstrated in Figure 3.13.
FIGURE 3.13 Showing the default password expiration interval in MySQL or MariaDB.
We can change the default password expiration in a MySQL or MariaDB DBMS either by changing the DBMS server’s configuration file or by set- ting the default_password_lifetime global variable within the DBMS.
In Figure 3.14, we show how a MySQL or MariaDB DBMS administrator can redefine that global variable to set the default password expiration at 120 days, with the SET statement. We then show the new default password expiration with the SHOW statement.
FIGURE 3.14 Setting the default password expiration interval to 120 days in MySQL or MariaDB.
Oracle often installs with a password expiration default of 180 days. To confirm the default password expiration for an Oracle DBMS, we can issue a SELECT statement on one of the DBMS internal tables as shown in Figure 3.15.
FIGURE 3.15 Showing the default password expiration interval in Oracle.
If we wish to change the default password expiration in an Oracle DBMS, we can issue an ALTER statement to change the DBMS internal tables.
Figure 3.16 shows how we can specify no password expiration in Oracle.
FIGURE 3.16 Setting no password expiration in Oracle.
Notice that no password expiration introduces a security risk with confi- dentiality. Figure 3.17 shows how we can change the default password expira- tion in Oracle to 120 days.
FIGURE 3.17 Setting the default password expiration interval to 120 days in Oracle.
Notice that a default password expiration value applies only to user accounts created after that value is put into effect and does not affect user accounts that already exist. Each user account contains information that includes the time interval in which their current password will expire. To modify the password expiration for an existing account, we have to change that account’s password expiration as we discuss next.
A DBMS administrator can set the number of days in which a given user’s password will continue to be valid before expiring. To set the number of days before expiration in MySQL or MariaDB, a DBMS administrator can issue a form of the ALTER USER statement, whose general syntax in given in Figure 3.18. Here we would replace username with the username of the account, along with optional hostname restriction, and ndays with the number of days until password expiration.
ALTER USER 'username' PASSWORD EXPIRE INTERVAL ndays DAY;
FIGURE 3.18 General syntax to set the password expiration interval to a given number of days for a given user in MySQL and MariaDB.
A DBMS administrator can also immediately expire a password for a given user account. This action may be a decision if the user’s password has a low suspicion to be compromised, and as a precautionary measure we will simply allow the user to continue using their account but with a new password. To immediately expire an account’s password in MySQL, MariaDB, as well as Oracle, a DBMS administrator can issue the ALTER USER statement whose general syntax is shown in Figure 3.19. Here we would replace username with the username of the account, along with optional hostname restriction,
ALTER USER 'username' PASSWORD EXPIRE;
FIGURE 3.19 General syntax to immediately expire a user’s password in MySQL, MariaDB, and Oracle.
If a user’s password expires—either by reaching the number of days since setting the current password or by an immediate expire by a DBMS admin- istrator—the user password must be reset before the user can regain their normal access with that account. Either the user or a DBMS administrator can reset the password for an expired account with the ALTER USER state- ment, as described in Chapter 4, “Database User Accounts.” By default, the user can still log into their database account with an expired password, but has extremely limited access. In that situation, the user still has the ability to log change their password so they can relogin in and regain normal control of their account.
If we wish to have no password expiration, a DBMS administrator can issue the ALTER USER statement, whose general syntax is shown in Figure 3.20.
Remember that while no password expiration may be a user convenience, it introduces security risks with user account confidentiality.
ALTER USER 'username' PASSWORD EXPIRE NEVER;
FIGURE 3.20 General syntax to never expire a user’s password in MySQL, MariaDB and Oracle.
Disabling/enabling user accounts
We may have situations in which a user account should be disabled such that no one can log into that account but it is not necessarily removed. This may be a temporary action, say, for when a user account is suspected to be compro- mised and for security purposes is not allowed to be used until the matter is assessed. Should the compromise turn out to be true, we can keep the account disabled until the breach is assessed, or however else is specified in the organ- ization’s security policy. In other situations, the disabling of an account may be a longer term solution, say because the user associated with the account is no longer with the organization, but for various functional or availability needs we still need the presence of that account so that, say, certain data or resources are still accessible. In both cases, we do not want anyone logging into that account for the time being.
To disable (or lock) a user’s account in MySQL, MariaDB, and Oracle so that logins to that account are denied, we can issue an ALTER USER state- ment whose general syntax is shown in Figure 3.21. Here we replace user- name with the user and any applicable hostname.
ALTER USER 'username' ACCOUNT LOCK;
FIGURE 3.21 General syntax to disable or lock a user account in MySQL, MariaDB, and Oracle.
When applicable, we can reenable a disabled user account, so that log- ins by that user are now permitted. In one of the previous scenarios. where we disabled a user account that was suspected of compromise, suppose the assessment yielded a false alarm. In that case, we can reenable the user’s account so the user can access the DBMS as before. To reenable (or unlock) a user’s account, we can also issue an ALTER USER statement, whose general syntax is given in Figure 3.22.
ALTER USER 'username' ACCOUNT UNLOCK;
FIGURE 3.22 General syntax to reenable or unlock a user account in MySQL, MariaDB and Oracle.
A DBMS may have other security controls for passwords and user accounts, and while these can vary among DBMSs, we introduced some common ones
in this chapter. We continue in Chapter 4, “Database User Accounts,” with other security controls for user accounts, such as with host-restricted access, which limits the system(s) by which a user account can access the DBMS.