12.4. Weak Authentication

Weak authentication practices can lead to exploits just as serious as those I've already discussed thus far, although sometimes it may be more difficult to spot these vulnerabilities than the others. Weak authentication is exploitable when a malicious user can obtain another user's login credentials or privileges either through monitoring network traffic or brute-force password hacking. Oftentimes this is harder to detect because the attacker logs in as if he were the other user, so any actions look like they are legitimate.

Depending on your design requirements, you may want to apply the non-standard autocomplete="off" attribute to input elements. It was originally introduced by Microsoft for Internet Explorer but is observed now also by Mozilla-based web browsers. The attribute instructs the browser to prevent the caching of previously entered values in the field. With such caching, a user can sit down at a shared computer, place the cursor in the text field and press the down-arrow key to see a list of previously entered values. Although this may be insignificant in itself, it is one additional step in an overall plan for increased security.

Many of the Internet's early protocols seem to be designed with the expectation that users were honest. Telent, FTP, POP3, IMAP, HTTP and others all pass information—including login credentials—in plain text across the network. Sadly, all users are not honest and it is easy to configure a machine's network card to observe all the information being passed through the network. Many protocols have since been augmented to support encryption. To protect your users from eavesdroppers watching the wire with the intent to steal passwords, it is also a good idea to require all login (and other sensitive) information to be passed using HTTPS.

<form action=" https: // www.example.com/login.php" method="post">
 <div>
  Username: <input type="text" name="name" autocomplete="off" /><br/>
  Password: <input type="password" name="password"/><br/>
  <input type="submit" value="Login"/>
  <input type="hidden" name="submitted" value="true"/>
 </div>
</form>

The Secure Sockets Layer (SSL) protocol was designed as a way to easily use asymmetric encryption to establish a secure connection between two computers. HTTPS is HTTP transacted over an SSL-secured connection. It calls for two computers to authenticate themselves through cryptographic means and then establishes a secure connection between two computers over which symmetrically encrypted data is passed.

The server must be configured to accept and correctly handle the incoming connections securely. HTTP uses port 80 by default, and 443 is the default port for HTTPS. You may require an SSL certificate for HTTPS. For publically used sites it is a good idea to purchase certificates from a well-known vendor such as Verisign (www.verisign.com) or GeoTrust (www.geotrust.com). This certificate typically contains a serial number, encryption keys, the server's domain name, company name, address, the expiration date of the certificate, and the details of the certification authority who issued the certificate.

Certificates can be expensive, however, so for personal sites or development environments you may want to use a self-signed certificate generated with OpenSSL. OpenSSL is a commercial-grade open-source SSL toolkit available online at www.openssl.org.

There is another drawback to strong cryptography in that it can fall under various legal restrictions depending on which part of the world you are in. To quote the disclaimer from the OpenSSL project's website:

Please remember that export/import and/or use of strong cryptography software, providing cryptography hooks or even just communicating technical details about cryptography software is illegal in some parts of the world.

So if you're reading this book in a country in which all this is illegal, forget I said anything. I'm too young/busy/whatever to go to jail.

Encryption will protect information as it passes through the Internet but it doesn't prevent brute-force password hacking attempts. This is where the attacker simply tries to guess what the password can be and keeps trying until he is successful. To protect against this type of attack you may wish to track login attempts and disable the account after 3 to 5 incorrect login attempts have been made. A more modern approach is Multi-Factor Identification (MFI).

The three main recognized ways to verify an individual is in fact who he claims to be are:

• By something the user has, for example a bank card or key fob

• By something the user knows, for example a password or PIN number

• By something the user is or does, for example fingerprints, DNA and signatures

But there are other less common ways as well. For example:

• By where the user is, for example, at a particular computer terminal

• By when the user is, for example, during a certain hours during the day

• By who else knows the user, for example, social networks

MFI combines two or more authentication metrics to verify an individual. When you go to an automated teller machine (ATM) to withdraw money from your bank account you are actually participating in MFI—you provide the ATM card (something you have) and your PIN number (something you know). You can mix and match various methods to incorporate MFI into your site.