As long as the Internet has been around....and still no secure e-mail?

As long as the Internet has been around....and still no secure e-mail?

Summary: I finally had a chance today to go back and check the comments on my post about how vulnerable the password recovery schemes of many supposedly secure Web sites are. See Are you sure you're the only one with access to that password you recovered?


I finally had a chance today to go back and check the comments on my post about how vulnerable the password recovery schemes of many supposedly secure Web sites are. See Are you sure you're the only one with access to that password you recovered? Think again. I asked readers (and you're free to still answer the request) to let me know if they know of Web sites that, via e-mail, will send you your actual password after you click the "I forgot my password" link (or something like it). The technology exists. It's just not found in every e-mail client nor are businesses prepared to alter their processes to handle this approach. One reader commented that does this. But when I tested Amazon's password recovery process, I found that the e-commerce giant actually does the right thing by sending you a link to a Web page where you can reset your password. The link is an HTTPS link (instead of the standard HTTP) which means that transmissions between you and the Web page are encrypted. In other words, your password isn't crossing a network in clear text where it's available to prying eyes.

Another reader made a good point about how, compared to the old days of single-bus networks, it isn't that easy sniff password traffic off a local area network (LAN). That's because most LANs use network switches instead of the old network hubs as a means of connecting servers and workstations to the LAN, and eventually the Internet. With the old 10Base-T twisted pair Ethernet hubs and the coaxial cabling that preceded them, it didn't matter what port or part of the coax a workstation or server was connected to. Every port acted as a passthru for pretty much all LAN traffic.

With the Ethernet switching hardware found in most wiring closets today, each port is like a private LAN that only passes traffic going to and from the server or workstation that's connected to it. In other words, it can see password traffic that addressed to some other destination. The reader points out that it's not a perfect solution because network administrators (some of whom may harbor malicious intent) may still have access to unswitched ports or areas of the LAN where all traffic is consolidated. But at least the pool of people that have that kind of access is limited in size.

Perhaps the most interesting response however, came from "pradecki" who titled his/her comment with Hence, secure email is way overdue. Wrote pradecki:

It still boggles me why servers don't do a public key cryptographic handshake/connection encryption when they transmit email. It doesn't take any new technology than what already exists. when user a logs into server A to send message to user b using email server B if they are concerned about security will use a secure connection between themself and their email server. However the security hole exists in the communication between the two email servers. if the two servers used a secure connection to transfer the email messages then the entire problem of forget password script emailing out plain text password would be mitigated.


The part about the technology already existing is what really drives pradecki's point home.

What's mind boggling to me is that the world of engineers is off solving some new problems with new technologies instead of addressing the nagging problems that still hound us: problems that are easily addressable with existing technology that needs no invention.

Regarding secure e-mail, here are the two biggest problems that need solving now. First, with any e-mail client, the option to send e-mail securely should exist. When you or I pick that option, the recipient's e-mail client should be able to automagically decrypt it. The technologies for doing this exist and, in fact, there are some e-mail systems that behave in this way. But they're not interoperable with all other e-mail systems. For this to work right, it has to work for everybody much the same way non-secure e-mail works for everybody today. It needs to be as simple as the sender pressing a "send-secure" button and the recipient(s) being able to open it on their end just as though they were opening any e-mail. No hoops to go through.

The second problem that needs solving -- a variant on the first -- is a standard fully interoperable way of applying digital signatures to e-mails. One that not only works technically, but is accepted in a business context as well. If it weren't for this one glaring hole in the e-mail system, I wonder if fax machines would even exist. The only time I need a fax machine these days is to fax a document with my signature on it to someone. In dealing with technology vendors, before they'll pre-disclose me on some news, I have to sign an non disclosure agreement. But here's the rub. They get to do the easy thing: they get to send me the NDA as an attachment to an e-mail. On my end however, I have to detach the attachment, open it up, print it out, sign and date it, and finally, find a fax machine so that I can send it back. Talk about productivity killers! This has to be one of the biggest ones. When agreements come in the e-mail like that, I should be able to digitally sign them and send them back without ever leaving my desk.

