> Nobody sane does that in 2025
Not for their own users passwords, no. But if a user has to provide secrets that
you have to user server-side, then yes. And you'll find that this happens much
more often than you're thinking. The problem here of course is that the secret
isn't easily revocable and that users may have reused this secret across
services. This doesn't apply to me because of the ASP enforcement, but I assume
your message wasn't directed at that. The fact remains that in this case, the
user wants their emails to be on another server. If that's something you do not
want to happen, you'll have to limit IMAP/POP3 access to specific networks. It
is an open protocol that utilizes the user's actual password as the access
token, and we're stuck with it for better or worse.
> Have you (re) read this document recently
Nope. I did just now, and it's an interesting read! Really shows the importance
of key rotation, even if you're confident a secret key can't be leaked.
Groetjes,
Louis
Op dinsdag 7 januari 2025 om 17:27, schreef Scott Q. via mailop
<mai...@mailop.or
> I may just point out that Google/MS365 have to store encrypted versions ( not
> hashed! ) of a user's password. Nobody sane does that in 2025. We don't do it.
> They don't do it for their own users. Why would you be ok with them, or anyone
> for that matter, except the client, knowing that info ?
>
> Have you (re) read this document recently ?
> https://www.dhs.gov/news/2024/04/02/cyber-safety-review-board-releases-report-microsoft-online-exchange-incident-summer
> [https://www.dhs.gov/news/2024/04/02/cyber-safety-review-board-releases-report-microsoft-online-exchange-incident-summer]
>
> Scott
>
> On Tuesday, 07/01/2025 at 11:10 Louis via mailop wrote:
>
>
> > > does the user use the same credentials to pull messages (POP or IMAP) and
> > > to log in to SMTP to send messages?
> >
> > Depends! I enforce ASPs with a scope, so the scope is up to the user in my
> > case. Clients never have access to actual user credentials.
> >
> > > NO IT IS NOT!
> >
> > No need to be so loud, I can read lowercase just fine. You're right in
> > saying there are differences, your last point about not controlling the
> > customer was what I was trying to convey. They have the freedom to choose
> > their client, I think that's the beauty of email. You do not have control
> > over how a client stores a password, this is just one of the reasons I
> > enforce ASPs. Your point 1 and 2 are also true, and in my mind they cancel
> > each other out regarding risk in this case. I don't have the statistics at
> > hand, but my gut tells me device compromises happen much more often than
> > Google leaking plaintext passwords.
> >
> > If you have more strict requirements, you'd probably already only be
> > allowing VPN access from devices within your control. I think it's clear
> > we're not talking about that context here.
> >
> >
> >
> > Groetjes,
> > Louis
> >
> >
> > Op dinsdag 7 januari 2025 om 01:46, schreef postfix--- via mailop
> > <mailop@mailop.org [mailop@mailop.org]>:
> >
> > > On 2025-01-06 18:21, L. Mark Stone via mailop wrote:
> > > >> On Jan 6, 2025, at 6:48 PM, Andrew C Aitchison via mailop >> how
> > > comfortable are you giving GMail your users' passwords
> > > >> (sorry, asking your users to share their password with GMail) ?
> > > >>
> > > > > > Andrew, either I’m not understanding or you’ve not thought this
> > > through…
> > > > > If a customer wants a copy of all of their email to be in Gmail, does
> > > it > really matter if Gmail has the password to the user’s account?
> > >
> > > does the user use the same credentials to pull messages (POP or IMAP) and
> > > to log in to SMTP to send messages?
> > >
> > > On 2025-01-06 18:11, Louis via mailop wrote:
> > > > Realistically, it's the same risk as giving the user's password to any
> > > > email client, right? Unless you implement a strict ASP policy for imap/
> > > > pop/smtp, the user is going to be giving out their passwords to email
> > > > clients anyway.
> > >
> > > NO IT IS NOT! on so many counts it is not:
> > >
> > > (1) one user device storing one set of user credentials is a much less
> > > interesting attack target than the server/infrastructure of a service
> > > provider holding millions of such credentials
> > >
> > > (2) conversely, the security applied to the server/infrastructure is most
> > > likely light years ahead of the average user's client device
> > >
> > > (3) not all email clients operated on user's devices are the same. some do
> > > stupid things such as saving credentials in plain text. others do other
> > > stupid things such as copying credentials to their owner's cloud
> > >
> > > (4) can't control the customer, whether they use Gmail or some local
> > > client, but can certainly control your infrastructure and the risk is
> > > totally different based on how you set up credentials for your own
> > > customers.
> > >
> > > Reading this mailing list, sometimes I wonder about best practices...
> > >
> > > Yuv
> > > --
> > > Ontario-licensed lawyer
> > >
> > > _______________________________________________
> > > mailop mailing list
> > > mailop@mailop.org [mailop@mailop.org]
> > > https://list.mailop.org/listinfo/mailop
> > > [https://list.mailop.org/listinfo/mailop]
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
