email unsecure

Simple list of reasons why email is insecure

Email has been around for decades, and is used daily by most working people. We read and send emails from our phones, tablets and computers. But how secure is it really?
Not as secure as you think

  • A user could have your email stored in their inbox, when their account gets compromised.
  • Devices/servers with stored emails could be stolen.
  • You have no control over where your email is forwarded.
  • You have no control over where your emails are stored, you are placing a lot of trust in the admins running those servers.
  • Emails should have a temporary lifespan, but they may be stored permanently, causing problems for you in years time.
  • Emails can be sniffed in transit, since they are not encrypted
  • It is easy to make emails go to the wrong machine by altering the DNS.
  • There a viruses which check the contents of emails on infected devices for passwords, account details and other useful details a hacker could use.

KeithS writes:

The simple and deepest answer is that SMTP (Simple Mail Transfer Protocol), which handles the sending of mail from client to mail server and between mail servers (other protocols such as POP3 and IMAP are typically used to retrieve mail nowadays), was originally designed for use in the ARPANET, which operated in a time when anyone who could use it had a security clearance in the first place. As such, SMTP fails at all of the four key aspects of information security, because when it was designed whose concerns were handled by alternate means, and the protocol has never been updated to attempt to do so.

  • Confidentiality: SMTP e-mails, by default, are not encrypted during transport or at any other time. Anyone can read them while they are being transmitted along an unencrypted channel, or while they are stored on either party’s mail servers awaiting retrieval.
  • Integrity: SMTP provides no more error checking than the transport layer protocol used to send it. That is woefully inadequate when you want to ensure that nobody has tampered with the message; TCP is designed to help ensure that the network itself didn’t cause data corruption or loss; it’s trivial to change the contents of TCP packets enroute if you have control of one of the network nodes along which they’re sent.
  • Authenticity: SMTP has no means to verify that the listed sender is actually the person who sent it. Someone halfway across the world can create an e-mail with your address in the “From” field and nobody will know the difference.
  • Non-Repudiation: Because you can’t verify that the person listed as the sender actually sent it, or that the e-mail itself is the original content sent by that sender, that person can very cogently deny that what you received is what they sent, or that they ever sent you an e-mail in the first place.

The addition of the SSL/TLS security handshake into SMTP, creating SMTPS, provides confidentiality on the first leg of the trip (from your computer to your “home” e-mail server). That’s all; you can’t enforce confidentiality along any other leg of the trip, and the other three aspects of InfoSec are unaffected.

To give you another idea, here’s a more dramatic version explaining one of the problems with emails from Tom Leek:

Context: an e-mail server, alone in a bay, somewhere in Moscow. The server just sits there idly, with an expression of expectancy.

Server:
Ah, long are the days of my servitude,
That shall be spent in ever solitude,
‘Ere comes hailing from the outer rings
The swift bearer of external tidings.

A connection is opened.

Server:
An incoming client ! Perchance a mail
To my guardianship shall be entrusted
That I may convey as the fairest steed
And to the recipient bring the full tale.
220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)
Welcome to my realm, net wanderer,
Learn that I am a mighty mail server.
How will you in this day be addressed
Shall the need rise, for your name to be guessed ?

Client:
HELO whitehouse.gov
Hail to thee, keeper of the networking,
Know that I am spawned from the pale building.

Server:
250 mailserver.kremlin.ru
The incoming IP address resolves through the DNS to “nastyhackerz.cn”.

Noble envoy, I am yours to command,
Even though your voice comes from the hot plains
Of the land beyond the Asian mountains,
I will comply to your flimsiest demand.

Client:
MAIL FROM: barack.obama@whitehouse.gov
RCPT TO: vladimir.putin@kremlin.ru
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.
Here is my message, for you to send,
And faithfully transmit on the ether;
Mind the addresses, and name of sender
That shall be displayed at the other end.

Server:
250 Ok
So it was written, so it shall be done.
The message is sent, and to Russia gone.

The server sends the email as is, adding only a “Received:” header to mark the name which the client gave in its first command. Then Third World War begins. The End.


Commentary: there’s no security whatsoever in email. All the sender and receiver names are indicative and there is no reliable way to detect spoofing (otherwise there would me much fewer spams).

Make sure you don’t send any important info via email, and if you receive any passwords via email change them as soon as possible.

If you have anything you would like to add please leave a comment below.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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