by Kurt Keller
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
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
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.
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
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)
(OK reply from server)
(OK reply from server)
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
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.
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.
© 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.
September , 2002
The Newsletter of the
Tokyo PC Users Group
Tokyo PC Users Group,
Post Office Box 103,
Shibuya-Ku, Tokyo 150-8691, JAPAN