4 ms·

"Although TLS protected, the data in the tunnel runs to Microsoft in plain text". What? Not sure if this is a mistranslation but this makes absolutely no sense.

"Although TLS protected, the data in the tunnel runs to Microsoft in plain text". What? Not sure if this is a mistranslation but this makes absolutely no sense. TLS is encryption. Why would they further encrypt it "in the tunnel"?

Fischgericht 3y ago
What they are talking about is that your passwords are uploaded via HTTPS/TLS, so an encrypted connection, but what they are sending are you full passwords in plain text over it. https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/3/3/1/0/1/1/01-Traffic_Mitschnitt-330ad3a100639b8c.png?force_format=avif%2Cwebp%2Cjpeg&org_if_sml=1&q=85&width=610 https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/3/3/1/...
- quietbritishjim 3y ago
  For IMAP to work you need the original password, not e.g. a hash. Once you've decided to send the actual password, whether wise or not, the best you can do is encrypt it, and TLS does that. What else would you expect?
  - nhinck2 3y ago
    I would expect Microsoft not to be on the receiving end of my plaintext password.
  - Fischgericht 3y ago
    TLS is only transport encryption. The password will be transmitted in clear before and and after that transport. This is not at all comparable to other "store my passwords inside the cloud"-systems, where the passwords are encrypted and decrypted on the users' devices, without the encryption key going to the cloud provider - that's the way it's handled in Password Managers, Chrome Auto-Fill etc. And I would expect Microsoft asking the user for explicit consent "May we take your IMAP password and transfer it and store it in our cloud?" in easy to understand wording so people understand the consequences (for example getting fired for having punched a gapping hole into your employers security policies like "Don't share this password with anyone") That expectation would match the law in the EU. And in addition, inside the EU it would also have to guarantee that the password will only be stored on servers inside the EU, and not end up, for example, with the NSA. And even then it still might not be legal. And from a user's perspective: Certainly a big chunk of users that have been using email software for the last decades would assume that an email client installed on your PC is doing the IMAP access locally. There is no need for your IMAP credentials to go to Microsoft. Merging your local mail store from multiple sources inside the client is what email clients have been doing for the last 20 years. There is absolutely no need to move this to the cloud. Yes, my computer can handle merging email folders.
  - fulafel 3y ago
    Another reason to use something else than passwords with IMAP for authentication.
  - magicalhippo 3y ago
    I would expect them to at a bare minimum encrypt it using a temporary public key before transmission, in case TLS connection was MITM'ed, and I'd expect them to use those fancy hardware security modules (HSM) they have[1] to protect it on their side. [1]: https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/overview https://learn.microsoft.com/en-us/azure/key-vault/managed-hs...
    - weikju 3y ago
      It doesn't matter how well they protect it, they still have the credential, and they decrypt it in order to be able to use it, so for all intents and purposes, it's in the clear _for Microsoft_ (and whoever else manages to have access). This is not how it should be.
      - magicalhippo 3y ago
        Obviously, and this is something they should communicate clearly. But if they were to provide such a "service" I'd expect them to minimize exposure, including the steps I mentioned.
    - magicalhippo 3y ago
      I was tired and forgot to add they should first check if the IMAP server supports XOAUTH2, and in that case require that to be used. Still not a great solution but at least not passing the password around.
  - yjftsjthsd-h 3y ago
    > What else would you expect? I would expect user credentials to not be uploaded without giving an extremely explicit explanation and receiving informed consent from the user.
    - alt227 3y ago
      Also, the credentials have to be stored in plain text. M$ servers cannot auth with your IMAP host with a password hash, so they must be saving the plain text password somewhere which seems absolutely crazy to me.
      - AlexandrB 3y ago
        Next time there's a data breach at Azure, there will be fireworks.
      - thiht 3y ago
        No, that's just wrong. They can store these credentials encrypted with algorithms such as AES-256. No need to store them in plain text. This is actually standard security practice when you absolutely have to store a key in a way that you can use it later, such as a password or an API key.
  - xorcist 3y ago
    IMAP supports a multitude of authentication standards, including hash and key-like, so the above is not necessarily true, however it is unlikely that Outlook supports them. Client certificates are supported by both Thunderbird and K9, would prevent this type of issues. In the cloud first era, your value is derived from how much customer data is under your control. Not for resale primarily but for stickiness. It's like the dot com era, only for real this time.
    - lxgr 3y ago
      > Client certificates are supported by both Thunderbird and K9, would prevent this type of issues. How? Outlook could just ask you for your certificate (+ private key) and upload that.
      - xorcist 3y ago
        I should have learned not to underestimate ingenuity by now.
  - steve1977 3y ago
    I would expect that my local e-mail client is making the connection to my IMAP server. Not a connection to Microsoft servers which then in turn connect to my IMAP server.
  - dahauns 3y ago
    >Once you've decided to send the actual password, But you haven't. Microsoft has decided that for you - without telling you. The more I think about it - that's not even just a GDPR issue, it's blatant malware behavior.
