In the previous two articles, Basic Client-Side Security Concepts and Basic Server-Side Security Concepts we’ve seen how we can easily get hacked on the client-side and server-side of our app. Here, let’s discuss vulnerabilities of our database architecture that any of your developers and architects should pay attention to.

Hack Access Point #1: Entering the Database

You might know by now that databases vary in architecture and in the languages they support to access data stored within them. They also very in security, but, in general, the access point to a database is secured by a combination of username and password. Now, your database architect (any person that helps you set up the database) does have the ability to open up the database to everyone, that is, get rid of the need for username/password combination in order to enter the database. It is up to you to make sure and communicate with your architect not to do so. With a username and password, however, you still have the potential of getting hacked if the hackers get a hold of your credentials one way or another – your password was too simple, you’ve stored your password in an accessible manner, you’ve used the same password elsewhere and it has been hacked, etc.

Hack Access Point #2: Understanding the Data Stored in the Database

Once hackers have gotten access to your database and your data, they now have to make sure they understand the data. It is not enough for them to have the contents of the database if, that is, the data is properly encrypted. In general, encryption is a technique to mask the actual data/text with other data/text that, for the most part, does not make sense to the viewing eye. For example, if a member of your site has their email saved in the database, it will not be stored as

"example@example.com"

but as something like

"EE889SADF90870O79USDAFDSFADS89798908ASDF"

This type of encryption is done in the server-side code of your application upon user registration. That is, the encryption happens in the server-side code before saving the data to the database. Your developer needs to architect and code the encryption method. The decryption of the email also happens on the server-side upon the user’s login or, generally speaking, upon retrieval of the data from the database.

The data that you most definitely want to protect using decryption (in case your database gets hacked) are passwords, emails, usernames and any user-specific data. What you want to prevent here is hackers getting a hold of any identifiable information for your users. Once they do this they can wreck havoc on your reputation and cause pain for your users such as spamming their email account. However, you can get pretty extensive with encryption even beyond the basic entries. I’ve seen people encrypt absolutely any and all data in their databases including post articles and post comments. I have also seen the actual table names and table columns be encrypted. It is up to you to decide what information you are comfortable with hackers getting their hands on. Personally, it is a bit extreme to encrypt posts and their associated comments as anyone can view these un-encrypted on the site itself in case of public sites.

I also need to mention here that certain data is not even permitted to be stored in your database unless you are compliant with certain laws. For example, it is illegal to store Credit Card information in your database unless you are PCI compliant which is a headache to do and most apps don’t. Instead, they employ the services of tools like PayPal, WePay and others. Those guys specialize in payment services and this is why they are experts at security their payment information.

Hack Access Point #3: Locating Decryption Methods for Your Hacked Data

Databases can be stored on the same server as the server/back-end component of your application. However, this is not a best practice because of security and scalability considerations. Database operation and server-side code processing operations are drastically different. They also hog each other’s resources if on the same server. In order to insure that your server code has enough resources on the server to perform swiftly, and vice-versa for your database, they need to be on their own servers specialized for their operations. As far as security, consider a scenario where sensitive data like passwords and emails are properly stored encrypted in your database and the code on how to decrypt them is located in your website’s directory. If both the sensitive data and how to decrypt it are located on the same server hackers only need to hack one server to get all your data. If, in turn, you separate the two into their own servers, hackers have a much higher hill to climb to get at your data. In this scenario, both of your servers would need to be hacked in order to get the data and then know how to decrypt it.

To further secure your database server I recommend opening it up only to the web server. You don’t need the communication to the database server opened up to the world. It only needs to talk to the web server in order to store and retrieve data. Further, you don’t need to allow any and all communication between the web server and the database server – just the database communication. Different types of communications use different types of protocols and ports. Your server architect/developer can control which communication to the server is allowed, which communication type is disallowed and who is allowed to access/not access each based on opening/closing ports to specific IP address or IP address groups. Make sure with your architect/developer that unnecessary ports are closed and necessary ports are only open to the necessary server groups.

Hopefully this brief description of client-side, server-side and database security helps you guys go out and write secure application. For further inquiries, please comment extensively!