Because of...
If you have grown up in a small village, chances are, that you never had to show any proof of identity when you withdrew money from your account at the local bank. And the clerk never bothered to check your signature on the slip you had to sign. You could use your account because the clerk knew you; because of...
        ... who you are

If I tell my credit card company to issue a credit card to you and charge everything paid with it to my account, you can use my account. Not because of who you are, but because you have a credit card for this account; because of...
        ... what you have

Did you ever call your bank and ask something about your account? If they did not know you by your voice, they will have asked you something about your account, like when and how much the last payment was or how much money there is about in the account. Before identifying you this way, they would not give you any information. Access to info about your account was only granted because you could correctly answer questions to which only you were supposed to know the answer; because of...
        ... what you know

Who you are--What you have--What you know. Identification is usually based on these three principles, not only in the physical world, but also on the internet. Somebody might give you some information because you used your email address to ask for that information; because of who you are. Somebody else might trust information because it is signed by the secret part of your GnuPG key which only you have; because of what you have. And Hotmail will allow access to your account because you used the correct password; because of what you know.

Shared secrets
Usually when talking about passwords and security, the focus lies on what a good password is, what a bad password is, how to choose a password and how long it should be valid. While these certainly all are important things and would justify a full article, today I want to focus on a different aspect: not how good, but how safe are your passwords?

One advice always given is not to write passwords down. While I surely agree that you shouldn't write your passwords on Post-it notes and stick them to your keyboard, I insist that having a GnuPG encrypted list of passwords on your harddisk is still much safer than having one very good, complicated, uncrackable password, which is only stored in your head but valid for everything. While you might not have written down your password anywhere, you're not the only one who knows some representation of it. The services you want to authenticate to must be able to verify that what you claim to be your password really is the magic combination which should give you access. And for this, some representation of it must be stored somewhere.

Most systems these days (but not all) which need a way to verify your password, don't store the actual plaintext password on the server side. Instead the output received when feeding it into a one-way mathematical function, a so called hash, is stored. Feeding your password to this function will always yield the same result (hash), but there is no way to determine the password from the hash. The only way would be to try all possible passwords one after another until the output matches the hash from your password.
Understanding what a one-way function is and realizing that this really works can be quite difficult at first. Further explanation of these functions would require another article. Instead of going too deep into the details here, let's just do a much simplified example of a one-way function.
Your password can be any number. Divide this number by 7 and dispose of the integer part of it, leaving only what's after the decimal point. From this we cut again everything which is after the third digit behind the decimal point. This is now the hash to your pass- number. It is one of the following seven values: 0.000 0.142 0.285 0.428 0.571 0.714 or 0.857. From this value it is impossible to determine what your original pass-number was. Of course you'll realize that finding a matching pass-number to your hash is very easy for this simple function. In reality much more complicated functions are used which can yield millions of different hashes, often even a different hash for the same password, depending on the time the password was initially generated. As you will undoubtedly know, there are password cracking tools abound on the internet, most of them just a download away. And lots of them don't need any advanced computer knowledge to use. Cracking any password, however well it may be chosen, is only a matter of time and computing power. So, if you come to think that some representation of your password, which you use to access your free, but some-what suspicious web-mail account at Mafiosi Online, is stored on their server and you use the same password for logging in to your computer at home, for logging in to your computer at work, for accessing your bank account over the internet and even the code for your cash dispenser card is the same, can you still sleep peacefully at night? Wouldn't it be wiser to use one password for things which are not so bad if somebody gets to know it, another password for middle risk things and a third one for the really sensitive stuff?

Ears on the line
How often do you authenticate to some service over the network? How often do you type a password, which will travel over the wires, without thinking about it? Depending on the protocol used, the login name and the password will travel in clear text over the wire. Also if the service provider has only stored a hash of your password on his system, your password might be visible in clear text while rushing to the service provider. For anyone with some basic networking knowledge and access to a part of the network, the password has to traverse, it is a piece of cake to extract the login information from the data stream. As you would expect, there are also some freely available and quite remarkable tools which make password sniffing quite comfortable and usable for the masses, even for the unknowledgeable masses. And not even switched networks will be of any help, some tools make ARP poisoning so easy that in ten minutes I could even teach my wife how to do it.

Let's see how some of the protocols you are most likely to use transmit passwords.

telnet / FTP:
Both, telnet and FTP (File Transfer Protocol), are very old protocols. When they were invented, the internet was small, most often you knew the people accessing other computers and security was not an issue. All the data sent with these two protocols is transmitted in clear text. So if you telnet to an account, every single one of your keystrokes can be seen, including the password you type. Exactly the same with FTP. If you use FTP to upload documents to your homepage and you have to give a username and password, everything is visible in cleartext on the wire. Also if you publish your homepage with some tool which automates the FTP session for you, if the protocol used is FTP, everything is in the clear.

Don't, under any circumstances, use highly secure passwords with FTP or telnet. And if you must use these protocols with sensitive systems, at least use a separate set of passwords for each system, so if a hacker finds the password for one system, (s)he will at least not be able to easily break into all the other systems as well.

SSH:
Whenever possible, you should be using SSH (Secure SHell) instead of telnet or FTP. SSH is a drop-in replacement for the rather insecure, old r-commands (rsh, rlogin, rcp) found on Unix systems. Free SSH implementations are available for almost all platforms. Public/private key authentication or passwords can be used with SSH. But contrary to telnet, it is not possible to see what you type, as the whole communication, from the very beginning to the very end, is encrypted. So even though with password authentication your password goes over the wire, it will, as anything else, be encrypted before leaving your computer and decrypted after arriving at the destination machine.