bravetraveler 3y ago
Transit vs rest, maybe? I suppose they'd prefer it be not transferred at all, but if it were... to be bundled up safely [for storage] before exfiltration
deleted 3y ago
[deleted]
montjoy 3y ago
It’s encrypted between the starting point (Microsoft) and your ISP. Microsoft is the “client” in this case and just like you can read your email in Outlook or Thunderbird, MS can read all of your email that they pull over from you ISP.
- martinald 3y ago
  Yes I know but saying TLS is 'plaintext' is completely silly. It's like saying your credit card number is transmitted in plaintext when you do a TLS ecommerce transaction. I do understand the point that the article is making, but implying that TLS is equivalent to plaintext is just plain hyperbole. What else can Microsoft do (assuming they want to do this feature?). Encrypt it again on the client side, then put it in the TLS tunnel? It's just double encryption at that point. They need the password FWIW the amount of users still using unencrypted IMAP is often pretty high in outlook or apple mail. Now that is a security issue. Try using a wifi packet analyzer at a large conference. I bet you'll see multiple or even dozens of plaintext IMAP passwords going thru the air.

Fischgericht 3y ago

What they are talking about is that your passwords are uploaded via HTTPS/TLS, so an encrypted connection, but what they are sending are you full passwords in plain text over it. https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/3/3/1/0/1/1/01-Traffic_Mitschnitt-330ad3a100639b8c.png?force_format=avif%2Cwebp%2Cjpeg&org_if_sml=1&q=85&width=610 https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/4/3/3/1/...

quietbritishjim 3y ago
For IMAP to work you need the original password, not e.g. a hash. Once you've decided to send the actual password, whether wise or not, the best you can do is encrypt it, and TLS does that. What else would you expect?
- nhinck2 3y ago
  I would expect Microsoft not to be on the receiving end of my plaintext password.
- Fischgericht 3y ago
  TLS is only transport encryption. The password will be transmitted in clear before and and after that transport. This is not at all comparable to other "store my passwords inside the cloud"-systems, where the passwords are encrypted and decrypted on the users' devices, without the encryption key going to the cloud provider - that's the way it's handled in Password Managers, Chrome Auto-Fill etc. And I would expect Microsoft asking the user for explicit consent "May we take your IMAP password and transfer it and store it in our cloud?" in easy to understand wording so people understand the consequences (for example getting fired for having punched a gapping hole into your employers security policies like "Don't share this password with anyone") That expectation would match the law in the EU. And in addition, inside the EU it would also have to guarantee that the password will only be stored on servers inside the EU, and not end up, for example, with the NSA. And even then it still might not be legal. And from a user's perspective: Certainly a big chunk of users that have been using email software for the last decades would assume that an email client installed on your PC is doing the IMAP access locally. There is no need for your IMAP credentials to go to Microsoft. Merging your local mail store from multiple sources inside the client is what email clients have been doing for the last 20 years. There is absolutely no need to move this to the cloud. Yes, my computer can handle merging email folders.
