3

I'm looking at implementing Office365 Message Encryption for our organization. My question is this: is it actually more secure than regular (unencrypted) email for messages sent to users outside the organization?

According to this page, external users can receive a one-time passcode in order to view encrypted messages. However, this one-time passcode is also sent via email, so assuming a MITM attack, couldn't the attacker simply intercept the one-time passcode and decrypt the message?

Let me know if I'm missing something or if this is just more marketing hype from MS...

ebarrere
  • 330
  • 1
  • 3
  • 15
  • RE: the MITM avenue. The *service* sends the OTP email, it doesn't come from the *sender*. If the recipient account is compromised, then it's compromised. I would have to assume that this service *requires* SMTP START TLS, rather than the default Opportunistic TLS (for compatibility). – blaughw Mar 23 '16 at 19:16
  • I'm not assuming a compromised account, I'm assuming a MITM somewhere, sniffing packets between two SMTP servers. Sure, if the service could _force_ STARTTLS along the whole path then that would fix the issue, however in that case encrypting the message in the first place seems moot. I just don't see how this service provides security _above and beyond_ that afforded by STARTTLS. – ebarrere Mar 23 '16 at 20:29
  • Rights Management can provide Do Not Forward, etc. capability. I think that encrypting the actual message provides more of a regulatory compliance feature. The OTP-via-email seems like the secondary method to retrieve a message, while signing in with a Microsoft Account (Live ID) is the primary. I think you are right, STARTTLS enforcement for known-capable partners is a better practice, in general. – blaughw Mar 23 '16 at 20:51

2 Answers2

2

Your concern does have some merit. However...

The one time passcode email doesn't specifically identify the message it goes with. So just having the OTP message does not tell you much. That being said if the person only has one encrypted message in their mailbox, plus the matching OTP email, an attacker can put 2 and 2 together.

Furthermore, the code is only valid for 15 minutes. So the window of vulnerability is quite limited. An attacker would have to be actively intercepting your email AND responding to it, not just passively dumping packets for analysis later.

If you are still not satisfied with the security, you can disable the one time passcode via PowerShell:

Set-OMEConfiguration -OTPEnabled $False

That will require the recipient to use a Microsft account, which is setup independently, but more complex to use.

myron-semack
  • 2,593
  • 19
  • 17
  • I use the OTP quite a bit - if they don't already have a MS account linked to the address I sent, it can get messy, and it doesn't make it any more secure (it might do the opposite if they get frustrated and then choose not to participate). – Jesus Shelby Mar 24 '16 at 00:35
  • 1
    MS account is "more secure" with regards to the OP's concern about the passcode being sent in a plain text email. In the case of a Microsft account the password isn't being sent in an email. (For the record I think the OP's concern is overblown.) – myron-semack Mar 24 '16 at 00:40
  • Imagine I've compromised an SMTP server somewhere between O365 and my external user. What's stopping me from (programmatically) scanning each incoming message for the text designating an encrypted message, requesting an OTP, intercepting the OTP and deleting it (without sending it on) after decrypting the original message? If this is technically possible then the system is no more secure than standard email, it's just more complex, and that's security through obscurity. Am I saying it's likely? No. But I'd like to know if I'm paying for something more than another layer of complexity. – ebarrere Mar 24 '16 at 21:53
  • @ebarrere Yes the attack you describe seems possible. There might be a captcha to get an OTP (don't remember it's been a while since I last used it). You can mitigate the attack by disabling OTP and requiring an account to view the message. – myron-semack Mar 24 '16 at 23:55
-1

It is certainly more secure than sending a plain text message. Once a message leaves your servers you can not be sure that the transmission is secured with TLS thru the entire journey (Unless you set up a direct trust and force TLS between two endpoints). You have to assume your message is in the clear once it leaves.

With the encryption service - Microsoft allows you to encrypt the message and send to a recipient. The recipient can read the message by accessing it thru a web portal or mobile application. They have an option to sign in with a matching Microsoft ID (it must match the recipient address) or use a one time pass code that is generated and sent to the recipient address.

Because you do not own and can not dictate the terms from which the recipient will receive and open the message you must TRUST that they are the person you are sending it to. If the recipient account is compromised than they may be able to open the message. This includes some man in the middle scenarios where the means to access the message (the portal link and encrypted message), as well as snagging the key.

You can try to layer in additional features like TLS (but you can't guarantee it) for transport. You can also be sure proper SPF, DKIM, and DMARC records configured (but these still rely on recipient honoring them) to help.

If you want end to end encryption you need to rely on S/MIME or something like PGP. But even with these tools you can never be 100% sure of who has the private key or if the recipient was compromised.

TLDR; If you can't or don't trust the person you are giving access to data, than no technical controls can give you what you are looking for. Users will forever be the biggest security hole.

Jesus Shelby
  • 1,294
  • 9
  • 14
  • Sorry the service does verify the recipient, however like any credential based service, noone can know if the identity has been compromised at the recipient end. – Jim B Mar 24 '16 at 04:15