As promised back in November, here is the first of my penetration testing tutorials. This tutorial will deal with the basics of Nmap, the popular port scanning security tool.

For this tutorial, you will need:

• Nmap
• A host (or hosts) that you own, or that you have permission to scan.

The host can be your computer (just use 127.0.0.1 as the IP address), or your home WiFi router (you can usually find the IP address of this in your network settings).

Performing your First Scan

The first thing we will do is run a default Nmap scan against an IP address. Enter the following command at your command prompt, or if you are using Zenmap (the graphical front-end to Nmap), put the command in the “Command” box.

nmap 192.168.1.1

Of course, replace 192.168.1.1 with the IP address you wish to scan (192.168.1.1 is the address of my home router). Then press enter. Nmap will start scanning the IP address you gave it, and should produce something like the following output:

Nmap Default Scan

As you can see, Nmap has detected that the host is up, and that it has 6 ports open or filtered. The entire scan took 9.37 seconds. What did Nmap actually do though? To understand this better, re-run the scan but add the -vv flag to the command:

nmap -vv 192.168.1.1

This will make the output more verbose, and should show you something like this:

Nmap Verbose Default Scan

As you can see, the first Nmap does is perform a Ping Scan to see if the host is up or not. A Ping Scan consists of sending an ICMP “Echo Request” packet to the host, and waiting to see if an ICMP “Echo Reply” is received. If no reply is received, Nmap will attempt to make a TCP connection to port 80. If this does not result in a connection or an error (e.g. if port 80 is closed), Nmap assumes that the host is down. Note that if you are running Nmap as a privileged user (i.e. root or an Administrator account), the TCP connection attempt is replaced by sending a TCP ACK packet instead.

There may be hosts that are up but are configured to block ICMP packets and ignore connection attempts to closed ports. If this happens, Nmap will assume the host is down and will not continue to scan it. To prevent this behaviour, simply use the -Pn flag in your command:

nmap -Pn -vv 192.168.1.1

Once the Ping Scan has completed, Nmap will attempt to do DNS resolution, by taking the IP address of the host and performing a reverse DNS lookup on it. If a domain name is found that matches the IP address of the host, Nmap will report it. The reverse DNS lookup can take some time, and when scanning a lot of hosts it is best to disable it. This can be done by using the -n flag in your command:

 $ nmap -n -vv 192.168.1.1

Finally, once the DNS resolution has finished, Nmap will perform a TCP Connect Scan on the 1000 most commonly used TCP ports. For each port, Nmap will attempt a TCP connection and report back if a port is open. If Nmap is run as a privileged user, a TCP SYN scan is used instead.

Service & Version Enumeration

So you’ve run a basic Nmap scan, and you’ve got a list of open ports on the host. At the moment, there isn’t much information you can get out of that list about what service is running on each port. To do it manually, you would have to connect to each open port and test different protocols until one works. Luckily for us, Nmap can enumerate services and their version numbers automatically. Just add the -sV flag to your command:

nmap -sV 192.168.1.1

Depending on the host and the services, a version scan may take a while to complete. When it ends, you should see something like this:

Nmap Version Scan

If Nmap cannot determine the service and version number of a particular port, it will mark it with a question mark and will often give you a “service fingerprint” which you can submit to the Nmap developers if you know what the service actually is. In the scan results above, I’ve removed these lines since they take up a lot of space, however one can see that the telnet service running on port 23 has given the router version details when Nmap connected to it.

When it comes to determining version numbers, Nmap will use built-in knowledge about different protocols to extract information. For instance, if Nmap suspects a port may be running a HTTP service, it will send HTTP requests and check for HTTP Response headers in the response packet. None of these methods are perfect, but Nmap seems to get the correct service and version number most of the time.

In a penetration test, knowing what services a host is running is very important when considering what exploits to use. The version number can also be a great help, as it will often tell you which exploits the service has been patched against.

Operating System Detection

Nmap can also be told to make an educated guess as to which Operating System the host is running. Nmap will analyze the packets it receives and perform numerous tests on them to try and narrow down the Operating System, including the version number, and in the case of Microsoft Windows, the service pack installed on the host. Operating System detection can be turned on by using the -O (capital ‘o’) flag in the command, but it does require a privileged user account to work:

nmap -O 192.168.1.1

If the OS is detected, Nmap should produce a similar output to this:

