The database containing the login and password information of your users is a target that can be of great value to an attacker. Unfortunately for you, it is also often an easy target for exploitation. We’ve already discussed some of the best practices for encrypting your passwords should a breach occur, but that is not enough. It is important to protect the data in the first place. This is a much bigger challenge.
Let’s take a some of the challenges involved in protecting username and password data. Most modern websites are primarily database driven with a (very simplified) architecture that consists of multiple front-end servers that distribute content and backend database servers that contain the content as well as user information. When a visitor to the site makes a request, the information is pulled from the appropriate database and delivered through the front-end servers.
Because websites rely on open protocols and standards to deliver content there is a lot of information an attacker can glean about an organization’s web infrastructure with a few well-chosen queries. To start with, finding out what type of Operating System a web server is running on will provide an attacker with some insight as to what type of database may be serving up the content:
-sh-3.2$ telnet XXXXXXXXXX.com 80
Trying XXXXXXXXXX.com...
Connected to XXXXXXXXXX.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 27 Jun 2012 05:03:51 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.3.3
Set-Cookie: pmaCookieVer=4; expires=Fri, 27-Jul-2012 05:03:51 GMT; path=/; httponly
Set-Cookie: phpMyAdmin=QsYd0S4%2CGjVqNeDU7hjVA1clD08; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, max-age=10800, pre-check=10800
Last-Modified: Fri, 07 Mar 2008 14:40:56 GMT
Set-Cookie: pma_fontsize=82%25; expires=Fri, 27-Jul-2012 05:03:51 GMT; path=/; httponly
Content-Length: 3663
Connection: close
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
By simply issuing the GET / HTTP/1.0 command I learned this web server is running Apache version 2.2.3 on Red Hat, while it does not tell me which version of Red Hat a quick check at DistroWatch.com tells me that Apache 2.2.3 came installed with Red Hat Enterprise Linux version 5.7. I also learned that the server is running version 5.3.3 and, most importantly, it is running phpMyAdmin, a program used to manage MySQL databases. All of this information was gleaned by simply issuing a command that every browser which visits the site also sends.
With this basic information an attacker has several options to attempt to gain access to the site database. The easiest of which is to install phpMyAdmin and find out what the default directory structure, as well as the default usernames and passwords are. A common mistake web developers make is leaving default, and almost always insecure, settings in place. Any tool that sits on the web server that can manipulate the backend database should not be stored in the default directory. Default passwords for these tools should also be changed and unnecessary accounts should be removed.
The next thing an attacker will do is search through the scripts on the site to see if any of them contain the username and the password to the database. Far too often developers will write a script that needs to query the database that includes the database credentials in the script. Sometimes this happens during the testing phase and the developers simply forget to the remove the credentials, but it can also happen by design. Database credentials should be stored somewhere on the server, outside of the directory path of the web site, and it should be both read and write protected so that only processes with the right level of access can view it.
If the database username and password are not found within the scripts, the attacker may get a little more forceful and start checking scripts the scripts to see what type of input validation is in place. This technique is most commonly tried with search scripts, but really any script that accepts input has the potential to be vulnerable. The attacker attempts to enter commands that will query the database -- piggybacking on the authentication process used by the scripts – into the forms on the site. If input validation is not in place, the attacker can use your own scripts to pull down a list of all the users’ logins and passwords. Because this is a higher profile attack, it stands out in the logs of the web server, if you are looking for it, so it is important to monitor web server logs and to understand what an injection attack for the platform that the web server is running on looks like.
As you can see from just the examples above, the attacker’s job is a lot easier than the web developers’. The web development team has to diligently review all code as well as ensure that the server itself is configured in a secure manner and keep a close eye on the logs looking for suspicious activity. The attacker only needs for one of those things to go wrong.
While it is important to follow the security guidelines outlined above, there are steps a developer can take to minimize the impact of a login and password database breach. Start by separating content, login information, and personal information into three separate database instances with different administration credentials. The bulk of your site, and most likely your scripting, revolves around content, which means that most of your chances for a mistake to occur comes from those scripts that manipulate content. If an attacker does find a flaw in one of those scripts they will not have access to any login or personal data.
Similarly, by separating login data from personal data, you will minimize the impact of a breach. Assuming the passwords in your database are well-salted, if an attacker does gain access to that particular database it will contain usernames and well-encrypted passwords. While that is still not a pleasant thought it is much more pleasant that having to notify users that the data contained usernames, password and personally identifiable information (PII).
Finally, restrict access to the third database, the one containing personal information, to only the parts of the site that need to run queries. This way, even if an attacker does gain access to the credentials to that database unless he can launch a query from the right file or directory he won’t be able to login to the database.
Remember, your login database is a target, but taking the proper steps to secure it and the data within it, will help to make it a very difficult target for an attacker to hit.