Almost everyone today is familiar with the concepts of a user name and a password. Your user name identifies you to the system (such as a website) and supplying the correct password makes sure you really are that user. In the online security business, this is called authorization and authentication. Are you authorized (permitted) to access the system, and are you authentically (really, truly) who you say you are?
It sounds pretty simple. You might imagine that the system just keeps a table of authorized user names and their associated passwords in a secure location where no one can access it. When someone logs in, the system compares the user name and password provided to the ones held under lock and key, granting access only if they match. The problem is, if anyone (like someone working inside the company that runs the website or a worker at the data center where the server actually lives) can see that table of names and passwords, he or she has instant access to all those accounts.
Early on, a better approach was devised. Instead of storing the passwords in the clear (called “plain text” in the parlance of cryptographers), a system would store a “cryptographic hash” of your password. For our discussions, a cryptographic hash has one important property: It’s practically impossible to find the original password that produced the hash. Think of it as a one-way operation.
When you log in, the system first hashes your password (which you entered as plain text) and compares it to what it has stored away. So, even if the system’s table of hashed passwords and plain text user names is stolen, the thief can’t see what your password is. This is one of the reasons modern websites “reset” your password, rather than provide it to you in plain text—they don’t have it. All they have is a bit of aptly named hash.
(To improve the security of a hash algorithm, it’s become common practice to add some number of additional characters—known only to the system—to the password you enter. These extra characters are known as “salt,” since they improve the hash.)
In the early days of the Unix operating system, the list of user names and hashed passwords was publicly accessible. Unix even provided access to the hash function so programmers could add password checking to their own programs. Of course, some enterprising programmer quickly wrote a program, fed words from a dictionary into that library function, and easily determined many user passwords. Even today, a so-called “dictionary attack” can work quite well. To combat it, some sites won’t let you use a password that contains a dictionary word or repetitive pattern. Some sites will even lock you out after several consecutive failed login attempts.
It’s pretty clear that your choice of password is important. And if the site you’re working with doesn’t take good care of it—by hashing it with salt and, even then, making sure no one can walk off with a list of user names and hashes—you could find yourself hacked.
Case in point: In early June, a list of 6.5 million encrypted passwords from the business site LinkedIn.com was posted on a Russian hacker site, requesting help in cracking (decrypting) them. It turns out that a cryptographic hash known as SHA-1 was used to hash them (without any salt to make it harder). Within two days of the list’s posting, more than 70 percent of the passwords had been determined via a straightforward dictionary attack. It’s presumed that the hackers involved also have the associated user names for these accounts. Note that if you use the same password and user name everywhere, the hacker who gets them is likely to try them elsewhere (such as bank and email providers).
Other than your password (and the practice of the sites you visit), your online security rests on something with the odd name of Secure Sockets Layer (SSL). The Web is based on the HyperText Transfer Protocol (HTTP), which was (and still is) completely insecure. Anything sent over the Internet from your computer to a website could be visible to anyone with a little bit of technical expertise. Obviously, this wouldn’t work for e-commerce or banking, so SSL was invented. When you connect to a website via the https:// prototcol, the connection from your computer to that website is encrypted and safe from prying eyes.
In turn, SSL is based on a digital certificate, or “cert.” If you want to run a secure Web server, you’ll need one. They cost anything from free to hundreds of dollars, and a common question is: “Why?” The technology is exactly the same. What you (as a site owner) are paying for is the blessing of a third party (the “certificate authority”). You can generate a free certificate yourself, but when a user visits your site, they’ll see a warning in their browser that your site uses a “self-signed” certificate. When it comes to paying for a cert, you have two choices: standard SSL certificate or extended SSL certificate. The difference? The extended certificate takes longer to get due to the more in-depth verification process, and it also displays differently it a browser: the standard cert shows up as a padlock in the address box of Internet Explorer, while the extended cert turns the whole address box green and displays the name of the organization that owns the cert. If you’d like to compare for yourself, visit www.gmail.com (standard cert) or www.citibank.com (extended cert). If you use Chrome, Firefox or Safari, you’ll see something similar.
Which cert should you buy? Remember, the underlying technology (and the security it provides) is exactly the same. Given the level of security awareness of most people when browsing the Web, it probably doesn’t matter that you’re using an extended certificate. The one exception, if you’re not as well known as Citibank or Google, it may help get over a visitor’s fear of doing business with you. Even then, GoDaddy.com offers the best prices ($70 per year for a standard cert, $100 for extended). Other cert providers are GeoTrust, Thawte and VeriSign (which actually owns Thawte, its “economy” brand).
Congratulations. You now know more than most people about online security. Still have questions? Drop me a line at mduffy@northbaybiz.com.
