You give out your passwords every day

If you’re allergic to acronyms, don’t read on. I’ve reached an all-time TLA/FLA density high in the following article!

Lock - photo by mfshadowTHE PROBLEM
Who knows the passwords you use for your email accounts? Who knows the password you use for your FTP account? Who knows the password to your blog admin page? There might be more than you thought!

Imagine user John Doe, with username jdoe who has the ‘strong’ password “p@ssw0rd“. Let’s take a look at what conversation happens when his Outlook/Thunderbird email client connects to check for new messages, or when he uploads a new version of his website with Filezilla/Dreamweaver:

This is a typical FTP conversation:

Response:	220 (ID of the FTP server)
Command:	USER jdoe
Response:	331 Password required for jdoe.
Command:	PASS p@ssw0rd
Response:	230 User jdoe logged in.
Command:	...

This is a typical POP3 (email) scenario

Command:	USER jdoe
Response:	+OK Password required for jdoe
Command:	PASS p@ssw0rd
Response:	+OK jdoe's maildrop has 2 messages (320 octets)

(remark: POP3 does have an APOP command that does not transfer the password in clear-text. It is however typically used for 2nd and following POP3 connections, using a piece of information that was given in the first transaction)

Wordpress loginEven more scary: when you log in to your blog/CMS software (that does not use a Google, Yahoo, MSN or Passport account), how does your password reach the server, you think? Encrypted? Not!

In all those cases, the password was sent to the server in clear text, i.e. readable and copy-able. Why is that bad? Anyone that is in the possibility to intercept the conversation, will have access to your password. You think that’s improbable? Well, let me introduce you to an elementary tool of any system administrator: the packer sniffer (e.g. Ethereal). This program will tell a network card to switch to ‘promiscuous mode‘ (listening to all network traffic instead of just those he participates in). It then allows the program to record any network conversation that passes on the local subnet (your office LAN, the Wifi network).

  • a LAN administrator (that guy with the “I read your email” t-shirt) can sniff anyone’s email (POP3) password and even the actual emails as they are downloaded by mail clients. I’m not saying he does, but he can.
  • that municipal Wifi network you connect to in that bar might also include a PC that records all FTP/POP3/HTTP conversations when they happen. You wouldn’t know.
  • same thing on conferences, meetings, when you just plug in or connect via Wifi to a network you don’t know.

Are FTP (RFC959 from 1985) and POP3 (RFC1939 from 1988) bad protocols? Not necessarily, it’s just that they were developed in an era where knowledgeable hackers were few, sniffing tools weren’t that prevalent and security wasn’t that big an issue. SMTP (RFC821 from 1982) (for sending email instead of receiving) also started out with clear-text authentication, but since it was mostly used with only IP verification and without user/password, that was less of an issue.


  1. PROTOCOL LEVEL: most modern protocols have been created/adapted to provide a more secure way of authentication, typically using salts, hashes and/or challenge-response systems, resulting in exotic names like e.g. CRAM-MD5.
    Protocol changes are tricky, because there is (certainly for SMTP, POP3, HTTP and the likes) a huge installed base of ‘old’ servers and clients that all have to be updated/patched to accept the new commands. Thanks to SMTP’s historical lack of security/authentication features, we now have an enormous spam problem (because anyone can send email on behalf of anyone to anyone else). Numerous proposals have been made to solve this, but if they include changes to the protocol, typically they don’t happen.
  2. TRANSPORT LEVEL: there is a generic mechanism based on PKI to start an authenticated and encrypted communication channel between two parties. It is called TLS (successor of SSL). Its best known application is HTTPS (URLs that start with https:// and where the little lock is shown in the browser). But there is also FTPS, POP3S, SMTPS, IMAPS, … Since the protocol itself does not change, the server and client can be unaware of the fact that they run over a secure channel.
    A concrete example: using stunnel to serve as secure proxy of an insecure server; all connections are encrypted between the outside world and the secure proxy, and the proxy just sends everything as-is to the actual server (but this insecure traffic is only visible on the server itself).
  3. CONNECTION LEVEL: going still a level deeper, we can encrypt all traffic between two points (as opposed to the previous transport level, where it is always about the encryption of 1 channel, between 1 client and 1 server). VPNs work like that: you connect the client to the VPN server once, and all further traffic between them is encrypted. This is great for remote office connections and the like, but not an option for communicating with random servers.
    This model was also used by Google VPN for Wifi: you connect to any (insecure) Wifi network and the first thing you do is create a connection to the Google VPN gateway. From that moment, all traffic goes encrypted to the gateway and only then to the Internet, so that any rogue clients on the local Wifi network cannot see/understand the traffic that is passing by. Google has however limited access the software to the users of Google Wifi, the network operated by Google in San Francisco.

Next time: introduction into PKI encryption!

6 thoughts on “You give out your passwords every day

  1. Peter Post author

    Gmail, Hotmail and Yahoo web-based mail do the authentication over https, so those are secure.
    For the others: POP3S, IMAPS and SMTPS would be better, but I don’t think providers will start offering them, it would be too expensive.

    FTP: SFTP (file transfer over SSH) works great if your host allows SSH.

    CMS (e.g. WordPress/Drupal) login: one could consider Javascript hashing?

  2. Robin Wauters

    Related but not really on-topic:

    I have a nasty tendency to use the same user name and password for every service I subscribe or register for. I’m always concerned about the fact that anyone who has access to the ‘back-ends’ (admins, helpdesk people, etc.) of those services might try logging on to other well-known services with that data.

    For example: a WordPress support employee could try and log on to Gmail with the same user name and password I provided in your WordPress account, and he’d get in just like that. The only way to avoid this is to use different user names and password for each service(or only the ‘critical’ ones), but how could you keep track, if you’re used to registering for all kinds of beta stuff out of interest?

  3. Maxim

    @Robin : there is , an opensource software hosted on sourceforge which provides password storage in a highly secured way (read AES). And, coincidence, a plugin for firefox was just released!

    Maybe this is the beginning of a solution…

    The problem with secured protocols (whether it is FTPS, IMAPS, POPS or even SSL or SFTP) is that it has a heavy load on servers and, as said Peter, it is expensive to deal with it because you’ll have to invest in more powerful servers or to buy many for load balancing…

    I was jocking earlier, talking about IPv6 (because it is not used today by individuals), though the idea of authentication could be a first way to deal with clear passwords without using a secure (read “encrypted”) layer.
    Ok, the password is sent in a clear way but if you are not who you claims to be, you are rejected.

    You can think about solutions like (and if you don’t know what it is, you should check this (famous) presentation :

    Any thoughts?

  4. Maxim

    Oh, by the way, I just found, an extension to firefox which provides multisite authentication and is made by… sxip (pronounce “skip”), the company of Dick Hardt, who made the presentation I linked in my last comment

    Just as example, websites like technorati or the blog platform wordpress have integrated openid as a authentification method, allowing you to share your your identity across websites

    (and I apologize because in fact I wanted to post this more recent presentation :

  5. Erlend

    I always use sFTP when possible, and all my websites use client-side encrypting when logging into a secure area(Javascript). SSL would be beter, but that is not always an option!

Leave a Reply

Your email address will not be published. Required fields are marked *