19

We have a vendor who sends us "secure" messages. The messages come as an email message that contains a link to an SSL encrypted website that has the real message. There is no username/password on the linked site, or any other form of authentication as far as I can tell.

I'm sure they do this so they can check off a box on some compliance checklist, but I want to know, can this truly be considered secure?

My thinking is that since the link itself is sent in the clear, then it is no different than if they had sent the message in the email in the first place. Any attacker who might be able to gain access to my email, either at rest or in transit, can capture and then visit the link.

So is this secure, and if it is at least at some level, what security problems might it be solving? Are there other security measures, not readily evident, that they could be taking to ensure only the original recipient can use the link?

Because several answers have mentioned it. In this case there is no IP address white listing or behind the scenes proxy authentication.

Also, there is an expiration date listed on the link, but it is fairly far in the future.

matthew
  • 1,090
  • 1
  • 7
  • 10

6 Answers6

20

Since raw emails are not encrypted, what you can read in an email could have (conceptually) been read by anybody. However, to read the email, the attacker would still have to connect to the HTTPS server, which leaves tracks (the IP from which the attacker connects will be known to that server -- of course, that IP will probably be that of a Tor exit node). The link-in-email system prevents passive-only attacks: the attacker has to send some IP packets of his own at some point. This is not a huge increase in security...

Usually, promoters of solutions such like the one you describe do it for security, but not your security. They want to know when the email was read. This is a preventive measure against people who read embarrassing emails and then claim they never received them. It won't be much of a proof, but it may be sufficient to counter evasive maneuvers from some uncooperative co-workers.

If you want a system which guarantees that only a specific individual will be able to read the email, then you need to define what specific individual you are thinking about. In the world of computers, everybody has a computer, and they are not immediately indistinguishable from each other. People have physical identities which are not part of the computer world, so a link must necessarily be made at some point. Standard secure email solutions like S/MIME do that through a public-key infrastructure: a recipient is defined by being "the guy who controls the private key corresponding to the public key which is in that certificate". This moves the problem of physical identification to a single preparatory step during which the certificate is issued.

A possible model is that you met the recipient in person once, and he gave you his business card; on the card is printed the fingerprint of his OpenPGP public key -- you then find the key from a public key server, and check the fingerprint. There are many variants on this concept, but a non-computer physical contact is necessarily involved.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    Good point on the passive-only attacks and on tracking. Although, in this case I'd think they be more concerned with preventing a data breach than merely identifying who caused it after the fact. – matthew Mar 11 '13 at 21:23
11

I'd like to add this to what The Bear has already said

This method adds almost no security at all. Why?

Exposing the email with the link = Exposing the real message

This is almost the same as sending the text in the same email used to send the link. Then why are they doing this? You might ask. Here are some possible reasons:

  • Delivery and reading confirmation: Clicking the link and viewing the page proves that you've read the message.

  • Plausible deniability: After the first visit, the message on the server can be removed and cannot be shared later with anybody else without a doubt about the message's source. (Even if you take screenshot of the message, save the page, keep the email with the link. The sender can always deny and claim that you can easily fake all of the above)

  • Access control: The server hosting the message might be configured to allow white-listed IP addresses to view the message. (Even if your email account was hijacked, the attacker has to be in the white-listed range to view the actual message)

Community
  • 1
Adi
  • 43,808
  • 16
  • 135
  • 167
8

One this that hasn't yet been mentioned is that this approach can improve security from a different angle: rather than addressing privacy concerns (which it clearly doesn't), it definitely helps in establishing verifiability.

Anyone can send an email and forge the headers to make it appear to have come from your vendor, but (presuming their systems are adequately secured) content hosted on their site can be trusted to be genuine.

This is especially important when phishing is considered. It is much easier to train people to only trust content they access through the "Secure Portal" rather than in the email message directly tan to try to get them to differentiate legitimate and phony emails.

Michael C. O'Connor
  • 181
  • 3
  • 3
    +1. In more standard terms: this method doesn't confer *confidentiality*, but it does help ensure *integrity*. (Though I'm less sure about your last paragraph. How hard is it to send an e-mail with a link to a fake site that resembles the real one?) – ruakh Mar 12 '13 at 06:41
