For enhanced security, we can create database user accounts with additional specifications and settings. As an example, we can restrict which system(s) or host(s) a user must be on in order to log into the database system. The first two account creations had no such restriction, so a user on any system may log into the database with username roberts or garrett.
If we wish to restrict which systems can be used to log into a particu- lar account, we can combine the username with a hostname from which the login attempt must occur in order to be successful. Any login attempt to that account from another system is automatically denied. We combine the user- name and hostname with an at (@) symbol in between them and no added spaces, similar to that of an email address format. In Figure 4.13, we show how to create the account for chu and restrict logins to that account from only the localhost, or system running the DBMS.
FIGURE 4.13 Creating a database user account with a password and host restriction.
As with usernames, if the hostname contains special symbols such as a hyphen (-) or percent sign (%), the entire hostname must be enclosed within a set of quotes. Note that while periods in a username were considered a special symbol, periods in a hostname are not considered a special symbol.
So, if we specify a hostname with one or more periods, we are not required to enclose the hostname within quotes. Furthermore, we can also specify a sys- tem with its network or IP address rather than hostname. In a similar manner, we do not have to enclose an IPv4 address within quotes because of the peri- ods involved. However, we do have to enclose an IPv6 address within quotes because a semicolon (:) is considered a special character.
Even though quotes were not required for the hostname in Figure 4.13, we provided quotes anyway because as with usernames, it is good practice to always enclose hostnames within a set of quotes for a predictable and uniform appearance, as well as to avoid the omission of quotes in situations where required.
As an important note, we do not enclose both the username and hostname within one set of quotes. Even though an error may not be generated, doing so has the effect of specifying the username as everything within that pair of quotes, including the at symbol (@) and hostname. The hostname portion will be assumed nonexistent.
In cases where we want to allow a user to log into the DBMS from multi- ple hostnames or IP addresses, we can specify multiple user accounts, one for each hostname or IP address. For example, if we want to allow user donnelly to log in from the DBMS system itself as well as the IPv4 address 192.168.2.8, we create two user@hostname accounts or instances for donnelly, as shown in Figure 4.14.
FIGURE 4.14 Creating a database user account with access from multiple systems.
Note that because each user@hostname account or instance is associated with its own password, we can either assign the same password to all instances or accounts for a particular user, or assign different passwords for each of those instances or accounts. Figure 4.1 shows different passwords for each of the multiple accounts that users donnelly and sanford have.
While using the same password for multiple user accounts may be eas- ier to remember from a user perspective, that can introduce a security vul- nerability. If that password becomes compromised, an attacker can use that
password among all of those user accounts and thus access the database sys- tem from all of the hosts by which that user is authorized. Specifying different passwords for a user’s set of accounts may be more demanding from a user perspective to remember all of those passwords, but can add a greater degree of security. Namely, if one of those passwords becomes compromised, only the account associated with that password is vulnerable. An attacker can then use that password to gain access only when logging in from the host(s) asso- ciated with that particular account. Because the other accounts for that user have a different password, they are still safe. As a result, the attack surface can be minimized in the event a password becomes compromised. For example, if the password for donnelly@localhost becomes compromised, an attacker can only use that password to gain access when logging in from the DBMS system.
If attempting to log in from 192.168.2.8, that account is secured by another password and so remains safe.
To help reduce the number of user accounts or instances involved when allowing a user to log in from multiple specific systems, the SQL wildcard characters can play a role with specifying multiple hostnames or IP addresses.
This is particularly helpful if the set of allowable hostnames or addresses fall within a certain range or network. To restrict an account to log in from a range of hostnames or network addresses, we can specify the range by using a SQL single character underscore (_) wildcard symbol to represent which single character can vary. For example, to represent the IPv4 address range 192.168.2.100 to 192.168.2.109, we can use an underscore (_) in place of the last digit, as shown in Figure 4.15.
FIGURE 4.15 Creating a database user account with access from a range of IPv4 addresses.
Note that because we created only this account for gardner, we have effectively restricted that user to log into the DBMS from only systems that have an IP address within the range 192.168.2.100 to 192.168.2.109, and not from the DBMS system itself (unless for some reason the DBMS maps the name localhost to an address within that range).
To specify a larger hostname or IP address range, we can use multiple consecutive single character wildcards. But we have to consider that because each wildcard symbol represents one character that can vary, a given number of single character wildcards matches against that many characters. For exam- ple, a specification of two consecutive single wildcard characters will match against exactly two characters.
To represent a multiple character wildcard match against any number of characters, we can use the SQL multiple character wildcard percent sign (%) symbol. As an example, suppose we want to allow user sanford to have access from the DBMS system itself as well as from any system within the 192.168.2 network (that is, any system in the IPv4 address range 192.168.2.0 to 192.168.2.255). We can specify % to match any value for the fourth number in the IP address, as shown in Figure 4.16.
FIGURE 4.16 Creating a database user account with access from a host and network.
A multiple character wildcard is also common with a hostname specifi- cation that involves an entire network domain or subdomain. For example, if we wanted to allow access from any system in the subdomain x.y.z, we could specify ‘x.y.z.%’ for the hostname.
As an important note, when creating a user account, specifying a wildcard for the hostname such as ‘username’@’%’ has the same effect as specifying
‘username’ alone. In both cases, there is no restriction on the host or system in which the login attempt occurs.
Now that all user accounts for the business scenario have been cre- ated, the listing of those usernames and their hosts should appear like that in Figure 4.17 for MySQL and MariaDB, and in Figure 4.18 for Oracle.
FIGURE 4.17 Showing the complete list of database users and their hosts in MYSQL.
FIGURE 4.18 Showing the complete list of database users and their hosts in Oracle.