Mailbox.org discovers unencrypted password transmission in myMail | Hacker News Reader

Mailbox.org discovers unencrypted password transmission in myMail

mailbox.org

83 pointslis29 comments

I'd never heard of myMail. Turns out it's a mobile only MUA made by a Russian company (https://en.wikipedia.org/wiki/Mail.Ru) and they were seen collecting people's usernames and passwords and using those logins to read people's messages from their own servers almost a decade ago (https://old.reddit.com/r/Android/comments/20u712/beware_myma...)

>they were seen collecting people's usernames and passwords and using those logins to read people's messages from their own servers almost a decade ago

To be fair microsoft's outlook ios and android clients does the same thing with external providers (like if you used it with fastmail). It is a common practice and something to be aware of when choosing an email app.

EDIT: I'm specifically answering this comment. As for the submission, that was incredibly stupid for them to do in 2023. At this point it should only be opt-in to turn encryption off, not a default.

Collecting credentials and reading mail from server is standard practice across hosts of email clients, since it’s the only way to get push notification working. If you don’t trust their server you probably shouldn’t use their client anyway.

BlackBerry was doing this 20 years ago. That's how their push email service (BIS) worked.

And yes I still lament the loss of the blinking red LED, a victim of phone makers today treating devices as if they were a piece of jewelry as opposed to the utilitarian tools they really are.

Apps can't just send notifications? If I had a mail client installed, couldn't the app just periodically connect to my mail server using my internet connection, see new mail was available, and then pop up a notification so I'd know?

That seems much more secure than having a third party collecting my passwords so they can connect to my mail server from their network using my password just to see if any new mail is there, read the messages, then send a notification to my phone to let me know about them.

I'm perfectly happy to trust Thunderbird enough to configure it to check my mailbox, but I wouldn't feel as comfortable handing my login information directly to Mozilla so that they can log into my mailbox whenever they feel like it. I guess Mozilla could push an update that collects my stored login credentials and do that anyway, but if they did I think there would be a lot of folks who'd protest.

> If I had a mail client installed, couldn't the app just periodically connect to my mail server, see new mail was available, and then pop up a notification so I'd know?

Desktop mail clients do. Phone mail clients can’t, so you either check on a server, or don’t get notifications on time.

Mobile platforms seem a bit broken. Timer/alarm apps seem to be able to take actions and notify on a regular schedule, it is specifically scheduled network activity that's restricted?

yes mobile OSes will delay and group background activity especially if it involves network access. But we're talking minutes, not hours of delay... Some phones are very aggressive and the app will need to show a persistent notification to keep background polling working, though.

I've never used a mobile client that used a third party to monitor a mailbox, they all do polling as you suggest. I'm not sure the man in the middle approach it's as common as OP is implying here (for non-first party clients).

It's debatable whether those are considered push notifications. On one hand, it's pushing the notifications from one program on the device to another. On the other hand, it isn't pushing remotely from a server to the device.

This reminded me of Pointcast Networks. Ah, the 90s. :) https://en.wikipedia.org/wiki/PointCast https://www.youtube.com/watch?v=qCqwB6sruIQ

Those are not push notifications, but the push part isn’t the goal, notifications are. The point here is you simply can’t poll on a reliable schedule on mobile devices, so push is the way.

Mail polling doesn't require accuracy. The OS won't delay your polling timer more than 10 minutes in the most aggressive cases, which is perfectly fine.

I'm sure the third party you share your email just to get push notifications with isn't monitoring your mailbox to the second either...

They probably are. If they connect via IMAP, they can use the IDLE and/or the NOTIFICATION command to get notifications of new messages arriving. This is generally as prompt as it gets; the server doesn’t wait much before sending the notifications.

>Apps can't just send notifications?

They can but consider this: How would they know to send them?

If you are adding a provider only locally there's no way for the app to know to generate a notification if it doesn't have an IMAP idle connection open constantly or scheduled polling. If the app is shipped by the email provider (like gmail app for ios using a gmail account) they can send pushes without leaving connection open or polling.

