Demo Image

Behind Enemy Lines

“To protect your client information, it is necessary to delve deeper into the hacker’s mind.” Corporations open up

“To protect your client information, it is necessary to delve deeper into the hacker’s mind.”

Corporations open up to the online world in an effort to increase their customer base and they are dependent on tech­nology to manage their data. With this comes the responsibility of protecting customer in­formation. Ensuring that their physical premise and local network is secure, won’t suffice – the danger of a school kid retrieving customer in­formation stored in the company’s website is very real and we hear such news very often. A London school student, in October 2010, pub­lished 27, 000 passwords that he got by hacking his school’s website. This was just a school, but there have even been cases of hacking which led to credit card numbers being stolen as well.

The word ‘hacking’ piques curiosity in even a non-technologist. Hacking is regarded as be­longing to an elite group of genius program­mers who can take control of any system, de­stroy any data they wish, crack passwords for any email ID and even place their own content on websites belonging to corporations and governments. In simple words, hacking means to get unauthorised access to data and hackers generally take advantage of some flaw that is present in the software application.

So how do hackers break into systems? There are numerous ways depending on the system being used and we’ll start with some basics on protecting data and loopholes in systems. And since it is websites that provide the public with a means of entering corporate networks we’ll focus on them.

Storing passwords there

In this highly networked world, everyone is a customer to someone. All data in the corporate world resides on databases – user names, cus­tomer address information, email IDs, mobile numbers, credit card numbers, bank account numbers and even passwords. And getting to the database is what a hacker would love to do. It is quite common for many people to use the same password for multiple websites and ac­counts. So how comfortable would you feel if your password is stored in a database – a data­base that can possibly be accessed by many em­ployees in the company that runs the website, a database that if compromised would reveal your password that could be used to access your other online accounts.

Till biometrics identification systems become cheaper and easy to implement, verifying users on websites will continue to be done using pass­words. So how does the system verify that a par­ticular user is the person they claim to be? The system asks the user for the login – ID (which could be known to the whole world – like an email id) and the password (which should be kept private by the user). The system then asks the database, “Do you have a record which has this userid and this password that the person has supplied?” If a record is found, then it al­lows you to enter the system.

So who all could potentially view your pass­word? Any person who has access to the data­base can see it – possibly anyone from the tech­nology department. This makes your password ‘not so private’ anymore. Till biometrics step in, passwords are like keys to your locker — you don’t want anybody else to get your key; not even the person who designed the website that you use.

Hashing passwords

So what is the solution? Don’t store the actual password – instead convert the password and store the converted value in the database. So if your password were: thiscannotbecracked

it might get stored internally as:


The process of converting the input pass­word to a hash key using an algorithm is called hashing. Given the hash key you cannot find the original password; it is a non-reversible al­gorithm and there are many hashing algorithms available. Most websites employ hashing when storing passwords. So even if someone stumbles upon the hash key for a user id, they will not be able to guess the actual password.

When the system needs to verify a user, the system would take the password entered by the

user, apply the hashing algorithm and compare the generated key with what is stored in the database for that login-ID. A match means the user has used the right credentials. Encryption is also a process for converting a given text to something unrecognizable. But encryption is a reversible process while hashing is not.

Is it foolproof ? Not really; if someone hap­pens to see the hash key in the database, the only way to find out the actual password is by trial and error – since hash algorithms are pub­lic algorithms, a hacker can keep trying a ran­dom set of inputs through the hash algorithm and compare the output produced with the hash key. If a match is found then the hacker knows what your password is. Obviously this cannot be done manually – what a hacker does is create a program that will keep trying different combinations through the hash algorithm and try to find the match – this method is called brute force! Though it is breakable, the key here is that the hashing algorithm needs to be strong – weak hashing algorithms like LM Hash take a brute force program only a few hours to find the password. Stronger algorithms are the SHA- 1 and SHA-2 (Secure Hash Algorithm). The stronger the algorithm, the longer it will take to find the password; and if it is going to take a couple of years to find the password, then that is not of much use for the hacker.

The whole idea of hashing the password is to ensure that even if the database is compro­mised, the hacker does not get passwords which can be used elsewhere.

How do you know whether a system em­ploys hashing while storing passwords? Simple — just go to the “forgot password” link and in case they email you your original password you can be sure that there is no hashing being done. Websites that use hashing will reset your account with an internally generated password because they do not know what the original password is.

Injecting code into databases

Keeping passwords safe is a priority. But this is not all — there is a lot more that resides on the database than just passwords. Any mecha­nism that breaches the database of a system is a potential threat to client information. Do you know that every time you fill up textboxes on a website and hit the submit button, you are most likely interacting with the database on that system? Be it doing a registration, resetting

your password or logging into a system, you are interacting with the database. For a hacker, this provides a small window of opportunity to test the database and if possible cause some


Any application performs database opera­tions (reading and writing) using SQL (Struc­tured Query Language). You can consider it as the language used to interact with databases. Whatever information we type into textboxes is used to build an SQL statement and then passed to the database for execution. So a login page might construct an SQL like this:

Check if there is a record on the database where

user = ‘userid-textbox-value’ and

password = ‘password-textbox-value’

The values come in from what the user types and SQL injection/insertion is a technique where a hacker tries to insert his own SQL statement. For instance, if the user gave the password as:

‘dummypassword’ OR ‘t’ = ‘t’ the SQL con­structed by the application would be: Check if there is a record on the database where user = ‘user-textbox-value’ and

password = ‘dummypassword’ OR ‘t’ = ‘t’

The new condition inserted is ‘t’=’t’ which is always going to hold true and so the data­base will say, “Yes, I do have a record for this SQL statement.” Now the application thinks that this is a valid user because there is a record on the database and this enables our hacker to enter the system. There are more frightful things a hacker can do once this weakness in the application is discovered. The hacker could insert SQL statements that even delete records or databases and wreak havoc! Some databases disallow execution of multiple SQL statements in one call but most databases do.

And you might think that this only allows a hacker to gain access into a system — but this can be modified further such that data from the database is returned. The hacker will try to form an SQL that he knows will fail and the resultant error message thrown by the system will give him the details of what he is looking for! Yes, there are a lot of applications out there that throw database errors back to the user in­stead of giving a customised error message that might say “Operation cannot be performed”. Database errors when propagated back to the user can be used by a hacker to learn details about the database and this information will aid him in fine tuning his attempts at hacking the website.

The weakness is because of the way the ap­plication is coded – the application is permit­ting special SQL characters (like the double quote in the above example) to be passed to the database. Robust applications will per­form strong validation on user entered values and there are techniques by which SQL injec­tion can be prevented. The techniques are well documented. There have been SQL injection attacks for years and it still continues to be used by hackers even now. Protecting against this might seem to be something basic that every programmer should handle. But even this year there have been credit card identity thefts in Japan and China using this technique. It just goes to show that just because something is well documented doesn’t mean that everyone knows about it!

What we have seen is just a small pie of the data security threat that companies face. If you happen to be involved with anything concern­ing client data, the adage “Do unto others what you would have them do unto you” holds very true. A breach can ruin trust in your company. Protect before the damage is done.

Pin It

Leave a Comment