6 ms·

> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password… Hmm, but couldn’t third party developer

by md_ 5y ago

> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password… Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.

striking 5y ago
Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.
superkuh 5y ago
If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.
- 0xCMP 5y ago
  they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.
- md_ 5y ago
  IMAP with OAuth is standard. What am I missing?
  - superkuh 5y ago
    It is not, in fact, a standard. It's a proprietary complicating thing that megacorps do and everyone else assumes is standard. https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749 "The OAuth 2.0 Authorization Framework" >This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope. So now you have HTTP protocol being used for IMAP, or worse and more common, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
    - tialaramex 5y ago
      > It is not, in fact, a standard. It's a proprietary complicating thing Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.
      - superkuh 5y ago
        It it were standard the same OAuth 2.0 module could be used with every provider of services. The reality is you need a custom implementation for every single megacorp and their local twist. It's not even a defacto standard by collective use.
    - Spivak 5y ago
      Why is it an issue that getting a token for use with IMAP requires an out-of-band HTTP request? How do you think SSO works for anything other than web services?
habosa 5y ago
In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.
- md_ 5y ago
  You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).
  - tialaramex 5y ago
    You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.
corobo 5y ago
e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :) -- Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change different password: check ringfenced access: check
- md_ 5y ago
  App passwords are not limited in scope, AFAIK.
  - corobo 5y ago
    It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail. Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought! I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!
dcow 5y ago
If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.
martius 5y ago
Google provides the App passwords feature: > An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords. Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.

by md_ 5y ago

striking 5y ago

Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.

superkuh 5y ago

If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.

0xCMP 5y ago
they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.
md_ 5y ago
IMAP with OAuth is standard. What am I missing?
- superkuh 5y ago
  It is not, in fact, a standard. It's a proprietary complicating thing that megacorps do and everyone else assumes is standard. https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749 "The OAuth 2.0 Authorization Framework" >This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope. So now you have HTTP protocol being used for IMAP, or worse and more common, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
  - tialaramex 5y ago
    > It is not, in fact, a standard. It's a proprietary complicating thing Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.
    - superkuh 5y ago
      It it were standard the same OAuth 2.0 module could be used with every provider of services. The reality is you need a custom implementation for every single megacorp and their local twist. It's not even a defacto standard by collective use.
  - Spivak 5y ago
    Why is it an issue that getting a token for use with IMAP requires an out-of-band HTTP request? How do you think SSO works for anything other than web services?

habosa 5y ago

In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.

md_ 5y ago
You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).
- tialaramex 5y ago
  You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.

corobo 5y ago

e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :) -- Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change different password: check ringfenced access: check

md_ 5y ago
App passwords are not limited in scope, AFAIK.
- corobo 5y ago
  It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail. Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought! I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!

dcow 5y ago

If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.

martius 5y ago

Google provides the App passwords feature: > An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords. Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.