Arnt Gulbrandsen wrote in <22bf0336-e861-4049-aa37-4d7d6e9a6...@gulbrandsen.priv.no>: |On Tuesday 11 February 2020 18:34:51 CET, Gerry O'Brien wrote: |> Do you have any plans to make mutt compatible with |> Microsoft's Exchange Online after they discontinue support for |> IMAP |> https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-ba\ |> sic-authentication-access-to-exchange-online-apis-for-office-365-custome\ |> rs. | |As you've no doubt grasped now, you misunderstood that blog posting |totally. IMAP is staying. | |But perhaps you want to know the point of the change: Most IMAP clients |want to keep the user's password around in persistent storage, so they can |reconnect without asking for a password. Which means that any antisocial |miscreants who gain access to a user's comptuer also gain access to a very |valuable password, which can be used to gain access to the user's Micros\ |oft |account at any time the miscreant wishes. | |So what Mirosooft is saying is: Effective October 2020, IMAP clients will |only be permitted to use an authentication procedure that doesn't require |storing high-value passowrds on poorly secured computers.
^_^ As its late, all i want to add here is that it is very neat that XOAUTH2/OAUTHBEARER replaces that one account password with three individual tokens, of which one is temporary, the access token, which you can use in place of the normal account password for accessing a specific service. Even the cumulative access to the three tokens stored on your poorly secured computer will not reveal the account password. Different to a Kerberos ticket you gained with kinit(1) one cannot render the access token invalid (kdestroy(1)), nor can you fine-tune anything when creating it. I think GMail times out an access token after 60 minutes. Refreshing the access token requires a HTTPS connection, and the two other tokens. Alpine MUA implemented that HTTPS thing itself, it requires HTTPS (with HTTP/2 to come for sure...) and JSON. Now. Why can't you just use plain text authentication with this access token, why must it be XOAUTH2/OAUTHBEARER? Why do you need an OAuth framework if you do support these two? Just offer a diversified set of passwords, one master, one for each service. Where is the difference? Why don't you either introduce service additions to refresh the access token, or extend the XOAUTH2/OAUTHBEARER "JSON" (why JSON? why not \0 terminated sub\0strings\0\0, like for others? Why JSON?) query/response with that possibility? (password=PASS\0refresh=yes\0\0?) P.S.: i store my passwords in a GPG encrypted ~/.netrc.gpg file (with the extensions my MUA supports). That is actually a symlink into a directory that is mounted via encfs. I know this is not perfect, it should reside on a filesystem that sits on block- level encrypted hardware, including encrypted swap, i will do that this year, somewhen, there is enough space for a 50:50 split when doing it. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
