Security measures for protecting web accounts

I though I would write some notes on website security today - specifically for account logins. So many sites these days require some sort of login. Even if there is no facility for users to register, most will require some sort of admin interface to a CMS for maintenance.

The dictionary/brute force attack is the simplest way somebody would try to gain access, and once they've gained access to your admin privileged account, they can do almost unrestricted amounts of damage. Once a cracker found the login page to your site they could quickly write a script which repeatedly enters usernames and passwords and submits the form. A script like this could make many attempts per seconds and will eventually get the correct combination, provided they do not get blocked in some way.

There are however a number of ways you can make it harder for a attacks to happen to your sites and your users.

Choosing safe passwords

Most brute force attack scripts will start off by going through the dictionary or a list of commonly used passwords (e.g. password, 12345, letmein, querty, liverpool , more). Your admin password should use a combination of letters, numbers and symbols even if you can't make your users do the same.

Obscuring the admin account

Use an obscure username for your admin account. Most web administration systems will initially create a user called admin or root with full access rights. A cracker will know this and will start off trying various passwords against the admin user account. Removing the default admin user or renaming it to something else will make the attempts useless - at least for a lot longer until they start trying other usernames.

Limiting login attempts

Limit the number of login attempts someone is allowed in a certain period of time. Surprisingly, many web login systems do not implement any such security. The principal is simple, when a predefined number of failed attempts have been attempted from a single IP address in a predefined period of time, further attempts are ignored. This works because it seriously slows down crackers so that, for example, instead of hundreds of attempts per minute, they are only allowed three.

You should check whether your current systems implement this feature. If you use a popular framework, somebody has probably already written a plug-in, module or patch to fix this.

SSL/TLS encryption

Use SSL/TLS (HTTPS) to encrypt the form data There are many occasions, where a man-in-the-middle (MITM) attack could be performed to listen in on the username and password data you send when you log in to a web form. This is especially a risk if you are using public wi-fi or an internet connection in a hotel or cyber-cafe. This is very easy for the attacker to do if the connection is unencrypted. If you enable SSL/TLS on your webserver and the web form is submitting to a URL beginning with https://, it will be next to impossible for the attacker to gain the username or password.

The unfortunate issue with getting this set up is that the server requires a certificate to be installed. You can generate one of these yourself (self-signed), however, as it will not be signed by a certificate authority (CA) that browser manufacturers trust, your users will probably be put off by a big warning message.

The problem is that a certificate is doing two things - enabling encryption security and proving that a website belongs to who they say it does. We just want the security aspect, but you have to have both. You have to make the decision on whether your visitors are savvy enough to trust the certificate, or whether you pay for a trusted certificate. There are projects such as CAcert that are trying to get accepted as a trusted CA whilst signing your certificates for free. However, until they are supported in every major browser, I have decided to go ahead and purchase one. Thankfully they are a lot cheaper than they used to be, but it pays to shop around and also check the list of supported browsers. Some can be bought for around £15.

There is one other reason for not using self-signed certificates and why users should not blindly accept these when they visit. Since your CA in unknown, a man in the middle could watch out for unknown CAs and auto-generate another certificate on-the-fly then pass it on to the user. If the user accepted this certificate, the data would be encrypted to the MITM, then the MITM would re-encrypt it to the server, leaving the user unaware of anything unusual. For this reason I would suggest only using a self-signed certificate if you and your users' browsers are setup to trust the correct certificate at the start, then you would be notified if it has been changed in between. You will probably want to generate a self-signed certificate with an expiry date very far into the future if you are going to use this approach.

Phishing attacks

Phishing is an alternative way for an attacker to gain access. It's really hard to protect your users from phishing attacks but you should learn how to avoid falling into the trap yourself.

If your site becomes popular, it is likely scammers will duplicate your login page and host it on their server where it will collect all username/password combinations entered. They will then send out emails to your users telling them they need to log in for some reason or another, including a link to their cloned login page.

Users should be warned not to ever click links in emails and/or inspect domain/subdomains, but this requires some technical knowledge. Once a user tries to enter their login details, the scammer can now access their account for malicious purposes. Among the most serious of these attacks are the ones that pose as your online bank or building society.

If you are a site administrator, it is likely that scammers have created pages that look like all of the standard website maintenance panels. Imagine, you received an email that appeared to be from someone who maintains your server, telling you that you need to change your password. Would you blindly click the link and log in?