Two-Factor Authentication - Expert Oracle and Java Security - page 182

Once my son broke the keypad on his cell phone and got another one with the same phone number.
I suppose that they cloned his SIM card in the new phone. For a while, both phones received all the
texting messages that were sent to him, so I can assure you that cloning (cell phones) works.
I like to remind my kids that the text messages they send, even if addressed only to a single other cell
phone, are going into a system that can be read by many people that they don't even know: the service
provider technical staff and law enforcement who may request access. That's not even mentioning the
parents, siblings, friends, and other snoops or thieves who might browse the phone at some time.
We need to remember that any data (including voice, photograph, and video) which is made into a
signal should be considered publicly accessible. That includes signals sent by plain old telephone
systems (POTS), cell phones, the Internet, and so on. That includes electrical, radio wave, light, and
sound transmissions.
Preferred Two-Factor Delivery
Cell phones are the most secure avenue for delivering our two-factor pass codes. However, there is
nothing sensitive about the pass codes, so pretty much any delivery route is fine. If a code is read by an
eavesdropper, to use the code that person would have to be sitting at the computer that initiated the
Oracle application, logged in as the initiating user and within the code cache timeout period (10
minutes). If someone sends a fraudulent code, that is not likely to have an effect other than frustrating
the user who is trying to use it for two-factor authentication.
The only preference we have is that if cell phone or pager delivery is available, we do not want to
send the code to e-mail. Because e-mail may be running on the same computer as the Oracle
application, sending the code to e-mail does not meet our goals for two-factor authentication, which is
separate and distinct identity traits. Specifically, the two factors we are counting on are what you know
(SSO initial login password), and What you have (a separate cell phone or pager).
Oracle Structures Supporting Two-Factor Authentication
In order to accomplish two-factor authentication, we will create some new tables and incorporate them
into our security processes. We will create a table to hold cell phone and pager numbers for users.
Additionally, we will create a table to hold the SMS gateway address for each cell phone carrier whose
phones we need to support. During our 10-minute cache timeout period, while we wait for the 2-factor
codes to be delivered to the user's cell phone, pager or e-mail, we will store the two-factor codes in the
Oracle database, in another new table that we will create.
In addition to new tables, we will also create functions to send and to test the two-factor codes. We
will also modify the p_check_hrview_access procedure to accept and test the two-factor code before
setting the secure application role, hrview_role .
Creating the SMS Carrier Host Table
Most, if not all, cell phone service providers (carriers) offer access to text their phones through an e-mail
server (SMTP.) For example, if you have a personal cell phone that is provided by AT&T, you can send an
e-mail message to your phone number at the AT&T SMTP server (e.g., [e-mail]), an d they
will route your text message to the phone as an SMS message.
Each carrier has its own SMTP to SMS gateway and address; for example, AT&T has txt.att.net. We
need a table to store those addresses so that we can send our two-factor authentication codes to cell
phones provided by a variety of carriers. We will create a table, sms_carrier_host , to hold those
addresses. See Listing 9-5. We also create a unique index based on sms_carrier_cd that we designate as
our primary key. And we create a view ( v_sms_carrier_host ) of the table. Create this table in the HR
schema.