How fingerprint scanning works with Oracle 9i security

Interested in using fingerprint scanning in Oracle 9i? Learn about Oracle 9i security and how it works with a biometric scanner in this tip from Oracle security expert Brian Fedorko.

Could you please tell me the Oracle 9i security features and their impact on biometric technology (scanner) for financial transactions?

What happens when staff place their finger on the scanner? (i.e, the operation that takes place between the scanner and the database before access is granted).

I need to write more on the technical part of my proposal and I would appreciate if you can help me.

A biometric scanner can add another degree of authentication to whatever data access you are granting.  Going to a multi-factor authentication scheme -- something you know (ID, password) --combined with something that you are (fingerprint) is a very prudent measure considering the potential sensitivity of any financial transaction.

The Oracle 9i database does not have any native support for fingerprint authentication, nor does any other, as far as I know.  What you’ll be looking at is simply storing and comparing whatever data the fingerprint scanning hardware or the supporting software supplies.  Here is the basic concept:

A user provides an ID, a password and a fingerprint scan for a transaction.  The fingerprint image itself is rarely stored or used, rather the minutiae of the fingerprint is analyzed by the hardware or its related software.  Points where ridges in your fingerprint split or end are identified, and then the angles and/or distances between the points are accurately measured and recorded.  Different manufacturers generally have various techniques and algorithms to process this data and create a unique, identifiable ID out of it.  Once this is obtained, we are simply dealing with 3 pieces of data (ID, Password and Fingerprint ID).

At this point, you have some options:

  • You can hash these values separately with or without a salt (a determinable, but variable input added to your values before the hash)
  • You can hash these values together with or without a salt
  • You can encrypt the values with or without a salt

Hashing without a salt is the least complex, but is generally vulnerable to brute-force attacks.  The hash input length and predictability will be key to mitigating this risk.  Encrypting with a salt would be EXTREMELY resistant to unauthorized attempts to retrieve the authentication information, however encryption key management and salt production can be very complex and quite difficult to implement effectively.  The approach you choose will need to be tailored to the system, environment, exposure, etc.

At this point, you must consider how the information will be transferred to the database to avoid collection, injection, Man-in-the-Middle attacks, etc.  If this is a closed, single site environment, the risk is reduced. If the information is to be transferred over the internet-at-large, at least encrypting message traffic is simply a must.

Lastly, you’ll want to compare what you have generated to a recorded value in the database.  This is often the least-addressed vulnerability, as the database is often well protected and in a trusted area far behind your network’s security layers (hopefully).  Unfortunately, most databases are extremely vulnerable to the insider threat.  Once again, mitigations include good personnel security practices, separation of duties, the principle of least privilege, etc.  Proper object permissions to tables, packages/functions/procedures are paramount, along with copious and focused auditing (and continuous monitoring of the audit table for anomalies).  Oracle has many native tools and options for ease and protection – However, you have MANY more options at your disposal in 10g, and especially 11g.  Consider looking at Label Security, Database Vault, Audit Vault, Oracle Advance Security, and TDE for ideas! 

To sum it all up:  Collect the data from the patron/user, protect the data, transmit the data, compare the data and grant/deny access appropriately.  This is definitely a critical and complex undertaking, but once you decompose the process into the necessary steps, and take prudent precautions, you’ll have an actionable plan for development.

Have a question for Brian Fedorko? Send an e-mail to [email protected]

Dig Deeper on Oracle database security