Database Reference
In-Depth Information
The Two-Factor Authentication Process
We are going to have Oracle applications attempting to read sensitive data that we are protecting. And
we are going to require that these applications do database authentication first; they will need to pass
our single sign-on tests, which were described in Chapter 8. Then they will need to request and receive a
two-factor pass code that we will send to them from Oracle database. It is that process of requesting and
receiving the two-factor pass code that we will be implementing in this chapter.
Once the user receives the two-factor pass code, they will submit that along with their request for
data (and do the encryption key exchanges that we finished discussing in Chapter 7). At that point, if the
user clicks his heels together and says “There's no place like home”, he will be back in Kansas with
access to read and update the data, as authorized.
Here's the catch: we can't assume that this two-factor code exchange will be instantaneous;
otherwise, we would just require that the two-factor code exchange and the data requests occur in the
same session. On the contrary, we will need to cache the two-factor codes in Oracle database for a set
time limit to assure that the user and code go together. Certain other facts about the user need to
correlate as well, such as the address of the computer from which the requests are being made.
Can you picture what we need to make all this happen? First of all, we need some data about our
application users. We need their corporate pager numbers, cell phone numbers, and corporate e-mail
addresses. The e-mail address is already stored in the
HR.EMPLOYEES
table. We will build another table in
the
HR
schema to hold cell phone and pager numbers.
Along with the cell phone number, we will want to designate a carrier. Each carrier (e.g., AT&T) has a
different address to which we will send messages for the cell phone. In the case of AT&T cell phones, we
deliver SMS messages to phones handled by a number of carriers. If you have paid access to an
aggregator, then you can use that as the carrier for all phones.
Security Considerations for Two-Factor Distribution Avenues
Two-factor authentication messages can be delivered to our application users via a variety of devices.
We are going to consider delivering the messages by cell phone, pager, and e-mail. With each of those
devices we have to consider the security implications. Our preference will be to send the two-factor code
to a cell phone or a pager. Only if those fail will we want to send the code to an e-mail address.
Security Issues with Two-Factor Delivery to E-Mail
E-mail in and of itself is a fairly secure application. It is password protected and it is usually well
managed. However, the data is usually not protected in transit by encryption, and it is extremely easy to
impersonate an e-mail sender and send mail as them. There is no inherent problem with exchanging
non-sensitive data using e-mail as long as you are willing to filter out the junk and verify the sender by
an alternate means, as needed.
Note
I love e-mail because it lets us communicate in a non-concurrent, non-collocated, and person-to-person
or broadcast fashion. It also can serve as a tactical record of a dialog and as a communication archive.
