Quote:
So ... IIUC you're saying that an https: connection to a webmail session (which internally uses IMAP to talk to the backend servers) is "secure" but an external client talking directly to the server over a secured (TLS or whatever) connection isn't?
Why do you think that?
What /specifically/ are the "possible security problems"?
|
Actually, I'm not sure and that's why I asked the question! First, I'm not certain that Gmail's web interface uses IMAP--I've read that it doesn't, but uncertain. Second, as pointed out by Folio, OAuth should be a secure way to sign in from third-party IMAP applications, but still you add another party, another interface. The more links in the chain between you and your email the more potential points of security failure. You have to put a level of trust into any app you are using.
Even OAuth has its vulnerabilities.
Quote:
One of the other key issues with OAuth is the general lack of built-in security features. The security relies almost entirely on developers using the right combination of configuration options and implementing their own additional security measures on top, such as robust input validation. As you've probably gathered, there's a lot to take in and this is quite easy to get wrong if you're inexperienced with OAuth.
Depending on the grant type, highly sensitive data is also sent via the browser, which presents various opportunities for an attacker to intercept it.
|
https://portswigger.net/web-security/oauth
Quote:
|
I take it that you disable POP and IMAP access in your Gmail settings to reduce the number of attack surfaces exposed by your account.
|
And with Gmail you can disable them, which I imagine eliminates those possible failure points. Not sure if they still exist, but until fairly recently I encountered apps that didn't use OAuth, but instead required app passwords that seem inherently less safe.