- fulafel 3y ago
  Another reason to use something else than passwords with IMAP for authentication.
- magicalhippo 3y ago
  I would expect them to at a bare minimum encrypt it using a temporary public key before transmission, in case TLS connection was MITM'ed, and I'd expect them to use those fancy hardware security modules (HSM) they have[1] to protect it on their side. [1]: https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/overview https://learn.microsoft.com/en-us/azure/key-vault/managed-hs...
  - weikju 3y ago
    It doesn't matter how well they protect it, they still have the credential, and they decrypt it in order to be able to use it, so for all intents and purposes, it's in the clear _for Microsoft_ (and whoever else manages to have access). This is not how it should be.
    - magicalhippo 3y ago
      Obviously, and this is something they should communicate clearly. But if they were to provide such a "service" I'd expect them to minimize exposure, including the steps I mentioned.
  - magicalhippo 3y ago
    I was tired and forgot to add they should first check if the IMAP server supports XOAUTH2, and in that case require that to be used. Still not a great solution but at least not passing the password around.
- yjftsjthsd-h 3y ago
  > What else would you expect? I would expect user credentials to not be uploaded without giving an extremely explicit explanation and receiving informed consent from the user.
  - alt227 3y ago
    Also, the credentials have to be stored in plain text. M$ servers cannot auth with your IMAP host with a password hash, so they must be saving the plain text password somewhere which seems absolutely crazy to me.
    - AlexandrB 3y ago
      Next time there's a data breach at Azure, there will be fireworks.
    - thiht 3y ago
      No, that's just wrong. They can store these credentials encrypted with algorithms such as AES-256. No need to store them in plain text. This is actually standard security practice when you absolutely have to store a key in a way that you can use it later, such as a password or an API key.
- xorcist 3y ago
  IMAP supports a multitude of authentication standards, including hash and key-like, so the above is not necessarily true, however it is unlikely that Outlook supports them. Client certificates are supported by both Thunderbird and K9, would prevent this type of issues. In the cloud first era, your value is derived from how much customer data is under your control. Not for resale primarily but for stickiness. It's like the dot com era, only for real this time.
  - lxgr 3y ago
    > Client certificates are supported by both Thunderbird and K9, would prevent this type of issues. How? Outlook could just ask you for your certificate (+ private key) and upload that.
    - xorcist 3y ago
      I should have learned not to underestimate ingenuity by now.
- steve1977 3y ago
  I would expect that my local e-mail client is making the connection to my IMAP server. Not a connection to Microsoft servers which then in turn connect to my IMAP server.
- dahauns 3y ago
  >Once you've decided to send the actual password, But you haven't. Microsoft has decided that for you - without telling you. The more I think about it - that's not even just a GDPR issue, it's blatant malware behavior.

bravetraveler 3y ago

Transit vs rest, maybe? I suppose they'd prefer it be not transferred at all, but if it were... to be bundled up safely [for storage] before exfiltration

deleted 3y ago

[deleted]

montjoy 3y ago

It’s encrypted between the starting point (Microsoft) and your ISP. Microsoft is the “client” in this case and just like you can read your email in Outlook or Thunderbird, MS can read all of your email that they pull over from you ISP.

martinald 3y ago
Yes I know but saying TLS is 'plaintext' is completely silly. It's like saying your credit card number is transmitted in plaintext when you do a TLS ecommerce transaction. I do understand the point that the article is making, but implying that TLS is equivalent to plaintext is just plain hyperbole. What else can Microsoft do (assuming they want to do this feature?). Encrypt it again on the client side, then put it in the TLS tunnel? It's just double encryption at that point. They need the password FWIW the amount of users still using unencrypted IMAP is often pretty high in outlook or apple mail. Now that is a security issue. Try using a wifi packet analyzer at a large conference. I bet you'll see multiple or even dozens of plaintext IMAP passwords going thru the air.