Home > Articles > Security > Software Security

Securing Databases with Cryptography

  • Print
  • + Share This
This chapter discusses how cryptography can fit into your security profile. After explaining what cryptography is and providing a general idea of how it works, we dig into the various types of cryptographic algorithms and see where the strengths and weaknesses of each lie.
This chapter is from the book

For more information on Security, visit our Security Reference Guide or sign up for our Security Newsletter

This chapter discusses how cryptography can address the concerns raised in the previous chapter. After explaining what cryptography is and providing a general idea of how it works, we dig into the various types of cryptographic algorithms and see where the strengths and weaknesses of each lie.

Finally, we look at where database cryptography sits in an organization's security portfolio. With respect to threats against confidentiality and integrity, we examine how cryptography can help with security. We also look at the common pitfalls and difficulties encountered in implementing a cryptographic system. Not only does a poorly implemented system not provide the needed protection, it can actually weaken overall security. We spend time looking at what kinds of risks a poor cryptographic system introduces.

2.1 A Brief Database Refresher

For the most part, this book assumes knowledge of databases, but we’ll quickly go over the fundamentals in case you’ve been away from the topic for some time. A relational database stores information in tables consisting of rows and columns. A field or cell is the intersection of a row and column.

Tables are related to each other through primary and foreign keys (these keys are quite different from cryptographic keys, which are discussed later). A primary key is a subset of the information in a row that uniquely identifies that row from all the other rows in the table. A foreign key links a row in one table to a row in another table by referencing the latter table’s primary key.

Indexes allow for quick searching through a table. By specifying an index on a column, the database creates a special data structure that allows it to rapidly find any information stored in that column. Primary key columns are typically indexed.

A standard language, structured query language (SQL), is used to manage data. Database objects, such as tables and indexes, are created, modified, and destroyed using a subset of SQL known as data definition language (DDL). Information is entered, viewed, altered, and deleted from a database using another subset of SQL called data manipulation language (DML).

The most common interaction with a database is the select statement, which is an element of DML. The select statement allows an operator to dig though one or more database tables and display just the data that meets specific criteria. A basic select statement contains three clauses. The select clause specifies which columns should be displayed. The from clause specifies which tables should be included in the search. The where clause details the criteria a row must meet to be selected.

The where clause frequently contains join statements, which tell the database how to include multiple tables in the query. Typically, a join follows the link established by a foreign key.

Other frequently used statements include insert, for inserting new data into a table; update, for modifying existing data in a table; and delete for removing rows. All of these statements also include from and where clauses.

Programs typically interact with databases by building and passing these statements to the database. For instance, when a customer wishes to see the items she added to her shopping cart last week, the application passes a select statement to the database to select all of the items in that customer’s cart. Then, when the customer adds an item, the application might pass an insert to the database.

Stored procedures offer another avenue for an application to interact with a database. A stored procedure is a program that is loaded into the database itself. Then, instead of the application building an insert statement to add a new item to the customer’s cart, the application would call the add_item_to_cart stored procedure and pass the item and quantity as arguments.

Databases are much more complex and feature-rich than what we’ve described here, but this overview should provide enough context to help you make sense of the database terminology used in this book. The code examples at the end of the book contain many examples of SQL statements. See Chapter 21, "The System at Work," for example.

  • + Share This
  • 🔖 Save To Your Account