Nmap Operating System Detection

The Operating System detected was Linux 2.6.8 – 2.6.27, which is common for routers. From a penetration testing point of view, knowing the Operating System gives some distinct advantages when selecting exploits. For obvious reasons, a lot of exploits are often OS specific, so this kind of information will only save you time later on.

Extras

I’ve covered the basics of port scanning with Nmap, and now you should be able to go off and scan some hosts to see what kind of services you can discover. In this section, I will quickly go over a few extra features that will help you scan more effectively.

Saving Output

Nmap can output to a file instead of to the terminal. It comes with three main output types: normal, XML, and grepable. Normal output (use the -oN flag in your command) will save what you see in the terminal to a file, XML output (-oX ) will format the output as XML so it can be parsed or turned into HTML, and grepable (-oG ) will format the output so that it can easily be searched by the grep program. Alternatively, you can output to all three of these formats at once by issuing the -oA flag in your command:

nmap -oA myScan 192.168.1.1

Scanning Multiple Hosts

If you want to scan more than one host, you can simply add the extra hosts to the end of the command. Alternatively, if you want to scan a range of IP addresses, or multiple ranges of IP addresses, you can use CIDR notation in the same way:

nmap 192.168.1.1 192.168.1.2 192.168.1.3

The above command will scan three hosts (192.168.1.1, 192.168.1.2, and 192.168.1.3).

nmap 192.168.1.1/30

The above command will scan four hosts in the /30 address block (192.168.1.0, 192.168.1.1, 192.168.1.2, and 192.168.1.3).

Custom Port Ranges

By default, Nmap will perform a TCP scan on the 1000 most common TCP ports. If you want to scan the 100 most common TCP ports, you can use the –top-ports flag:

nmap --top-ports 100 192.168.1.1

Alternatively, if you want to scan specific ports, or specific ranges of ports, you should use the -p <port(s)> flag:

nmap -p 22 192.168.1.1
nmap -p 1-100 192.168.1.1
nmap -p 22,23,50-70 192.168.1.1

The first command above will only scan port 22, the second will scan ports 1 to 100 inclusive, and the third command will scan ports 22, 24, and 50 to 70 inclusive.

UDP Scanning

TCP is a very popular protocol, but some services use UDP. To perform a UDP scan, use the -sU flag in the command. Be aware that UDP scans often take longer to complete than TCP scans. You will also need to run the command as a privileged user in order for it to work.

nmap -sU 22 192.168.1.1

This will scan the 1000 most common UDP ports and report back on whether they are open or not. As with TCP, you can specify custom ports to scan too.

Advanced Nmap Port Scanning

I’ve touched on just a fraction of what Nmap can do, and I intend to write a tutorial later in the year that covers the more advanced features of Nmap, including the very powerful Nmap Scripting Engine. I’ll also share a number of techniques for speeding up host discovery scans, and how to gain a better control of Nmap’s multi-threaded nature.

Until then, I hope you’ve enjoyed the tutorial. Please feel free to ask questions in the comments, and I will get around to answering them when I can. If you think you’ve spotted a mistake in the tutorial (quite possible, I’m only human), then please don’t hesitate to point it out.

The reason for this small change in direction is threefold:

1. When I started this blog a couple of years ago, cryptography was one of my main interests. These days, whilst I still like reading up on advances in cryptography, I don’t find it as interesting as other aspects of information security.
2. Cryptography itself can be seen as a big part of “Information Security”, so it seemed pointless to effectively include it twice in the tagline.
3. I’ve worked as a penetration tester for almost 6 months now, so ethical hacking is now something I am focusing on and wanting to write about more.

So I’m going to start a small series of simple but detailed tutorials on various skills required when penetration testing. They will range from basic usage of nmap/nessus/metasploit to the more advanced cracking of stolen hashes and attacking web applications. If people have suggestions for other tutorials, be sure to contact me and I’ll do my best to put one together.

Last night I was also informed that my MSc Project (on Fuzz testing Web Applications) received a SearchSecurity.co.UK award for being of “outstanding quality”.

That’s all the personal news for now. I’ve been very busy at work over the past two months, so I have had less time to do personal projects like updating this blog.  As Christmas nears, I’ll have more time for these sorts of things. For now, thanks for reading!

1. Send all confidential data over a secure connection.

