posted on 7:46 PM, November 14, 2008
We are often asked, "Is ExSite secure? Can hackers break in?" It is normal for people to want to know that their website and data are secure from theft or vandalism, but the subject of security is much more complex than these questions imply. We obviously design the system to prevent unauthorized intrusions, but there are many ways to cause mischief on the web, and software security can only deal with a limited subset of these.
In other words, Web Security has many facets. Let's discuss each of them in turn, and consider how ExSite deals with each.
1. Can unauthorized people access private pages?
Private (member-only) pages are protected by a login and password scheme. Normally you need to know a valid login/password pair to gain access to the private page.
There are two ways to "hack" into a private page. The first is to use technical hacker tricks to bypass the system security and fool the system into letting you in. Obviously we design ExSite to make this as difficult as possible.
The second way is to just to log in like any other user. The hacker's trick here is only in guessing the right password to use, and this is usually much easier than one would think. A disturbing amount of the time, the following simple tricks will get the job done:
Some organizations issue stock passwords, such as login + member number to all their users. These are also easy to guess, once you know the password formula.
The lesson here is that if you do not select hard-to-guess passwords, no amount of extra system security will help. Worrying about engineered security at this point is like investing in the most expensive, hard-to-pick locks in the world, and then keeping your key under the doormat.
ExSite does attempt to enforce a basic password strength policy when users change their own passwords, to prevent weak passwords from creeping into the system. This is described in more detail below. However, these tests can be bypassed when doing bulk imports of member data or login accounts. Be sure to use reasonably secure passwords when initializing new accounts (eg. a random text string). If users then attempt to change their password to something that is easier to remember, the built-in password strength feature will ensure that easy-to-remember is not the same as easy-to-guess.
2. Can unauthorized people access administrator screens?
The administrator screens will only display information to users of a sufficiently high access level. You must be at least access level 3 to set other users' access levels.
Under-privileged users will have their access denied, and will get a login screen instead of the administrator screen. This has all the login and password strength issues noted above.
If you are making good use of the password strength feature noted above, your administrator passwords should be relatively secure from password-guessing programs.
3. Can unauthorized people access the server or database back-end?
This falls outside the realm of ExSite, and in the broader area of server security. Suffice it to say that ExSite does not require any server or database services be opened up to the general Internet, and for maximum security we recommend having nothing but the minimum required services opened to the Internet. In the minimum case, this is http (and/or https) only, but in many cases you will also need some other basic services such as ssh to connect to the server for remote maintenance. Common legacy services such as ftp, telnet, and sendmail should be disabled if possible, as they are a known source of many security issues and are not used by ExSite at all.
4. Can communications with the website be eavesdropped on?
Eavesdropping usually occurs in one of two places: (1) over the network, and (2) at the user's keyboard.
The first case has a straight-forward solution, if it concerns you: run a secure (encrypted) server (https). ExSite supports this mode of operation.
The second, more devious form of eavesdropping, is a more serious problem. Malware (viruses, trojans) that infects PCs may install "keyloggers" that watch what you type, and record the information for their own use. Using a secure webserver will not help if your users are using PCs that are infected with keyloggers. In some ways, this is a more likely and imminent threat than someone eavesdropping on your network connection, since (A) many people have infected PCs, and (B) you have no control over what PCs people use to connect to your website. Since the problem is out of your hands, you should simply assume that this is the case for a small proportion of your users, and take steps to mitigate the possible damages (see below).
5. Can the website get vandalized ("defaced")?
Defacing websites is a popular pastime in some hacking circles. Essentially, hackers plaster their graffiti on your home page as a way to gain status amongst their hacker peers.
To deface a website, they need to get administrator access in some way, either through your web application, or through some other weak point in the server. These methods of breaking in to your system are already covered in points 2 and 3, above.
6. Can the website become inaccessible due to a denial-of-service attack?
A denial-of-service (or DOS) attack swamps your website with so much traffic, that it can no longer respond to legitimate requests.
Because there are never any unauthorized intruders in your system, it may help to think of this as a performance issue rather than a security issue. Ie. the problem is not that your server has been breached, but that it cannot keep up. You can deal with this the same way you deal with too much traffic in general, eg. (1) switch to a higher performance running mode, (2) switch to faster server hardware, (3) use more static pages, which are faster.
Of course, a real DOS attack can always increase its bogus traffic to match your increased performance, so this isn't always a fix-all. It would be nice to be able to ignore or downgrade bogus traffic so that it has a lesser impact on your system. ExSite has some built-in kill-switch features that can help. There is a manual kill-switch that blocks all dynamic page views (the most costly form of visit) so that when under the effects of a DOS attack, only your static pages will be served. Alternatively, you can have a kill-switch trigger automatically when the server is too busy. Regular readers will get a friendly message telling them that their page view has been delayed.
If DOS continues to be a serious problem for you, then you will want to look into dealing with the problem before it even hits your website, such as at the webserver level (Apache) or at your firewall. Note that DOS attacks (and their even more serious cousins, distributed-denial-of-service attacks) can be quite difficult to handle even for the largest professional websites. There are no simple solutions for this problem that don't also impact real site visitors, unfortunately.
7. Can members' personal data be viewed by unauthorized people?
Only if you allow it. Member's private data is normally handled by a Members or Membership plug-in.
If privacy of member data is a concern, then the Best Practice is to use this plug-in on member-only pages, so that only authorized users have access to it.
Otherwise, you can put the data where ever you choose. For example, some sites may be promoting their member's products or services. Those members probably want you to publish their contact information where everyone can see it.
8. Can sensitive personal data (eg. credit card numbers) be viewed by unauthorized people?
See point #7 for a discussion of how personal data can be handled. ExSite does not collect sensitive personal data like credit cards by default.
Best Practice is: simply don't do it. There are many reliable, secure e-commerce services out there that will take on all the security issues and risk associated with handling credit cards. Outsource the payment processing to these services, and the whole problem is out of your hands.
If you absolutely must collect and store sensitive personal data, then you should have a protocol for handling that data, such as:
Mitigating Security Risks
Transforming any website with regular user accounts into a fortress that is impervious to hackers is a fool's mission, because:
If anyone can reach the login form, then your site is only as secure as your login and password policy. Anyone, including automated robots, can type into your login screen, which means anyone who has stolen a password, or is willing to try a bunch of guesses, can take a crack at it.
Implementing a truly secure password protocol and security regime is not that difficult, but it can end up being so user-hostile that your users won't be able to figure out how to log in because their passwords are too difficult, or constantly changing. The benefits of higher security may outweigh the risks.
If convenience to casual users is important, then it will not be easy to implement a truly secure system. In this case, a more sensible approach is to be aware of the security risks, and plan to mitigate losses or damages due to security breaches:
Here are some steps you can optionally take to add extra security to an ExSite installation or its webserver.
Additional Notes about Password StrengthExSite has a password strength testing feature that is used when users change or update their own passwords. It will disallow passwords that are too weak. Password strength is calculated as a number on the following scale:
Password strength is increased by:
If you want to change the strength requirements for passwords, use configuration settings like the following:
# decrease minimum password strength for regular (level 1) usersNote that password strength is only tested when passwords are set through normal password-changing tools in ExSite. If you manually set passwords in the database or through a data import, no strength tests will be performed, and the passwords will work regardless of how strong they are.
Additional Notes about Password Security
Passwords are stored in the ExSite database in plaintext by default. In some applications this is considered a dangerous way to store passwords because if someone gets access to your database, they get all of the passwords of everyone in the system, including the system administrators.
Our point of view is that if they have access to your database, it's already much worse than that. Encrypting passwords in the database is therefore false security. However, this extra layer of security is useful in some special cases, so ExSite has options for more secure password storage, which can optionally be enabled. For example, you may not want your IT people to browse the database and see passwords, or you might export your member data to files that are used outside the website, and you may not want passwords to be clearly visible in these exports. (You could just exclude them from the exports, of course, but sometimes that gets overlooked by accident.)
The configuration setting password_storage_method can be any of the following values:
plaintext - the default.
crypt - encrypted with 2-way encryption, so that the original password can be recovered with the system decryption key.
des, md5 - 2 different methods for hashing (encrypting with 1-way encryption), so that the original password cannot be recovered. With these methods, even if the list of password data is stolen, the hackers will still not be able to log in. (Small consolation, in our opinion, since they would have to be in your database to get this list, so they are already several steps beyond logging in.) Also note that both of these encryption methods are considered somewhat old, and susceptible to certain types of attacks that are feasible with substantial, but feasible, amounts of computing power.
Additional Notes about Secure Servers
Running a secure server (https) is a simple way to encrypt all communications with the website. This prevents eavesdropping on the network, but not at the user's PC. It is not a perfectly secure solution, but with certain types of data, especially sensitive private data, the risks are high enough that you want all the protection you can get.
Do you need a secure server? Ask yourself: what are the consequences of someone being able to see data entered into forms, or data returned in pages, as they are sent over the Internet? If the consequences are not serious (eg. someone can see that you ordered yellow towels), a secure server is optional. If they are serious (eg. they can see that you ordered yellow towels with credit card number XYZ to be delivered to your home address at ABC) then it's a good idea.
The simplest way to set up a secure website is to serve the same site from both a secure and an insecure URL. That way, if anyone types in a URL and uses http: instead of https: they will still get to the right page. However, if you ensure that all links on the site itself always point to the secure version (https), then no matter whether they start from a secure or insecure URL, they will always end up at a secure URL after they follow any links or forms.
To make sure that all links point to the secure site, you should do one of the following:
best practices (5)
content management (12)
data handling (7)
graphic design (21)
html formatting (7)
plug-in modules (28)
visual tutorial (29)
web protocols (9)