HTTP / proxy:
Did you ever have to enter a username and password to access some protected resource with your browser? Most likely yes. If checking what's going over the wire, you'll see a HTTP header in the request your browser is sending to the webserver and this looks about like this:
        Authorization: Basic ZGVtbzE6ZGVtbw==
Looks very complicated, right? But in fact, this is almost plain text as well. It is neither a hash, nor encrypted. It is simply encoded with the base64 algorithm. Decoding is very simple, I could even do it by hand and the decoded string is demo1:demo, which is exactly the username (demo1) and the password (demo) which I typed in the browser's password pop-up box.

If you surf the internet through a proxy server and need to authenticate to the proxy server with your userID and password, then the same method is being used to authenticate to the proxy server as when authenticating to a webserver. The only difference is, that the header used reads Proxy-authorization instead of only Authorization.

Using highly sensitive passwords to authenticate to webservers or proxies should be an absolute taboo. This information can not only be seen and easily decoded, it also happens that, for debugging reasons or whatsoever, all the headers of your request may be written to a logfile and stored somewhere. For a password hunter, getting hold of such a logfile would be like Christmas. What's more, some versions of proxies are known to leak the Proxy- authorization header into the requests sent to the webservers, including your proxy authentication information in every single request sent onto the internet.

POP3 / IMAP4:
A couple of years ago, when connections to the internet were not yet so fast, a friend called me and said that her computer locked up every time she dialled her provider and wanted to download her email. The modem lights were flashing like crazy, though. I didn't think that it was a problem with her computer, but had the impression that there was a huge mail in the queue, which took so horribly long to download. So I asked her for the mailserver she was using, her mailaccount name and the password and did the following:

        telnet her.mailserver 110
           (OK reply from server)
        user her-mail-name
           (OK reply from server)
        pass her-password
           (OK reply from server)
        list
After the list command, I got a list of emails she had in the queue to retrieve. Indeed, the one with number one was so large, that it would take her about 15 minutes to download. So, still connected to the POP3 server and logged into her account, after checking with her, I sent a delete command for this huge mail and logged out with quit.

Combining this little story with the information given before about telnet sending everything you type over the wire in cleartext, means, that also with POP3, your password is clearly visible. Especially if you have configured your mailer to check the mailbox every five or so minutes for new mail, chances for a hacker to read your password off the network are quite good. There are, however, alternative authentication methods with POP3 servers, for example APOP. If your provider's POP3 server supports APOP authentication and your client does as well and indeed uses this method, then your password will never go over the wire when you login to your mailaccount. With APOP a server-generated timestamp and your password are combined, then an MD5 hash computed and the result is being sent together with your login name. On the server side the same is being done. If the hash computed by the client and the hash computed by the server match, you're granted access. But, this means that on a POP server your password must be stored in plain text or at least in a form from which the plaintext representation can be retrieved.

While POP3 servers are not required to support the normal, quite insecure authentication (but most, if not all, do), the story is different with IMAP4. As with POP3, IMAP4 servers can also support multiple authentication methods, but they are required to support plaintext password authentication at least as a fallback method.

So, unless you know quite well what authentication method is being used when retrieving your mail and how it works, it is advisable not to use your most secret passwords for mail.

Other threats
With passwords it's the same as with anything; if you absolutely want to get it, you can. It might be expensive and cause a lot of trouble, but it is definitely possible. Social engineering is one way, pressure another. If you can spend some bucks and have access to the machine your victim is using, there are keyboards and connectors on the market which will log every single keystroke. Some of the more advanced (and more expensive) ways are to monitor electrosmog generated by your computer, keyboard or monitor or installing tiny little spy cameras on the ceiling. This is not something which is being done only in books and movies. Some interesting passwords are the codes of the bank cards used for withdrawing cash. Police have actually found cash dispensers with very tiny cameras above the keypad. While you type in your code, somebody nearby watches what you type on a small portable TV. After you leave the cash dispenser, somebody walks into you. No problem, you think, because you still have the money you just withdrew, not realizing that your card is gone. They now have both, the card and the code which goes with it.Another possibility for somebody to see your password is system administration or troubleshooting. Usually this is not dangerous, as the people who get to see the login information are not interested in it. But if a good system or network administrator should turn evil, (s)he will have ample opportunity to sneak around for some valuable information.

Conclusions
As we've seen, there are various possibilities to get to know somebody's password(s). To be realistic, you always have to think that one day somebody will get your password, be it on purpose, by mistake or by accident. In order to prepare for that occasion, it is highly advisable that you use a number of passwords, chosen by sensitivity of the data they allow access to and the probability of password detection. What works well for many purposes is to have a password base, which is supplemented by some information about the service the password is used to access. For example, you might have the string P3f as your base, append an m for mail accounts, an l for login accounts, a w for web accounts and the first three letters of the service's name. So the password for your mail account at Mafiosi Online might be P3fmMaf, for your Hotmail account it could then be P3fmHot, for your login at the university you'd use P3flUni, for the web login at amazon.com it could be P3fwama and so on. Such a scheme is easy to remember, even though all the passwords are different.

I hope that I could give you some insight into why you should use more than one password. Information about how to create good passwords and what kind of passwords are easily crackable is available in abundance. But if you would like to see an article about it here, then say so, and I'll see what I can do.

GnuPG - The GNU Privacy Guard	http://www.gnupg.org/
Programming Internet Email	http://www.oreilly.com/catalog/progintemail/
Practical Unix & Internet Security	http://www.oreilly.com/catalog/puis/
PINBOARD	http://www.pinboard.com/
HighTechSamurai	http://kurt.www.pinboard.com/

© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.