At the very least, send user credentials (i.e. username and password) over HTTPS. At the very most, send all data over HTTPS, especially when your apps are dealing with large amounts of personal information. There are almost no excuses for not using HTTPS these days, especially when buying an SSL certificate is so cheap. Be aware that if you choose to only send credentials over HTTPS, your web application will be susceptible to session hijacking attacks.

Never send any confidential data in an email, especially password confirmation emails. Email is not a secure method of communication, and it probably never will be (PGP is not widely used at all). When dealing with passwords, always let the user set their own, as opposed to generating it for them. That way, you do not need to send their password in an email since they already know what it is.

2. Encrypt confidential data before storing it.

If your web application stores credit card numbers of users or other confidential data, make sure that this data is encrypted in whatever storage medium you are using. If your web application needs to access this data, it should be copied and decrypted in memory, before discarding the copy. At no point should the unencrypted data be stored in some permanent location.

Additionally, the key(s) used for encryption / decryption should not be stored in the same location as the encrypted data. This is to minimize damage if the storage medium is compromised (for instance, if hackers gain access to a database containing encrypted data, the decryption key should not also be compromised).

3. Salt and hash all passwords in the database.

This is possibly one of the most important things a web application designer should implement in terms of user security, but again and again we see large organizations and companies either ignoring or misunderstanding the importance of salting and hashing passwords.

There are absolutely no excuses for not salting and hashing passwords. Your web application should never be able to retrieve a user’s password, either for a comparison or for sending to the user in case they forget it. When the user first registers, their password should be concatenated with a salt (some unique random string of characters) and then hashed with a strong hashing algorithm (SHA-256 for example). PHP has a built-in function called crypt() that supports numerous hashing methods.

4. Any alterations that increase security should be opt-out or forced.

Many web applications start off with a basic level of security, and then slowly add security as time goes on and the application becomes more popular (or, more often, in response to a security breach). Aside from the fact that this is a terrible way to approach application development, if it is done this way, any alterations to the application that increase security should be opt-out or forced upon the user.

To use a counter-example, Facebook originally worked over HTTP, with only the login being sent over HTTPS. This led to session hijacking attacks where a user on an insecure network could have their session cookie(s) stolen and used to gain access to their account. To fix this, Facebook allowed the entire site to be used over HTTPS, but had this option disabled by default. In short, they fixed the problem for those less likely to be affected by it anyway (the security conscious who don’t use insecure networks). Such an option should be forced upon users (as it does not impede on the way they use Facebook at all).

Generally speaking, if the increase in security has no effect on the usability of the application, or it fixes a critical security vulnerability, it should be forced on users with no option to opt-out. If the increase in security affects usability in some way which may annoy a large number of users, and the security issue it fixes is not considered high severity, there should be an opt-out for those users. Obvious exceptions to an opt-out would be features that require user setup (e.g. 2-step authentication).

5. Any alterations that reduce privacy should be opt-in.

A reduction in privacy happens if an alteration to the application makes some (user) information accessible to users who didn’t have access to it before, or if the application starts storing information that it wasn’t storing before. For example, if an email address on a user profile is usually hidden and an alteration is made to allow the user to display their email to other users, the email address should remain hidden until a user actively chooses to display it.

In the case of more information being stored than was before, it is perfectly acceptable to deny access to users who refuse to agree to this new storage feature (e.g. if a law is passed which requires your application to store IP addresses indefinitely). However, prior to the user agreeing to the change, the system should treat their information as it did before.

6. Password resets should depend on a security question of the user’s choosing.

If the user uses a “forgot my password” feature, the application should assume that the request is malicious and present the user with a security question (or questions) that they set up when their account was registered. Sending an email with a password reset link is not recommended, since the email account could already be compromised. Once the security questions are answered correctly, it is then acceptable to send a password reset link in an email.

Letting users themselves set the security questions on their accounts puts the security of their account in their own hands, and reduces the usage of pathetic security questions like “Mother’s maiden name?”.

7. Persistent session cookies should have a short life, but be renewed often.

Persistent session cookies (i.e. those that keep a user logged in between browser sessions) should expire after a short period of time. This reduces the likelihood of an attacker gaining a valid session cookie from an offline source and using it to hijack a user’s session.

In order to make cookies last longer without increasing the likelihood of such a session hijack, cookies should be renewed after a certain amount of time (thus extending the cookie expiration date). For example, a persistent session cookie is initially set to expire 2 weeks from when it was created, but it is renewed for another 2 weeks if the user uses the application when the cookie has less than one week until its expiry date.

8. Protect cookies from JavaScript using HttpOnly.

Setting the HttpOnly flag on cookies (theoretically) prevents JavaScript from accessing cookies completely. This means that any Cross-site Scripting (XSS) attacks will be severely limited, as they are often used to send cookies to a remote attacker. Even if you have protected against XSS attacks (see tip 9), the HttpOnly flag will protect your users against self-XSS attacks (where an attacker convinces the user to manually enter JavaScript and run it in their browser).

9. Treat all data as malicious. Validate and sanitize input. Escape all output.

If this list of tips could be reduced to just one item, it would be this one. User-entered data is something you have absolutely no control over, and it is the basis for almost every single attack on web applications. All data should be treated as malicious and handled as such.

Validate all user input against a whitelist of acceptable values (e.g. if an integer is expected, ensure that it does not have any non-numeric characters). Sanitize all input strings before sending them to a database by escaping characters like ‘ and ” (the PHP function mysqli_real_escape_string() does this for you). Using prepared statements or stored procedures instead of passing user input directly to an SQL statement will eliminate any SQL Injection vulnerabilities if they are used correctly.

Do not forget to validate lengths of inputs either. The HTML “maxlength” attribute can be easily ignored by an attacker, so always do a length check when the input reaches the application server.

When outputting user-submitted content to a web page, know exactly where it is going in the page and escape it accordingly. Escaping content intended to be placed inside HTML tags is completely different to escaping content intended to be placed inside JavaScript code.

10. Generate unique hard-to-guess tokens to be used with requests that alter values.

Cross-site Request Forgery (CSRF) is a potentially devastating attack that only requires a user to visit the attacker’s website. It affects most web applications simply because developers do not consider the trust that browsers have in their users. Unfortunately, CSRF is complicated to defend against, but such defences should be implemented if your application is to be judged as secure.

For each request that alters a value (ranging from changing a user email address to actively logging the user out), a unique and hard-to-guess token should be pre-generated and submitted with the request. Upon receipt of the request, the application should check the token to ensure it is valid before the alteration is allowed.

Deep Web

The Deep Web is quite simply any content on the Web which is not accessible to or indexed by standard search engine spiders. A search engine spider will typically crawl a website by visiting it and then visiting all the pages it links to, which includes pages local to the site and pages on other sites. Whilst this gives the search engine a pretty good view of the web, it misses out on a lot of other resources for various reasons:

• Standard search engine spiders do not try to log into any websites, so any resources protected by a login are not accessible to it.
• Content which explicitly denies access to search engine spiders (e.g. using a robots.txt file) is also left off the search engine index.
• A web server may host a file or directory of files that isn’t linked to anywhere on the web. These files and directories would be missed by search engines as they would (most likely) be by humans too.
• Content that requires input by a user to be generated (i.e. search results) may also be effectively invisible to search engine spiders.
• Some websites may require a special browser configuration to gain access.

You can think of the web as an ocean of content. Anything on the surface of this ocean is content that is being linked to openly. A search engine spider can only look at the content on the surface of the ocean, and any content in the deeper parts of the ocean (whether protected by a login, or just hidden from view) is inaccessible to it.

What it is important to remember is that the Deep Web has nothing necessarily to do with illegal activity, nor is it about being anonymous or hiding your identity. Most of us access the Deep Web on a regular basis, whenever we check web mail, or log in to a social networking site. If a search engine can’t see it, for whatever reason, it’s part of the Deep Web.

Dark Web

Conversely, the Dark Web does have numerous links to illegal activity and hiding one’s identity. It is a collection of websites that are only accessible over the Tor network, which hides your IP address and gives you complete anonymity. Not every website accessed over Tor is part of the Dark Web, since Tor allows you to browse anonymously on the regular web as well. However, the Tor network has a special pseudo-top-level domain suffix called “.onion” which is used to get to websites which host themselves over Tor, and are therefore only accessible via Tor.

Going to these websites without using a browser configured to use Tor is impossible, so the Dark Web is actually a subset of the Deep Web, and as such is not indexed by search engines. Whilst there are many websites on the Dark Web which do not promote illegal activity, there are plenty that do, including sites that sell drugs and weapons. A BBC report earlier this year highlighted the Dark Web quite well, and the hacktivist group Anonymous have attacked pedophilia-related websites on the Dark Web before.

Darknet

Wikipedia asserts that a darknet is a “private, distributed P2P filesharing network, where connections are either made only between trusted peers using non-standard protocols and ports or using onion routing.” Limiting the term to certain types of filesharing network is unhelpful in my opinion, and I see no reason a darknet cannot simply be any such network. This would make the onion routed part of the Tor network itself a darknet, and it is often called “The Darknet” (though there is more than one darknet, the onion routed part of the Tor network is still the most well known).

This too would make the Dark Web a part of the Darknet. However, it is important to point out that the Dark Web and the Darknet are not synonymous. Many other services can run on the Darknet, such as email, IRC, etc. The Dark Web is just one of these services, contributing a subset of traffic over the Darknet.

So a darknet (no capitalisation) is any network where connections are made only between trusted peers using non-standard protocols and ports or using onion routing. The Darknet (capitalised) is the onion routed part of the Tor network. This means that the Darknet is a darknet, in the same way as the Internet is an internet.

To make matters slightly more confusing, Project Meshnet used to be known as the “Darknet Plan”, though luckily the name was changed to more accurately reflect the nature of their project (and possibly to alleviate confusion).

Dark Internet

Finally, we end with a term which is completely unrelated to the three above, yet still manages to get confused with them. The Dark Internet refers to the unreachable network hosts on the Internet. They could be unreachable because a machine is turned off, or a network cable is damaged, or even because routing tables have become corrupted somewhere. Nobody, not even regular Internet users, can reach them. The Dark Internet is constantly changing; machines get taken offline, and some get put back online, but whilst they are offline, they are part of the Dark Internet.

Image via CrunchBase

On 12th July 2012, more than 400,000 emails and passwords for Yahoo! Voices were stolen via an SQL injection and published online. The passwords were reportedly stored in plaintext, making this security breach even more serious. If you are a member of Yahoo! Voices, change your password immediately, and if you use the same password on other sites, make sure to change them as well.

I performed the following password analysis with the help of pipal, a very popular and powerful password analyzing tool. The full pipal report is located here, with a longer report (showing the top 100 of each category) here.

10 Most Popular Passwords

123456 = 1667 (0.38%)
password = 780 (0.18%)
welcome = 437 (0.1%)
ninja = 333 (0.08%)
abc123 = 250 (0.06%)
123456789 = 222 (0.05%)
12345678 = 208 (0.05%)
sunshine = 205 (0.05%)
princess = 202 (0.05%)
qwerty = 172 (0.04%)

Despite numerous warnings by security professionals, the most popular password is still “123456″, followed by “password” in second place. These are highly insecure passwords, not just because of their length or complexity (which is very low), but because they are at the top of most password lists that attackers use to try to compromise an account. Remember, brute-forcing a password is always a last-ditch attempt at gaining access to an account; a clever attacker will always try common passwords first, and if your password appears in a password list online, you should never use it!

The fact that these passwords were even allowed reveals substandard practices in Yahoo’s password policy. To boost security, a user should be required to have a password that contains both upper and lowercase letters, as well as numbers and symbols. For additional security, the chosen password should be rejected if it matches one found in common password lists.

Password Length

8 = 119214 (26.92%)
6 = 79650 (17.99%)
9 = 66058 (14.92%)
7 = 65654 (14.83%)
10 = 54815 (12.38%)
12 = 21785 (4.92%)
11 = 21261 (4.8%)
5 = 5325 (1.2%)
4 = 2748 (0.62%)
13 = 2585 (0.58%)
14 = 1433 (0.32%)
15 = 773 (0.17%)
16 = 442 (0.1%)
3 = 303 (0.07%)
17 = 252 (0.06%)
20 = 169 (0.04%)
18 = 116 (0.03%)
1 = 116 (0.03%)
19 = 78 (0.02%)
2 = 67 (0.02%)
21 = 6 (0.0%)
22 = 4 (0.0%)
29 = 3 (0.0%)
30 = 2 (0.0%)
24 = 2 (0.0%)
28 = 2 (0.0%)

