[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to use fetchmail with MS Office 365 / davmail?



On Thu, 29 Apr 2021 14:03:37 +0100
Darac Marjal <mailinglist@darac.org.uk> wrote:

> 
> On 29/04/2021 13:11, Eric S Fraga wrote:
> > Dystopian is right.  Our organization, using O365, has moved to
> > "multi-factor authentication" without consultation and I can no longer
> > use gnus, for instance.  Absolutely horrible.
> 
> Ask your administrator to enable "Per Application Passwords" -
> https://docs.microsoft.com/en-us/azure/active-directory/user-help/multi-factor-authentication-end-user-app-passwords
> 
> The idea here is that, if a human is logging in, they still provide two
> factors (something they know and something they have) via the TOTP
> mechanism. But for automated access, where an application is logging in
> on behalf of that user, the user generates a long one-off password ONLY
> for that application. This works a bit like an API key - password #1 is
> for gnus on laptop 1, password #2 is for Fetchmail on laptop 1, password
> #3 is for gnus on laptop 2 and so on. Each instance of an application
> gets its own long password.
> 
> It's ostensibly more secure than storing the user's password in that
> application because:
> 
> * Per-App passwords are computer-generated. They can be tested for high
> entropy and regenerated instantaneously, before a "good" password is
> offered to the user. (I don't know whether this is actually done, or
> whether it's just the output of a pRNG password generator)
> 
> * Per-App passwords can be revoked without spoiling access to other
> applications. Did laptop 2 get stolen? Just revoke password #3 and you
> don't need to change the passwords stored on Laptop 1.

I've been looking into this recently, and I think there's a third, very
important but subtle reason why 2FA + application specific passwords
are (or at least can be) more secure than the classic password model:
the application specific password can be limited to grant permission to
access the account *data*, but will not grant permission to alter
account settings, so the account cannot be totally hijacked the way it
can be with classic passwords if they ever get compromised.

Celejar


Reply to: