retrocoder.se

Login

Securing a website

Posted 2014-08-05 10:54:39

In this article I will talk about some aspects of website security. Website security deals with the task of preventing unauthorized access and changes to a website. Anyone, including me, who runs a website, like retrocoder.se, and/or develops applications to be run on a website, like RetroCMS, has to deal carefully with this matter.

What really sparked me to write this article was my recent upgrade from Joomla. When I unistalled Joomla I took the time to look through the log files generated by Joomla. What I found was that during the last couple of months, there has been thousands of failed login attempts made on retrocoder.se. Someone seems to have been running a brute-force attack on retrocoder.se, trying random combinations of username and passwords to try to get login access to the site. This lead me to think about the security measures in RetroCMS, which I have given some thought already before I started coding RetroCMS, even though no requirements have been written down so far.

Soo how does RetroCMS deal with this matter then. Well lets start considering what it is that should be protected. Basically it is the SQL database that needs to be protected. This is for two reasons, first and foremost the SQL database contain user information like password and email address. This is information that should be kept private at the discretion of the user. The seccond reason is content generation. If someone is able to make unauthorized changes to website content they can deface the website or create even worse attacks, like cross-site scripting.

Of course the above means that the php code also needs to be protected. Anyone with access to the php code, e.g. via ftp, can breach the security of the website. In this article I will not discuss this matter, other then noting that this is basically the task of the server provider, and of course me selecting a good password. What I am dealing with in this article is only access through the webserver, i.e. the http protocol.

Through the webserver, any visitor send information to the webserver via the get, post and cookie variables. The information in these variables are used in various ways to create SQL queries that are sent to the SQL server. And since we are trying to protect the SQL database this means that all data used to form a SQL query should be validated to make sure a malicious attacker is not able to create a SQL query that was not intended. This type of attack is called SQL injection and there is a lot of information on the web regarding this and how to protect against it. For those who wants to read more the SQL Injection Prevention Cheat Sheet is a good start to learn more.

Another way of attacking the website is to run a long series of login attempts toward the website hoping that eventually some username and password will be correct. This is what has happend to retrocoder.se. The first and foremost protection against this attack is to have a good password. If the password can be easily guessed or exists in a word list then there is nothing to protect against unauthorized access. But if the password is a good one, then we should make sure that the time is on our side. If it take long enough time to test passwords like this, then the likelyhood of a successful attack is diminishing, making it practically impossible.

An easy way to acheive this would then be to add some delay to the login process. But a much better approach is if the delay could be built into the SQL database. This is acheived in RetroCMS by using the bcrypt password hashing method to store the password in the SQL database. Passwords should NEVER be stored in clear text in the SQL database! And even using popular methods like MD5 hashing is not a good option. This is because many of the common hashing methods are designed to be fast, which is good if the hash is used as a message digest. But since we want testing of passwords to take "long" time, fastness is not a desirable feature.

Bcrypt is based on the blowfish cipher and it is configurable so that the effort needed to test a password can easily be increased in the future. This is needed as computer performance increase over time. To read more about bcrypt, wikipedia is a good starting place. Using bcrypt to hash the password and storing this in the SQL database also has the benefit of protecting againts password breach even is someone is able to get access to the SQL database, through SQL injcetion or other means. Even if an attacker has been able to copy the SQL database to his own computer, the attack will take long time.

RetroCMS has good protection against malicious attackers. But what I realized when I looked at the Joomla logs is that I want RetroCMS to log failed login attempts just like joomla does. This feature was missing but has been added yesterday. There are some other improvements that could be made as well, like limiting the number of failed login attempts. This will even further slow down an attacker trying to login. If after three failed login attempts for the same user or from the same IP address, login is locked for 15 minutes for that user or from that IP address. This would mean that an attacker is only able to test 12 passwords per hour and practically stopping the attack.

Hope to see you soon again!
// Retrocoder