by IWR Consultancy
Hyperframe is already designed with security in mind. The Web is a hostile environment, and the level of security which would be acceptable on an internal LAN is generally inadequate here. That said, the distribution package has to be supplied in such a format that it is reasonably easy to get started with it. Once the site is up and running, you may wish to consider making a few changes which further increase security.
The choice of a file-based CMS is one of the most positive steps you can take towards better website security, eliminating as it does the risk of SQL code injection. However, you should not be complacent about various other security concerns which apply to all websites.
It goes without saying that non-guessable passwords should be used. Words associated with your business, car types or regsistrations, favourite sports or team names are all bad examples of passwords. Choose something which you can remember, but no-one else would expect to find as the password.
Hyperframe employs tarpitting, such that repeated bad logins will cause its response to become progressively slower and slower. This makes bruteforce guessing or dictionary attacks much harder. Passwords in-transit between the browser and server are salted and double-encrypted, using a challenge/response mechanism. Passwords are never stored in plaintext on the server, either in memory or on disk. This part of the system took a fair amount of coding time to get the results we wanted, but we feel it's worth it for the peace of mind it gives. No-one can guarantee that a site will never be hacked, but we feel that any hacker having-a-go at a Hyperframe site will probably decide to try somewhere easier instead.
A few additional changes will make the site even more secure:
Change the site administrator's username
Change the administrative key
Since v2.4 it is no longer possible to view php scripts in pages with only the admin key, hence in this respect there is no longer the same degree of need for a non-default key. However, it's still good security practice.
Reduce the session timeout (and increase the keepalive ping rate to suit)
Change the site hash
Restrict the IP addresses the site can be administered from
The main usage here would be to restrict access to your ISP's specific IP ranges. Though, you can also restrict access to the IP ranges in use in your World region. This offers some useful protection from regions where hacking is known to be rife. It is not of course an absolute protection, since proxies can be used to get around the restriction. But, it is a useful way of keeping hostile robots out.
To avoid giving away that an IP block is in effect, the response to an admin-mode request from a banned IP is to present an error message which makes it look as if the site is down with a perplexing bug.
IP restrictions do not prevent the site being viewed, only edited.
Powered by Hyperframe