There are multiple vendors that offer so-called "secure messaging" services, designed to allow secure e-mail without the need for technology such as PGP, S/MIME or strict TLS between mail servers. The one I've been looking at is Mimecast's "Secure Messaging" service, but others are available.
Typically, instead of the content being embedded within the e-mail, it's uploaded to the vendor's servers, and the recipient is sent an e-mail advising them that they have a secure message waiting for them. The e-mail contains a link to a portal which allows them to view the content.
Access to the portal is via HTTPS. This ensures encryption during transit, which otherwise may not be the case if the content was embedded within the e-mail itself.
Access to the portal is protected via a username and password, which is designed to ensure the content can only be accessed by the intended recipient. If the recipient has not previously used the service, they are e-mailed a temporary password, which they must change after their first login.
Now, if the temporary password is delivered via the insecure channel (i.e e-mail), isn't that a flaw in the system? If an attacker was attempting to eavesdrop on the e-mail (presumably the threat this is designed to mitigate), then they wouldn't get the content, but they would get the password, which they can then use to access the content (assuming they get there before the intended recipient who would reset the password). Isn't that somewhat analogous to Alice sending Bob a symmetric key in plain text immediately before sending the cipher text?
I appreciate that the risk only applies when:
- It's the first 'secure message' sent to that recipient as they will have set a password after that
- The intended recipient has yet to log in and reset their password (may never happen if they never read the message)
So, am I right in my identification of the flaw, and is it just a limitation of the design, i.e it has some limitations in exchange for ease of use/flexibility?
I did wonder whether the Mimecast service has an option to allow you to deliver the password to the user over a separate channel (e.g phone) to improve security, but I haven't seen anything like that in the documentation so far (I've yet to actually trial it).