Again, the technology for doing this exists. It's just not found in every e-mail client nor are businesses prepared to alter their processes to handle this approach.

Pradecki is 100 percent right. Secure e-mail is long overdue. Looooooong overdue.

Topics: Servers, Browser, Collaboration, Networking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • And, securing email would also make it harder for Spamers to operate.

    Really, it would make it virtually impossible for spammers to operate if we had secure communications between know email servers.
  • PGP

    This does not relate completely to password retrieval, but PGP (pretty good privacy) has been around for over 10 years now. It effectively encrypts whatever messages you send, with a variety of options.
    • That does not help if it is not universally avaiable so you can send it to

      anybody and be sure that they can decrypt and read it. We also need to secure the communications between email servers to shut down spammers and phishers.
    • Much easier than PGP is S/MIME

      Much easier than PGP is S/MIME. S/MIME is pre-installed in every single email client. X.509 Digital Certificates can be obtained for free at places like Thawte.
    • X-ASVP as key distribution

      The problem with current e-mail encryption systems is key distribution. Server to server encryption is fine, but it forces all e-mail senders to use specific mail hosts. Client to client systems require trust in a paid Certificate Authority pre-configured in the e-mail client. There is an Internet-draft out currently (posted on ) that proposes a way to standardize key distribution based on a URL search-path derived from a recipient e-mail address. It would not take much to extend e-mail clients to use X-ASVP search-path to locate PGP keys (web of trust authentication) as opposed to CA verified keys (read as per key cost).
  • It's not difficult

    I regularly sign my emails using gpg using pgg on Gnus, but I realize that's a bit challenging for the majority of folk. I also have Thunderbird set up with Enigmail to use gpg, as well, and I use FireGPG in Firefox to encrypt or sign emails sent through Web email systems. Both seem to work fine. Receiving signed (or encrypted) emails is easy; sending them requires me to type my passphrase, but that's seemingly both a good idea and configurable.

    Have you seen It seems designed to be an easy way for people to get started. I use WinPT, which generally makes things such as encrypting or decrypting files or managing keys relatively easy. See also for some of my online comments about the subject.

    The primary limiting factor I've found is the paucity of folks with gpg public keys.
    • Still, it is not a universal standard. We need a simple "send secure"

      option that is available on all clients. But, we also need the servers secured to shutdown spammers and phishers.
    • Just your message says "difficult"

      With all due respect, no one should have to know or care about gpg, pgp, Gnus, FireGPG, Enigmail, etc. etc. etc. I'm thinking one extra button or link at the top of my email client that says "Secure Send" (or "Send Secure"). Anything else and I might as well learn how to COMPILE and MAKE (if you get my drift).

      Thanks for replying.

      • Easy as pie

        Point and shoot / easy to use secure email solutions are relatively new on the scene, but a few exist. Big name telcos such as AT&T and Verizon offer an extremely easy to use secure email product that that while based on standards such as PKI, X.509 and S/MIME, is designed for common people (read non-technical) to use. Google and check out Echoworx for more details.
  • About signing and faxing documents...

    Have you tried, converting your ndas and contracts to pdf and digitally signing them?

    You get both a digital signature and your actual ink signature placed on the document. Then I just use my online fax service to send it out to their fax and i email a pdf back to them...about a min. total time.

    The bonus, the fax service I use also delivers my faxes to my email as pdf, and is an 800 voicemail which delivers voicemail mp3s to my email. There are lots of similar services, pick your favorite and get productive.

    Paper free and productive.
    Give it a shot.

    Hopefully we get secure email soon, it almost boggles the mind.
  • Regarding your productivity killers...

    David, I have found that a Tablet PC is a great way to avoid the issues with having to sign digital attachments and faxing them back.

    It's easy because you can use the pen to sign the attached document, save it, and then either email it back or if you have to fax it, create a new fax in outlook using any of the fax services that integrates Office.

    Works great. And if you don't like Tablet PC's get yourself a small digitizer table and use the pen from that to sign the document.
  • It's not possible

    It would take another decade for all the mail server in the world to change to secure communication, and in the mean time, you would have no way of knowing if the mail server you are sending to IS secure or if the recipient IS using a 'secure capable' client.

    Servers would have to have a way of checking if the mail server they are sending to has secure, so more requests, and then it would have to fall back to plain text if it didn't.

    Can you imagine the slow uptake? And then there would be options like "Only send to secure servers" which would mean half your mail (or more) would never end up being recieved, and users would boycott it.

    Sad but true, secure email will never be mainstream.
    • It is possible, but need e-mail to URL conversion

      Sure it's possible, but you need to know how to locate an e-mail recipient's preferences when all you have is their e-mail address. What you need is an e-mail address to web address converter algorithm. ( Google: X-ASVP )

      Look at this example X-ASVP "meta-document".
      It tells you that PGP is supported by the client and gives you the public key. Who can post to that URL? The owner of the recipient e-mail address. How did you find that URL? The X-ASVP search-path algorithm in Internet-draft posted at
  • Not only does the technology exist...

    But it's often just a configuration option on the server to enable it. I have TLS/SSL enabled for SMTP and IMAP here. If you want to send or read mail using my servers, you have to authenticate over an encrypted connection and send/receive your mail on an encrypted connection.

    This is nothing new. Sendmail, postfix, UW-IMAP, and goodness knows how many other email server packages have had this capability for years already. People just have to use it. I suspect the reason it has had such poor uptake is that before administrators will enable it, users have to request it. And before users will request it they have to know that it's available and what it can do for them.
    • You missed the point

      Secure communication with YOUR email server is fine, and if it's an email to someone else on that email server, again, fine. But the communication between YOUR email server and SOMEONE ELSES email server is NOT encrypted.
      • No, you're completely wrong.

        1. No he didn't miss the point; the most common way to hack email is in the last 100 feet whether that's through a wire (through layer 2 hijacking) or wireless LAN connection.

        2. Sniffing traffic between two SMTP servers is REALLY difficult to pull off unless you have access to the ISP's infrastructure. In fact if you could hijack someone's email server, you can actually steal their domain name or obtain SSL certificates on behalf of the actual owner.

        3. Server to Server encryption is actually quite simple and requires nothing more than enabling SSL or TLS on the SMTP server and obtaining a $20 publicly trusted digital certificate on each server. I even have a tutorial here for Server administrators.
  • Sorry, SSL encrypted POP3 and SMTP have been around for a LONG time

    Sorry David, SSL encrypted POP3 and SMTP have been around for a LONG time and most ISPs even support it and all it takes is for the user to click a check mark and use a different port number. It's as easy as turning it on to get an encrypted point-to-point connection between the user and server. It?s all just a matter of user education.

    For end-to-end encryption, S/MIME has been included in just about every single mail client for a decade. All you need is a free Personal Digital Certificate from a service like Thawte on each end to enable authentication, non-repudiation, and encryption. I?ve asked people to get their cert so that I can send S/MIME encrypted email to them and back and they?ve done it just fine if they had a desire to do secure end-to-end email.
  • AT&T Mail Client Ports

    Regarding the port number changes for an AT&T mail client, David Berlind is right. I use Outlook and have been using the ports he mentioned for years. Works fine. One other point though that should be mentioned. If you access the AT&T mail servers, either inbound or outbound, by a provider other than AT&T, you also need to prefix the standard AT&T server names with the letter i. Am not sure if that is true if your provider is actually AT&T but with other providers, such as Comcast or Charter, that change also has to be made.
  • Sending links via emails is NOT secure

    >> One reader commented that does this. But when I
    >> tested Amazon?s password recovery process, I found that the
    >> e-commerce giant actually does the right thing by sending you
    >> a link to a Web page where you can reset your password.

    You sure thought that sending a link is the right thing do to!! Be aware that people using phishing scams exactly want genuine requests to send such password reset or login links via email.

    Over phone conversations, Verizon and Cingular folks ask for so much private information thinking that they are making their system secure like that. They do not realize that a fake custmer service representative would use the very same means (which people would be used to) to get all your personal information.

    **My opinions do not necessarily reflect that of my employer**
  • error?

    Presume you mean "In other words, it can NOT see password traffic that addressed to some other destination.."
    [correction capitalized"