The point of having your details with the app developer is that their servers will remain always connected to your email provierr and generate pushes that will go over Apple or Google's push network.

I can see it making sense if you're already using the mail servers of the company that made the app (gmail for example) since they already have unrestricted access to your login info and mailbox anyway.

I guess otherwise I'd rather it be my phone regularly polling my mail server over my connection than a third party regularly polling it using theirs. I can see it being a popular option for folks on expensive/very limited data plans though. It doesn't take a ton of bandwidth to poll a mail server, but checking every 5-10 minutes it could add up.

the OS won't let you do that reliably unless the user also keeps opening the app. background processing is heavily limited for the right reasons.

iOS does that, maybe, but Android doesn’t. The mail client I use on my Android phone notifies me in a timely fashion when new mail arrives, often in less than a second. It just uses IMAP’s IDLE command to wait for new mail. If the connection drops it can just open a new one.

"Android doesn't"

Does it occur to you that there are so many different variants of Android and they all do their own thing regarding background processes? It is so complicated that you can find websites like this https://dontkillmyapp.com/

That’s a fair point; I hadn’t realized how bad certain brands could be. The last Samsung phone I owned was from about 10 years ago, and it worked just fine. I replaced it with a Google Pixel last year when the 3G networks started getting shut down, and it works great too.

Given the shoddy "battery saving" behavior of various Android vendors, probably not. I have a phone collecting dust that was so bad in this regard that no matter of tuning and disabling battery optimizations would get notifications to work in all apps.

Why would this be the only way? I have IMAP push reliably working with k9mail on Android.

> Collecting credentials and reading mail from server is standard practice across hosts of email clients,

In some countries this is "unauthorised access to computing systems".

But Google and co. are above the law anyway.

I had an alert about 9 months ago that someone might have accessed my hotmail, I went to check the previous logins and did see some from places in SE Asia but from months ago.

Mixed in were many logins from an IP address owned by the Microsoft campus at times when I would have been asleep. The account is a backup, and I don't have that mailbox attached to any apps. I emailed their security team asking what was going on but never got a response. After changing the password all the access was stopped. Though I should go back and re-check.

Interestingly, this is another security issue with STARTTLS. The whole concept of first establishing an unencrypted connection and only then upgrading to encryption is fragile in multiple ways.

Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).

https://nostarttls.secvuln.info/

And as one of my co-authors just pointed out to me, we also found a few security issues in mymail, yet they closed them as "not applicable"...

It's not just explicit vs. implicit TLS that's an issue with MUAs. Assuming good implicit TLS configuration there's still no proper way to harden such connections against an active MITM - we don't have an usable MUA-STS standard.

Was that the buffered input during starttls connection? Man thanks for that. I had to go and update my code due to that paper.

And the mess I had unavoidably made around the sockets and starttls just made that worse. And there was no real way to unit test it.

Thank you for writing this, I use it as a reference when explaining the difference STARTTLS and implicit TLS and why people should choose one over the other.

Another nice one is that implicit TLS is SNI routable (and thus much easier to route) -- this is the main reason for me, and I wish the standard had been updated to encourage more people to try 465 (or have a way to specify port in DNS records for example). Huge missed opportunity.

> or have a way to specify port in DNS records for example

https://www.fastmail.help/hc/en-us/articles/360060591153-Man... under "Client email auto-discovery"

Though support for these are...

TIL about those DNS configurations.

It does look like they are actually for clients (i.e. MUAs doing IMAP & Submission), not for relay (i.e. MTAs doing SMTP/SMTPS).

I've used MTA-STS and XML to enable auto-config for my stuff:

https://vadosware.io/post/thunderbird-autoconfig-for-your-se...

Oh and it looks like MTA-STS might be the solution:

https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...

Turns out there's an excellent guide by the UK government:

https://www.ncsc.gov.uk/collection/email-security-and-anti-s...

https://www.security.gov.uk/guidance/email-guidance/mta-sts/...

Relevant RFC:

https://datatracker.ietf.org/doc/html/rfc8461

Reply on news.ycombinator.com