You give out your passwords every day
14 Feb 2007If you’re allergic to acronyms, don’t read on. I’ve reached an all-time TLA/FLA density high in the following article!
THE 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)
Even 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.
SOME SOLUTIONS
- 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. - 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). - 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!
