Internet Security for End Users

Internet security involves two things:

• network security - keeping unauthorised people out of areas they should not be able to access
• data security - keeping data secure, even if it is accessed

Network security

This is an advanced topic. Network security depends on the hardware used in the network, the software running on it and how this software is set up and kept up to date. End users can do little about this. Part of this software is however authentication software to keep unauthenticated users out of certain areas - user names and passwords. End users can do much when it comes to choosing the right password. To make your password strong, don't base it on a dictionary word (password cracking tools use dictionaries, among other things) and have both upper and lower case letters as well as numbers in your password. If things like underscores are allowed, use them as well. There are powerful password cracking tools, like John the Ripper, out there. John the Ripper can even be downloaded for free. It is in most Linux distribution repositories and can very easily be installed. And John the Ripper is by far not the only password cracking tool freely available. So, you're up against the big guns when it comes to passwords. Don't make it easy for them.

Another aspect of network security which needs mentioning is intrusion detection. Many, if not most, people will never even know a hacker has been into areas of his network. A hacker doing it for money will steal (copy) information and try not to leave any sign of his intrusion. What's the use of stealing a lot of credit card information if the people are going to cancel those credit cards in a few days? A compromised network area is one in which all the information is to be considered stolen.

Data security

How can your data still be safe even if it falls into the hands of the wrong people? Simple, encrypt it. But there are some things to be aware of. Think of encryption as existing in three varieties:

• asymmetric encryption - like when you send credit card details over the Internet
• symmetric encryption - like when data is stored in an encrypted format, but has to be turned into plain text again to be useful
• one way encryption or cryptographic hash functions

Asymmetric encryption

Asymmetric encryption depends on a pair of two keys, a public key and a private key. One key (any one) encrypts and the other one decrypts what his paired key has encrypted. The public key is freely supplied to anyone who wants to communicate with the entity holding the key pair. The private key is jealously guarded. Your browser takes care of obtaining a public key whenever it is needed. How your browser takes care that these keys conform to certain principles:

• the key has been signed by a recognised certificate authority.
• the key has not expired
• the key comes from the web site it is supposed to come from

If anything is amiss with the key, your browser will throw up a warning. Let's consider an example of asymmetric encryption:

You have bought something at an online shop and have reached the stage where you have to supply your credit card details. You should be on a secure page as indicated by the https: in the browser's address field. Your browser will have obtained the public key of the online shop or whoever handles their payment. After filling in your credit card details and clicking submit, or whatever may be on the button, your browser uses the public key obtained to encrypt your credit card details, and any other details on the same form, and submits it to the server of the shop or payment gateway. The only key in the universe that can decrypt your information is the paired private key held by the online shop or payment gateway. This is really one of the more reliable things in life. You have very little to worry about that your information will be intercepted and decrypted.

Your information now reaches whoever handles the credit card payments. They decrypt this data, using their private key, and inspect it. Now let's say, for arguments sake, that you didn't fill in one compulsory field. This can of course be checked by your browser on your own machine using Javascript, but this form of error checking is not 100% reliable. So, for the sake of this example, let's say the form you submit is checked on the server. The application running on the server notices this error, creates an html page as a response and sends this back to you, with, in most cases, the field containing the error highlighted and with feedback on the nature of the error, after encrypting it with the private key used by this web application. The values you filled into the fields are also sent back so you don't have to start all over again. But you will notice that your credit card number is not sent back to you. Mostly only the last four digits are sent back. Now why is this? It is because anybody who has the public key used by this web application can decrypt what has been encrypted by the private key of this web application. And the server hands out this public key to anyone who wants it - it's not called public for no reason.

After all this the information you sent is in the shape it's required to be. The application does a Luhn check on the credit card number you submitted to ensure it is a number which will pass for a credit card number. If everything is fine, your credit card details will be sent to the credit card people, after encrypting it with the public key of the credit card people. The credit card people check all the details you submitted, see if a valid credit card matching the details you submitted has been issued to you and if you have sufficient credit or funds to pay the amount involved. Whatever the case, a response is sent back to the server of the online shop or payment gateway which in turn do what is necessary to get the result of this response displayed to you, the customer of the online shop.

Your very sensitive credit card information has been transmitted in every case encrypted using a public key. Sending information over the Internet encrypted with a private key is not that secure, as pointed out before. Private key encryption is mostly used for digital signing. If anybody uses his private key to encrypt a message or signature which can be decrypted with a public key, only the person having the paired private key of the material decrypted with the relevant public key could have encrypted (signed) it.

Symmetric encryption

Symmetric encryption is when the same key is used to encrypt and decrypt material. This is mostly used when storing information one doesn't want anybody, legitimate users or hackers, who has access to the raw information store, mostly a database, to be able to use. The only way this data can be usefully used is by using the application that encrypted the data to access this data. This application will know the location of the key needed to decrypt the data as well as the encryption/decryption algorithm used.

Make no mistake, symmetric encryption makes things much harder for hackers to get useful data from your data store. But its weakness is that the key has to be available to the application that uses it and one can tell from the software which encryption algorithm is used. So if intrusion is detected, even if all the information is encrypted, all the information is regarded as compromised. The hacker may never succeed in decrypting this information, but one cannot know that.

One way encryption

One way encrypted material can never be decrypted. One way encryption needs to conform to the following:

• the same raw data will always encrypt to the same encrypted values
• it is not possible, if one has the encrypted values, to work out the raw data which will encrypt to those encrypted values
• small changes in the raw data will lead to big changes in the encrypted values, so one can't know if one is getting "hot" seeking for the right raw data
• the encrypted values are always of the same length, giving one no clue about the length of the raw data

One useful application of one way encryption is stored passwords. Any password you type in is encrypted and compared to the encrypted stored password. If you lose your password, it can't be read from the database and given to you. If this can happen, your password was stored in plain text. No, your password has to be reset using a known, often machine generated, string. This new password is then given to you. You can reset it to something you can remember as soon as you have used it and logged in.

What to take from all this

Firstly, believe what I've told you about passwords. Secondly, the most sought after information you have, is your credit card details. Believe me, your medical history is boring and not profitable, so is your love life. But your credit card details can be used or sold. So, what to do?

• never submit your credit card details over an unsecured network connection - if you're not sure the connection is secured, don't use it
• be very selective about whom you allow to store your credit card details - Sony was hacked, and they're big

When it comes to storing your credit card details, don't think twice, it's not all right. Don't ever let a shop store it. It may be fine for a payment gateway, like those belonging to banks and other big organisations, to store it. Amazon has a very good record. Stored credit card details are vulnerable as long as they're stored.

If you find what you learned on this page useful, please use the social media widgets at the bottom and pin, tweet, plus-one or whatever this page.

The form for comments is below.