The Weakest Link

It is widely believed that it is 'impossible' to ever have a hack proof system. This is a sort of urban myth - but with the added appeal that even if shown to be false, you can't go too far wrong by believing it. You can though, very easily find yourself barking up the wrong tree. To be clear it is possible to produce a computer system that without the correct authentication, is completely unpenetratable. And it is possible to concoct passwords that could put the odds against a lucky guess at trillions of trillions to one. And unlike buildings that could ultimately be bulldozed if all else fails, all a computer system needs to do is deactivate accounts after say three authentication failures and send the account holders an email. An attack can deny service but you can easily prevent a break in.

But that is just the computer part. The human users are a different matter. On the one hand humans can be unpredictable. A person known and trusted for years, suddenly turns and does an 'inside job'. But there are things that can be done to counter this problem. Extra authentication steps when off-site or otherwise outside of the normal range of IP addresses, the audit trail, the honeypot. But on the other hand humans can be all too predictable and this is worse because it is difficult, if not actually impossible to protect yourself from other people simply being themselves! And humans can be careless or worse, can be duped. And that is why realistically, you cannot have a hack proof system.

As a proprietor of an online service, your administration account can be made secure and due diligence on your part can keep it that way. Onerous perhaps but it can be done. But you also have to worry about your user accounts. The cost of a breach depends on what your service does of course, and what guarantees you have made to your users. For a bank this is critical but it can still be very nasty without involving money. As a minimum, it will waste a lot of your time sorting out the mess and then there is the impact on reputation to consider. Just as a chain is as strong as it's weakest link, a computer system is as secure as it's most insecure user! So what can be done to prevent your users from leaving the keys to what is not just their front door but yours, under plant pots in your garden?

Password Limitations

As 'everyone knows', a good password is one that is easy for the user to remember and hard for everyone else to guess. But this statement is itself dangerous because we all think we know what it means when in fact, none of the terms are properly defined. It is a lot easier to know the sorts of things we can remember than it is to work out what others might guess about us - and unfortunately the two tend to be loosely correlated. We can all see what makes a bad password, e.g. personal data that is either widely known or can easily be discovered. But we are not so good at seeing what makes a good password.

Because of this, some employers have taken matters into their own hands and adopted a 'password policy'. Broadly these either generate passwords for users or force users to routinely invent new passwords. But such policies are at best ineffective and more usually, are counter productive. There is nothing to be gained from changing a password that has not been discovered and both approaches increase the incidence of human memory failure leading users to make the fatal mistake of writing their passwords down. You will not be surprised to learn how often people leave their passwords on post-it stickers stuck to the sides of their screens because you will have doubtless seen it done and more than once.

But the 'good password' notion assumes the you as user are the target. Some nasty person is out there to take out your system. To bring you down! And although that might be the case it usually isn't and it is of little relevance anyway. The big mistake is to think it is personal - even if it is personal. True, your system might be specifically targeted if it is or is perceived to be of high value. More likely though, it is a target simply because all systems are targets. Attacks are almost always completely indiscriminate. If you have a computer system connected to the Internet you WILL be attacked just as you will be bitten by mosquitoes if you are anywhere near water on a summer evening. And sooner or later, unless your counter measures are stringent, there will be consequences. But here is the thing, the attacks are not generally conducted with guessed passwords. They are almost always conducted with passwords that have been systematically harvested.

The tools of the hacker

There are too many tools and techniques to list here and needless to say, they are constantly being added to. Many of these techniques take advantage, one way or another of shortcomings in relatively basic security measures and so can be countered by due dillegence. It pays to focus on the detail of what we call 'the conversation' between the client and server. Don't think just in terms of the top level, of who looks at what web pages and fills in what forms. Look at the detail in the headers. Record everything. Design programs to trawl logfiles for aberations.

