For a long time now, I have been eagerly awaiting for out-of-the-box RSA encryption support with pure PL/SQL. Not so much for to sharing secrets, but rather, the ability to sign messages and verify signatures. I might have missed the announcements, but it looks like my wait is over support with asymmetric key operations added in 21c, and (perhaps backported) in 19c as-of release 19.9.
In my previous blog post on Running ORDS Against the Autonomous Database - Part 2, we had looked at how to add an existing Let's Encrypt (LE) SSL certificate to an Oracle Cloud Infrastructure (OCI) Load Balancer. You'd typically wwant to host your websites or Oracle Application Express applications over a secure transport layer, especially when sensitive data is communicated between the browser and server.
In a previous blog post, I provided a recipe for enforcing encryption for data-at-rest. However, it is important to remember that Transparent Data Encryption (TDE) protects your data from bad actors, who might have illegally gained access to the data files. Data exists unencrypted when loaded and accessed in the database. Malicious attacks can come from internal sources as well. When storing user confidential information, data stewards need to take greater responsibility in ensuring that data is only seen by staff who are authorized and require access to privileged information. That could mean creating tiered access and other protections like data redaction.
For example, an e-commerce website that handles credit card transactions, may require call centre staff to have access to the last four digits of a credit card number for verifying customers' identity when support call are received. Or an insurance claims website that requires claimants to submit their health identity number. The application displays the partially or fully-masked ID, enough to suggest that the data has been captured, but insufficient for a passerby to steal a glance.
Oracle's Data Redaction makes this possible, and with the latest release of Oracle Database 18c Express Edition, this technology is now acessible to developers for FREE! If you are new to Data Redaction, here's a simple recipe to get started!
Transparent Data Encryption (TDE) is a powerful database feature that allows developers and administrators to very quickly, persist data encrypted at-rest. Applications do not require explicit coding to encrypt data for storage. TDE manages encryption during storage, and decryption when data is read, transparently and automatically.
TDE can also be used during backups. In the typical "tape falls off the back of the truck" scenario, malicious actors would not be able to decipher the data on the lost tapes without the crucial encryption key stored in the Oracle Wallet. Assuming of course, the wallet was not backed up to the same tape.
This enterprise-grade feature is found in the Oracle Advanced Security Database Option. That requires user to be licensed for database enterprise edition. However, with Oracle Database 18c Express Edition (18cXE), Oracle has made it free and accessible by everyone!
This post was specially written for Oracle Application Express (APEX) developers who are new to this technology. It provides a simple workflow for creating an encrypted tablespaces. Since APEX application live on the database, placing the parsing schema on a TDE-enabled tablespace, automatically protects the entire application. Hopefully this will encourage you to use it for protecting Personally Identifiable Information (PII) or any other sensitive and confidential data.
Updated November 17, 2018 Please read this follow-up post as well. It contains an important note about intermediate certificates and where to download the root certificates.
One of the difficulties working with web services in the previous version of Oracle Database Express Edition (XE) was the lack of a usable Oracle Wallet. This was fast becoming a huge problems for developers, as many API providers started enforcing requirements to that clients accessed services through secured channels. When working with 11g XE, I often relied on proxies within a sandbox to mask the need for SSL/TLS. I discussed this somewhat at length in a previous blog post.
With the 18c release, Oracle has opened up and provided us developers the opportunities to make our apps safer. We now have access to the (orapki) tools needed to manage an Oracle Wallet. I don't do this a lot, so I keep a snippets of what I do to make this easy.
Authentication is an essential component of any enterprise application. These days though, it isn't enough to protect your applications with only a username and password. These are easily stolen by key loggers, sniffing non-encrypted HTTP traffic, phishing, hacked Internet services and the list goes on. To make matters worse, many users have a poor habit of reusing passwords that thieves then use to penetrate other systems. I have had my fair share of that experience.
The question is, can we implement two-factor authentication (TFA) in Oracle Application Express (APEX)?