7 April 2008
If you provide users with a password, you should probably think about telling them how to keep their password safe. Teaching users how to avoid being tricked into giving away their account data - being ‘phished’ - can be difficult.
Social engineering is a method of obtaining access to a secured system by exploiting a person’s trust. It consists of deceiving a person into granting access to a system by some sort of pretense. For example, let’s say I receive a rather desperate sounding phone call from an intern over in IT who has screwed up and lost their password and needs desperately to fix some problem for their boss. They know I have an account and are hoping I would be so kind to log in for them, something which I might be happy to do for a colleague. However, the person on the phone is not an intern in IT at all, and doesn’t even work for the company. What’s more, the second I have given them access via my own username and password, all of the security precautions are now absolutely useless; the attacker has gained access to the system they wanted to access. What if they pretended to be working at the bank? They might goad me into letting them empty my bank account.
A second example of a social engineering attack is to exploit a person’s guilt - to make the person believe that they have been caught doing something wrong and may get in a lot of trouble if they do not cooperate. This ‘cooperation’ may involve handing over their personal details. This kind of attack can even work if the victim did not do anything wrong; the act of being ‘accused’ can put someone into a defensive state. The desire to cover up any wrongdoing they have been accused of may distract them from the fact they are being conned.
The term phishing is used to describe such attacks when they are done over a message service, such as over email or text messages. Phishing is also often done on a large scale; a would-be attacker sends an email to perhaps thousands of people pretending to be from the IT department, or a bank, or something, hoping that at least one person will fall for the scheme. Some such schemes are wildly inventive, while there are just as many that are stock standard: ‘we need to confirm your account details’, or ‘we need to verify that your account is active’.
From the point of view of anybody involved in computer security, the fact that such attacks are so effective is depressing. They are effective for many reasons.
One reason such attacks are effective is that, like with any security precaution, it is as weak as its weakest point. In a large organisation in which lots of people have access to a system, only one person needs to slip up and accidentally give their username and password to the wrong person in order for the system to be compromised.
Another reason is that the users of a system may, being less confident with technology, be naturally inclined to trust and be a little fearful of somebody who both seems to know a lot more about technology and is in a position of authority; for example, someone from an IT department, or law enforcement, or who has access to their bank account. The consideration as to whether or not the person who contacted them is legitimate takes second place to the desire to comply with this person who seems so much more knowledgeable about the system.
It may also be that people don’t realise that computer security does not stop at some unseen attacker trying to guess or steal your password; that in large part an attacker can just walk right up to you and ask for it.
So, what do we tell the users?
Systems administrators often use the phrase ‘we will never ask for your password’. This is a good message, because it at least signals to users that there may be nefarious motivations behind someone offical asking you to confirm your password.
However, in most cases where someone is duped into giving their account information, they actually believe the person who has contacted them is legitimate. The phrase ‘we will never ask for your password’ can quickly develop exceptions to the rule; an attacker might say ‘Oh, but our systems are down and we have to log people in manually today.’ As it is coming from a person genuinely believed to be legitimate, such an exception is easily accepted to be true both because it is plausible, and because the victim trusts the attacker to know more about the issue than they do.
I think that users should be instructed that if they are ever asked for their password, even by genuine system administrators, they should not give it over the phone or in reply to the email. Instead, the receiver should call back the company on the known correct phone number and then give the password. Let’s say that I call you up and tell you that we are in the process of deleting unused accounts and we need your password to confirm whether your account is used or not. If you truly believe that my story is legitimate, you may ignore the advice that we never ask you for your password, because my story seems like a plausible reason for an exception to the rule. But if you have been told that you should always call me back when asked for a password, you may be less likely to be convinced by my insistence that that isn’t necessary. I might say that you won’t be able to call me back if you tried, or that the matter is urgent, but this may raise more red flags.
In terms of email phishing, too, we can instruct users never to click through a link to a site on which they have an account; instead, should they wish to visit the site they should type the site address or name into their browser.
Whether this is all effective is speculation, and it must still be remembered that no matter how security conscious an organisation is as a whole, it only takes one weak link: one uninformed or absent-minded person to slip-up and allow a breach of security.