5

One trick I've seen before is a single-use download link. If you visit the link, you cannot download the file after the first attempt. If you get there and the file has already been downloaded before you try it, then you have detected a compromise. Hopefully this site records the address and time of downloaders at a minimum.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
4

The problem the sender of the email is trying to solve is data in transit and data at rest, specifically, a copy of their email and the path it takes to get to it's destination. When you log into one of these "secure" solutions, Tumbleweed is an example, you are simply logging into a server on the sender's network. The data never left the sender's network and thus was not unprotected in transit, nor is it unprotected at rest, like when it is sitting in your inbox in your webmail account.

Additionally, the link that you were provided by the sender was only sent to your email address, so presumably, only a person with access to your email would have access to that link. Hopefully, the link generation algorithm is designed properly and is safe from an attacker having the ability to predictably brute force the links and search for known messages. Also, this service assumes that you use a strong password on your email account.

Some of these "secure" email solutions do have the ability to create a username/password combination to protect the email.

Joe Gatt
  • 162
  • 8
  • 1
    If they're assuming my mail is secure enough for the link, what do they really gain by not sending the data? Losing the link is the same as losing the data. – matthew Mar 11 '13 at 17:12
  • @matthew See the second point in Adnan's answer. If they maintain control of the data, they can delete it, and they can control when it's deleted. – Xander Mar 11 '13 at 17:29
  • @Xander: no, they don't get to delete the data, they only get to stop hosting it. The data may have been read and archived by others. – jmoreno Mar 11 '13 at 20:42
  • @jmoreno Of course, that's a given. More specifically they get to delete the original data. – Xander Mar 11 '13 at 20:45
  • @jmoreno in some cases the information itself might be useless. Here's an example, "A" sends email (single-use URL) to "B" saying "I have stolen money from X". Even if "B" keeps a copy of the email (containing the link) and even if "B" takes a screenshot/saves the page, "A" can always deny and demonstrate how the screenshot and the page could be fake, nobody can prove the that "A" really said that. On the other hand, if the email was "I've stolen money from X and here's a video of me doing it", even if "A" denies sending the email, B still has the video to prove A's involvement in the theft. – Adi Mar 11 '13 at 22:55
  • @Xander: I mentioned it, because some people might use it under the impression that they do get to conrrol the lifetime of the data. Like some users of Snapchat. It's not secure, it's just generally not worth the bother. – jmoreno Mar 12 '13 at 02:36
  • @jmoreno Cheers, it's always better to be explicit, so all's well. – Xander Mar 12 '13 at 03:22
2

I would suggest that without knowing the entire flow, it shouldn't just be assumed that this is security theater; however, it is also entirely possible that it is. If you want to confirm that these are actually secure in the way your company intended, ask your infrastructure team if anything goes on behind the scenes.

The term “secure” could be being used in terms of non-repudiation; the “email” you access via the link is guaranteed to be unaltered between their server and your browser. It is also possible that a guarantee is provided that the email never changes, such as by having a trusted third party store the original “email” they sent. This would be to the benefit of both companies, assuming that the only security necessary is that both parties have the exact same information. Clearly, this isn't sufficient if the security was to protect privileged information.

It could be that your company has a set of static IPs assigned to it, and the other company has a white-list of those IPs, requests coming from them being allowed access. Internally, your company could achieve a separation of concerns with this system.

Finally, it could be your company performs the login/handshake automatically on your behalf if your connection goes through a proxy when leaving the internal network. This could be anything from any company employee can see the secure emails (like above IP example) to the proxy doing a lookup for your email address based on your user ID and passing that to the other company’s server as part of the handshake to determine if you in particular have the right to see that email.

I hope that a single sign-on approach (the last example) is the reason that it appears as if you require nothing but a link to access this secure information. Your question does make me consider if we should be somehow conveying to users if their ability to access an internal application without login was due to single sign-on or that the information is intended to be public within the organization. Or maybe they expect it internally but would want some indication for third-party only? I suppose that is a UX issue.

Matt
  • 161
  • 2