Databases are mainly used to support various business-critical applications. They can store many kinds of data. However, there are some things you should never keep in a database.
These basic database security techniques will help protect your data:
-
Unsecured Credentials
This is probably an obvious point, but it’s not a good idea to store plain text passwords in your database.
If a hacker gets access to the data in this table, he or she has a list of all passwords for all users. These passwords are in plain, readable text, which can be used to log in to the system as though the hacker were that user. This might not seem like a big deal: If the hacker has already accessed the system, why would he or she need a login? The problem is, people often use the same password for many accounts. If a hacker has user names and passwords, he or she can use that information on other sites. So, how do you get around this issue? Encrypt the password before storing it. This process is often called “hashing” and can also be combined with “salting.”
Hashing involves applying an algorithm to an entered password, which encrypts it. It can then be stored in the database. To check against this password, the system can perform the same hashing process against whatever value the user has entered and can check the output against the stored hashed value previously entered (the correct password). Many programming languages have a built-in functionality to perform this for you. Long story short, don’t store plain text passwords in a database.
-
Duplicate Data
Storing duplicate data in your database is not a good idea. It occupies more space in your database, which can be a considerable amount if you have a large database. Also, it can cause problems when you need to update the data, as you need to update it in several places. The only exception to this is when you’re creating a data warehouse. These kinds of databases are optimized for fast querying, rather than updating, and usually contain duplicate data.
One of the advantages of using a relational database to store data is the ability to store data in multiple tables, with each table representing an entity, which is then linked to each other. This is referred to as “normalization”. It allows you to have a single table for each entity, and use ID numbers (or other key values) to link between tables.
This means it’s easier to update data if you ever need to make changes to some values. It also saves space, and can often improve performance when making changes to the data.
-
Files Such as Images
Databases allow you to store files within tables in the database, such as images.
Now, while you can create tables and columns to store files (such as Oracle’s BLOB data type), it doesn’t mean you should. Storing a file in a database table means you need to use database logic (and possible application logic) to access the file. This increases the size of your database and degrades its performance. It also makes backups and data corruption harder to deal with. A better approach to storing files and images is to use the file servers. That’s what they’re made for. Doing so allows for faster file access, easier file metadata access, and easier backup and restore functionality.
-
Credit Card Data
Finally, you shouldn’t store credit card information in your database unless you absolutely need to.
This includes credit card owner names, numbers, CVV numbers, and expiration dates. There is far too much risk involved. If a hacker gets access to credit card data from your system, it has a big impact on your company and your customers. You also need to be externally audited to make sure you comply with strict standards—namely PCI DSS—if you store credit card numbers. This creates more trouble for your IT department and means additional expenses. A better approach is to use an existing solution, such as Authorize.net or PayPal. These organizations have already developed the software, proved their compliance, and many other companies already use and trust these companies. It’s better to avoid storing credit card data at all. Doing so is not worth the risk, and other companies do it better.
