Email - Your Biggest Security Vulnerability

Email.  Most probably your biggest security vulnerability that you didn't know about.

Email is ancient.  The core of how email works and how your email is transported from you to it's recipient was designed nearly 40 years ago, in 1982 (SMTP - RFC821).  It relies on your email being transported around in plain text from server to server in a manner you have no control over.

Problem One: Email is unencrypted and PLAINTEXT

A good analogy would be to compare your email to sending a postcard through the regular post.

Although forget about Royal Mail for this analogy - imagine all the post offices and sorting offices and delivery vans are all independently owned, all moving post between them.

You write your postcard (email) and once you've finished writing it and putting all your confidential information on, you pop it in the nearest postbox (represents hitting send and your email leaving your computer/phone/tablet and going to your email/internet provider's SMTP server where it gets queued for sending).

Next your postcard travels to a sorting office where it's inspected and then put in a pile with other mail also going to Domainname City (MXLookup - this is where the mail server decides which other mail server it should send the email to).  The sorting office gets their 3rd-party couriers to take the pile of mail to Domainname City (represents the fact that the plain-text email must be routed through other networks).

The couriers drop off the postcard with the other mail at Domainname City Post Office.  Here it is sorted and then delivered to the recipient's fancy stand-alone mailbox at the end of his drive [analogy works better with US-style mailboxes!](representing the MDA - Mail Delivery Agent/Local Delivery Agent delivering the email to the recipient's mailbox) where it will wait until our friend "checks his mail", then he will find our plaintext postcard waiting for him to take home/download.

This really is no exaggeration.  At all points along the way your email is - like the postcard - able to be inspected and read by ANYONE along the way.

Now, how many times have you just sent a quick email saying something like;

"Just use my account - username blahblah password YELLEDBLAH secret question Mr Fluffy Pants"

Or, even worse but again - how many times have you done something similar?

"Subject: EBoardingPass-xxauto01 Flight Number xxx-xxxxx Booking Number HOL1DAY001

Please find attached scan of my passport"

Or, another simple example that pretty much everyone will fall foul to at least once and probably over and over and over again, never realising any mistake:

"Subject: Payment Declined for usual purchase

>> Hi Fred, unfortunately your bank debit failed this month.
Hi Tom, please try my Masterskim Credit Card, 99905417 exp06/66 CVV123"

Unfortunately, it just gets worse when we turn our attention from the security of the content of the email to the security of the sender and the question of identification.

Problem Two: Email can be sent BY anyone AS anyone

 When an email is sent, part of the information contained within it is a <from:> address.  This address is supposed to tell us who the email is from (surprise surprise).  However, as you've probably correctly guessed, this can be forged.  And as you've probably also guessed, it is extremely trivial to forge.  In fact, almost the only two things any mailserver will check about a <from:> address is whether or not it should relay mail from @domain.com and whether that domain is blacklisted (both decisions based around combatting the spread of SPAM - nothing to do with actually checking the validity of addresses or identities).  Just because an email says it is from passport.office@gov.uk doesn't mean it's from the Passport Office.  It doesn't even mean it's from a gov.uk address.  Unlike the URL in an address bar in a web browser, the contents of an email <from:> field is no indication as to the real source of the content.

As well as the standard, run-of-the-mill phishing scams that are fairly easy to spot and avoid, with just a little real-life social engineering this is still a glaringly big security hole.

Take Mr Stocktrader-Smythe.  An email pops up in his inbox from his mate Bill Insidetradington-Scott telling him that MyBentCompanyInc's shares are going to go through the roof and to purchase £10k of shares on his behalf.  Mr Stocktrader-Smythe duly purchases £10k of shares, plus he moves some of his own personal portfolio to include a big chunk of MBCInc shares.  Thing is, Bill never sent any email.  It was Phil Crookbent who has his own agenda - manipulating the MBCInc share price? Destroying Stocktrader-Smythe's portfolio and wasting Bill's money. Who cares? And unless Mr Stocktrader-Smythe replies to the email, no-one might ever know or pick up on the spoof email.

Or take Jan and Dave; they've just posted on Facebook that their campervan is loaded and ready to go for their Scotland roadtrip tomorrow, and neighbour Mike has just commented reassuring them that he'll water plants and keep an eye on the house for them while they're away.  Suddenly Jan and Dave get an email from Mike asking them to leave a spare key under the garden gnome....

This is address spoofing and it is amazingly trivial to do.  Calling it simple is making it sound more difficult than it actually is.  It can be so easy to forget this and to confer trust when there is none just from the sight of a familiar name.

Problem 3: Anyone can intercept and change an email

Absolutely anyone could have intercepted our email and changed a couple of things here or there; heck they could rewrite the whole bloody thing and we wouldn't know.  Imagine Mr Stocktrader-Smythe sending an email to buy 20,000 shares, only Mr Insidetradington-Scott intercepts it on the company mail server and changes it to 20,000,000 shares...  We need a means of protecting the integrity of our email.

Solving the problems in a Pretty Good Way:

In this day and age we need a way of making our emails confidential so only the intended recipients can read what we've written, and a way of proving that we are who we claim to be.  Unfortunately the 39-year-old email specification doesn't make provision for these things but luckily for us PGP (Pretty Good Privacy) and OpenPGP with RFC4880 do make provision for exactly this.  I wrote a small bit on Gnu Privacy Guard (GPG) and how to do the basics.  It's going to be a GPG/PGP Sunday!


Read Part 2 (Part 3 really) of this here where we discuss how to secure email with PGP, and how PGP can build trust and confidence,

Maybe.  I do need to reboot myself at some point...