Bad pun intended.
Let’s take a moment of silence to lament this terrible practice. I registered for a site today… jumping through the typical hoops required to get to the goodies I wanted in the first place. The site operator decided to use an email validation system. After filling in the typical registration form I hopped over to my email and checked for any new messages in my inbox.
There are three possibile destinations for a validation link email – my inbox, my spam folder or it never showed up. It did show up… another hoop was successfully jumped.
Nothing unusual so far… until I opened it up and saw my user ID and password in plaintext. EMAIL IS NOT SECURE!
So let’s break it down. First here’s a very basic graphic of how this flows:
Hopefully when you are filling out your registration form your connection to not.secure.com is https. To check this just look in the address bar of your browser. If the address starts with https:// it is secure.
The site operator’s server does some crunching on the form data you submitted. It then looks up the IP address for the domain of the email address you supplied using DNS and initiates an SMTP connection with your email provider. SMTP is unencrypted. Data is sent in plain text.
At this point the site operator makes a bad security decision and decides to include your username and password in the email message.
Your message has made its journey and is about to land on its final hop — a server for your email provider. Let’s take a closer look at what happened between Step 2 and Step 3.
Now you can see on the diagram that I have spelled out a number of SMTP “hops” – and a cloud. That’s because when data moves between two machines on the Internet there is an arbitrary number of intermediate machines creating a path or route.
We can get a feel for this by using the command traceroute (or tracert on Windows). In this example I’m showing the route from this blog’s server to tema.ru – the blog of Russian designer Artemy Lebedev.
traceroute to tema.ru (126.96.36.199) 1 << My gateway >> 2 core1-aggr301a-2.ord1.rackspace.net (188.8.131.52) 3 vlan901.edge1.ord1.rackspace.net (184.108.40.206) 4 xe-7-1-0.edge1.Chicago2.Level3.net (220.127.116.11) 5 vlan52.ebr2.Chicago2.Level3.net (18.104.22.168) 6 ae-6-6.ebr2.Washington12.Level3.net (22.214.171.124) 7 ae-5-5.ebr2.Washington1.Level3.net (126.96.36.199) 8 ae-41-41.ebr2.Frankfurt1.Level3.net (188.8.131.52) 9 ae-72-72.csw2.Frankfurt1.Level3.net (184.108.40.206) 10 ae-31-89.car1.Frankfurt1.Level3.net (220.127.116.11) 11 18.104.22.168 (22.214.171.124) 12 bor-crs-1-be3.spb.stream-internet.net (126.96.36.199) 13 m9-crs-1-be1.msk.stream-internet.net (188.8.131.52) 14 m9-cr02-po6.msk.stream-internet.net (184.108.40.206) 15 Caravan-m9.msk.stream-internet.net (220.127.116.11) 16 v815.th-2.caravan.ru (18.104.22.168) 17 www.mk.ru (22.214.171.124)
So in this case the path is 17 hops.
The important matter is that it only takes ONE security breach on any piece of equipment along those 17 hops for your credentials to be compromised.
You open your inbox and – shock! horror! you see your credentials carelessly emailed by the site operator. You immediately compose an email to them and link to this article to show them the error of their ways.
To be fair – this same logic applies to the connection between you and any web site. When accessing the web your data follows the same long pathways to and from servers.
Users – When moving sensitive information around online a good rule of thumb is to use https or a password protected zip file or don’t do it at all.
Site operators – Stop the irresponsible practice of using http and email to move sensitive data.