As you can see, most people are still using short passwords. Indeed, a whopping 61.66% of people are using a password that is 8 characters or shorter. If you include passwords with a length of 9 or 10, then the number jumps to 88.96%. When a dictionary attack fails, the main thing stopping a brute-force from succeeding in a specific amount of time is the length of the password. For each additional character a password has, the amount of time needed to brute-force it increases by a factor of 95 (assuming the brute-force is trying all types of character). Even if the password only contains lowercase letters, an additional letter will increase the time required by a factor of 26.

8 characters and longer is usually cited as the recommendation for password length, but with cracking speeds up due to improvements in processing power, that number should probably be closer to 12, if not more. Remember, a long complex password need not be hard to remember.

Complexity

Only lowercase alpha = 146512 (33.09%)

This small statistic shows a staggering lack of password complexity. Almost a third of passwords only contained lowercase letters, making the task of brute-forcing them much easier.

loweralphanum: 224085 (50.6%)
loweralpha: 146512 (33.09%)
numeric: 26080 (5.89%)
mixedalphanum: 23233 (5.25%)
loweralphaspecialnum: 6053 (1.37%)
mixedalpha: 5122 (1.16%)
upperalphanum: 3416 (0.77%)
mixedalphaspecialnum: 3327 (0.75%)
loweralphaspecial: 2103 (0.47%)
upperalpha: 1776 (0.4%)
mixedalphaspecial: 489 (0.11%)
upperalphaspecialnum: 233 (0.05%)
specialnum: 189 (0.04%)
upperalphaspecial: 51 (0.01%)
special: 20 (0.0%)

As these additional statistics show, more than half the passwords only contained lowercase letters and numbers (the numbers only increase the brute-forcing attack by a factor of 10). Barely one percent of the passwords could be considered “complex”, containing upper and lowercase letters, numbers, and symbols.

Conclusions

Yahoo! is of course to blame for the passwords being accessible to hackers, as well as storing them in such an insecure way. Their password policy which apparently lets users choose single characters for a password is absurd, and a full investigation should be carried out to find out how on earth the users were left this vulnerable. There were some decent passwords in the list, and those were made completely useless through Yahoo’s ineptitude.

That said, it should be noted that regardless of Yahoo’s ineffective defences and security policies, a great deal of these user chosen passwords were highly insecure. It is up to the user to choose a decent password, rather than relying on a system which you should not really trust (as users, we do not know what security weaknesses a system has, or how it stores important data). It is best, therefore, to create a unique complex password (or passphrase) for each account you have online, and to use a good password manager to help you keep track of them.

The second article is on the top 5 online password managers, something every sensible person on the Internet should have. With so many different websites, you can either have the same password (highly insecure) or generate a unique password for each. Online password managers mean you don’t have to remember all your passwords, though as I’ve pointed out before, you can generate highly secure and easy to remember passphrases for the most secure sites you visit.

Of course, there are already a lot of fuzz testers out there, especially for web apps, so mine will be “special” in a number of ways. Firstly, it will be a command-line tool so that users can run it from machines without a display manager (always useful). Secondly, it will use an XML-based “scripting” language that I have developed, which will allow people not familiar with programming (QA teams for instance) to easily write tests in a structured way that they can understand. Finally, it will support multiple fuzzing methods including a simple list of values, incrementing numbers, and completely random data.

I hope to open source it at the end of development, and of course I’ll make any such announcements on this blog.

The most visible difference between Flame and earlier pieces of targeted malware like Stuxnet and Duqu is the size, expanding to 20 megabytes when fully installed (Stuxnet was only half a megabyte). CrySyS Lab, which discovered Duqu in 2011, have described Flame as “arguably… the most complex malware ever found.”

More information on Flame can be found below:

Identification of a New Targeted Cyber-Attack - Iran National CERT (MAHER)

The Flame: Questions and Answers – Kaspersky Lab

sKyWIper: A complex malware for targeted attacks [PDF] – CrySyS Lab

Meet ‘Flame’, The Massive Spy Malware Infiltrating Iranian Computers – Threat Level (Wired)

Flame malware – more details of targeted cyber attack in Middle East – Naked Security (Sophos)

Flame: Massive cyber-attack discovered, researchers say – BBC News

I’ve written three so far, the first of which has just been approved and published, so please go read it and share it with friends:

How to secure your Facebook account

Unlike the rather technical and complex articles on this blog, my Yahoo! articles will apply to as many people as possible. If you’ve ever wondered about the security of your Facebook account, or have friends who need it drastically, this article should help you out.