Many techniques take advantage of shortcomings in the security of PCs, large numbers of which harbor infections. Viruses don't have to be of the type that print a rude message on the screen and then wipe the hard disk. Those are a nuicence only to the PC owners. The ones that threaten your online service can sit there quietly waiting for something interesting to be typed in such as a user name and password, then they relay this information to a server somewhere for later use. The user won't see a hit on performance and so will not have any reason to think they have an infection.

And it need not be a virus. It can be a browser plug-in. Lots of websites have been set up specifically to dupe users into accepting a plug-in. It easy for a website to appear legitimate. The company fully registered, the accounts in order and up to date. All shopping cart orders dutifully fulfilled. So when the website suggests, for reasons of improved quality of service, improved security, improved anything - that you should accept the recommended plug-in, a lot of people will just do as they are told. And indeed the site and the business behind it could be fully legit. But the programmer who wrote the plug-in might have had different ideas.

Once a hacker gets to the point where they have a server that sits there collecting data from infected machines it is then easy for them to expand their empire. Data mining programs can be run to identify the more interesting accounts - such as the administration accounts of websites. Then the hacker can infect at will any down-loadable programs programs on the site with a virus or change what was a legit plug-in into a malign one. More downloads of viruses and plug-ins. More infected machines on the database, more data to harvest. And if it their inclination, more machines to act as foot soldiers in a DDOS (distributed denial of service attack).

Any one of your users could be handing out their user name and password by unknowingly using an infected PC. And you as site administrator could be doing the same. OK you can be super diligent. You can do things like ensure the PC you use to monitor and control the site is not the one used for general use, is virus checked, is not signed up to music download sites and has no proprietary plug-ins. But you can hardly ask your subscribers to do the same. So what can you do to bolster the security of your most insecure users and thus your site?

Fighting Back

Since it is as good as impossible to stop people of malign intent acquiring your user's user names and passwords how can you prevent them from doing damage once they have logged in? One answer is to quarantine all sensitive user actions such as those involving money and changes to account detail until the user confirms the actions via a separate channel. Assuming the online service is a website the basic idea is to send an email and/or text message to the user and require a particular response. For the email, this could just contain a code that has to be copied into a form on the website. Avoid measures such as requiring users to supply 'the 3rd and 5th letter' of such things as their 'secret access code' because that forces many users to write down the code on paper. Consider IP and MAC address based restrictions. It generally causes mimimal inconvienience to users to insist that particular actions may only be carried out from a particular PC at a particular location.

It is worth bearing in mind that secret questions and answers, could be all be known to the intruder by the same means as the user name and password. Depending on the value of user accounts, it might be worth spending 10 minutes with each, face to face or verbally over the phone, establishing such information. Mostly though, this is not economic or practical so secret questions are no panacea. But the confirmation request and user response are not as important as their endpoints. Use of email and text messages make life a lot harder for the hacker. To intercept the confirmation request the hacker would have to know what email address they needed to gain access to and then actually gain access. Text messages are harder to intercept unless the hacker can avail themselves to the user's phone. If the user is logged on using their mobile phone however, a facility you would probably not want to deny, a separate channel would obviously be harder to establish. But the call line ID on the return text message still has to match as does the browser cookie. And while the phone can easily be stolen, unless you really are being specifically targeted the chances that thief and the intruder being the same are low. For any other thief it would be three counts and they are out.

This is all commonsense and common practice and can be added to. But all these measures depend on one thing - keeping core data safe on the server. And luckily that does fall more within your jurisdiction. There are two things to be sure of. Firstly, make sure the program(s) that implement your online system are the ones you think they are. For this you need the source code. Compile the source code and check it produces the exact same binaries that are running. And if you are not the author, examine the source code if you are not the author to see what ports it is listening on and what outbound connections it is initiating. It is easy to spot back doors with the source code (even as a programing novice) but a lot harder without it. Secondly check what other programs, unrelated to your system (should only be OS programs) are doing. Then with all that done, configure the firewall to only accept FTP and SSH connections from your IP address, accept HTTP, HTTPS and if applicable SMTP and POP3 connections from anyone, and accept nothing else ever.