Updating the User Password

There may come a point in the future where you will need to change your Oracle Database password. For example, if you don’t use the Docker image for a long time, the user password may expire. If this happens, then it’s simple enough to update the password using a very similar set of steps to those described in the previous section.

Notice in Example 2-6 the use of update instead of create. If the user already exists in the database and has the required privileges, then there is no need to include the GRANT statement.

Example 2-6. Updating a user

alter
 
session
 
set
 
“_ORACLE_SCRIPT”
=
true
;

update
 
user
 
<
user_name
>
 
identified
 
by
 
<
password
>
;

GRANT
 
ALL
 
PRIVILEGES
 
TO
 
<
user_name
>
;

So, just supply a different password in the update command in Example 2-6 and make a note of the new password for future reference. Quit the session when you’re done with the password update.

You’re finally finished configuring the containerized Oracle Database instance and it’s now time to move on to installing SQL Developer.

Getting Started with SQL Developer

For your required platform, download a copy of SQL Developer from Oracle:

https://www.oracle.com/tools/downloads/sqldev-downloads.html

Tip

As SQL Developer is an Oracle product, you’ll have to accept terms and conditions and also log in as a user. Once this is complete, you can then follow the steps to install SQL Developer on your platform.

We’ve trudged through a lot of steps to get to this point. So, let’s take a short break to discuss an important topic, which relates to downloaded artifacts.

Verifying Downloaded Files: Defense in Depth

As an optional extra, it’s always a good practice to verify the signature of any manually downloaded file. Where a key value is provided, you can verify it locally after downloading the required file. On the Windows platform, this can be done using the certutil command:

certutil -hashfile <Downloaded_File_Name> MD5

Substitute the full path and name of the file you downloaded and use the signing algorithm that matches the one on the distribution website from which you received the file. I use the MD5 algorithm. Another signing algorithm that can be used is SHA-1. In either case, make sure that the signature value generated by the certutil command matches the one on the originating website. This helps to verify that the file has not been tampered with during the download.

This is an example of what is known as defense in depth, which means that, rather than relying on a single level of defense, we use multiple levels. How the principle applies in this case is that we don’t assume that our antivirus software will detect and quarantine a compromised downloaded file. Instead, we check that the published signature on the website for the file matches the value returned by the certutil command. The signature check operates in addition to the antivirus software check.

Sadly, not all publishers include signatures on their downloadable binary files. This is a shame because it may inadvertently facilitate file modification attacks. Such signatures can be created automatically by the build process used to generate the artifacts.

Defense in depth is a little like having two external locked doors in your home. If one of the external doors is breached, then there’s a second level of defense. So, rather than relying exclusively on one defense mechanism, we use a combination of schemes, layered one on top of the other. Signing algorithms are of course not foolproof. They are merely an addition to existing security measures.