Re: support of two factor authentication?
On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: > As more isps and email providers require two factor authentication, I > hope mutt will support this security system! Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. What I do then is to generate an app-specific password which is the one I use in the mutt configuration. There's not much to support, it's just a different password, unless there's something I'm not getting right. Cheers, -- José María (Chema) Mateos https://rinzewind.org/blog-es || https://rinzewind.org/blog-en
Re: support of two factor authentication?
On 18-06-12 08:49:09, José María Mateos wrote: On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: As more isps and email providers require two factor authentication, I hope mutt will support this security system! Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. What I do then is to generate an app-specific password which is the one I use in the mutt configuration. There's not much to support, it's just a different password, unless there's something I'm not getting right. Yes as far as I am concerned it's on the email provider to give you app-specific password functionality. If you want real 2FA, ie you require a token every time you open mutt, then I would recommend using gpg to encrypt your password and access it that way. Then you can use a smart card to store your gpg key (yubikey, nitrokey) and gnupg will only decrypt your password when it is present. The benefit of this is that you can use the same key to sign and encrypt messages. 2 in 1! As far as I know, TOTP (like Google Authenticator etc) is not part of the authentication protocols supported by email. What you see as 2-FA are usually just used to protect web front-ends. I might be way off the mark though. signature.asc Description: PGP signature
Re: support of two factor authentication?
I use LastPass CLI to present my password. I have LastPass protected with 2FA. My .muttrc contains a line like this: set imap_pass="`/usr/local/bin/lpass show --password myname@mydomain || sleep 1`" and set smtp_pass=$imap_pass and that works for me. -- Hokan Bicyclist Sysadmin
Re: support of two factor authentication?
On Tue, Jun 12, 2018 at 08:49:09AM -0400, José María Mateos wrote: > On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: > > As more isps and email providers require two factor authentication, I > > hope mutt will support this security system! > > Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. > What I do then is to generate an app-specific password which is the one > I use in the mutt configuration. There's not much to support, it's just > a different password, unless there's something I'm not getting right. I do this too, with Gsuite (for work). But that's not really "supporting" 2FA auth; the provider is making a way to bypass 2FA for convenience. I think if Mutt were actually supporting it, there would be a way to have hooks to enter both password and passphrase. Because of the different auth schemes used for this (and presumably lack of support in the IMAP protocol), I'm guessing it might be pretty difficult to implement this. w
Re: support of two factor authentication?
On Tue, Jun 12, 2018 at 09:45:50AM -0500, Hokan wrote: > I use LastPass CLI to present my password. I have LastPass protected with > 2FA. > > My .muttrc contains a line like this: > set imap_pass="`/usr/local/bin/lpass show --password myname@mydomain || sleep > 1`" > and > set smtp_pass=$imap_pass > > and that works for me. It should be pointed out that this is not really 2FA at all. If I have your actual user credentials (username & password), say because I got root access to the machine where you run Mutt and snarfed them out of memory, this scheme does nothing to prevent me from using them directly, completely bypassing any 2FA on LastPass. With respect to the resource to which your credentials give access, there's no second factor. LastPass is just acting as a proxy for your brain. The only actual effect it has is to complicate (in a technical sense) the retrieval of your single authentication factor from your "memory" (i.e. LastPass' password store)--making it arguably less secure, not more (because more potential points of failure mean a higher chance something will break, preventing you from being able to access your mail). All the security in the world does you no good if the resources you're protecting are unavailable to legitimate users. The point of 2FA is to prevent the scenario where an attacker gets your credentials (user & password, or "the thing you know"), allowing them to gain access. Examples of how this would be 2FA is if your IMAP server *additionally* required a cryptographic certificate, hardware token, sent you a text to your phone, etc.--something that only *you* should have physical access to. Inability to access that physical thing (your second authentication factor) still prevents access, even though your credentials are compromised (known by someone other than yourself). Like your scheme, this also increases complexity, but unlike your scheme, it additionally provides a real increase in security--making the extra complexity involved (arguably) justified. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpKYJ0UMvI_j.pgp Description: PGP signature
Re: support of two factor authentication?
On Tue, Jun 12, 2018 at 08:49:09AM -0400, Jos? Mar?a Mateos wrote: > On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: > > As more isps and email providers require two factor authentication, I > > hope mutt will support this security system! > > Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. > What I do then is to generate an app-specific password which is the one > I use in the mutt configuration. There's not much to support, it's just > a different password, unless there's something I'm not getting right. > > Cheers, > > -- > José María (Chema) Mateos > https://rinzewind.org/blog-es || https://rinzewind.org/blog-en Jose, In what little I've read, I'd thought one needed to authenticate with two passwords, but I'm probably wrong. Thanks, I'll try it if it becomes necessary. Tom Fowle
Re: support of two factor authentication?
On Tue, Jun 12, 2018 at 02:10:29PM +0100, Ben Oliver wrote: > On 18-06-12 08:49:09, José María Mateos wrote: > >On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: > >>As more isps and email providers require two factor authentication, I > >>hope mutt will support this security system! > > > >Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. > >What I do then is to generate an app-specific password which is the one > >I use in the mutt configuration. There's not much to support, it's just > >a different password, unless there's something I'm not getting right. > > Yes as far as I am concerned it's on the email provider to give you > app-specific password functionality. > > If you want real 2FA, ie you require a token every time you open mutt, then > I would recommend using gpg to encrypt your password and access it that way. > > Then you can use a smart card to store your gpg key (yubikey, nitrokey) and > gnupg will only decrypt your password when it is present. > > The benefit of this is that you can use the same key to sign and encrypt > messages. 2 in 1! > > As far as I know, TOTP (like Google Authenticator etc) is not part of the > authentication protocols supported by email. What you see as 2-FA are > usually just used to protect web front-ends. I might be way off the mark > though. Thanks, I'll look into this if necessary, but my email is not that critical I hope. Tom Fowle
Re: support of two factor authentication?
On Tue, Jun 12, 2018 at 09:45:50AM -0500, Hokan wrote: > I use LastPass CLI to present my password. I have LastPass protected with > 2FA. > > My .muttrc contains a line like this: > set imap_pass="`/usr/local/bin/lpass show --password myname@mydomain || sleep > 1`" > and > set smtp_pass=$imap_pass > > and that works for me. > > > -- > Hokan > Bicyclist > Sysadmin Thanks Hokan, I'll look into lastpass Tom Fowle
Re: support of two factor authentication?
Tom Fowle wrote: > On Tue, Jun 12, 2018 at 08:49:09AM -0400, Jos? Mar?a Mateos wrote: > > On Mon, Jun 11, 2018 at 08:26:42PM -0700, Tom Fowle wrote: > > > As more isps and email providers require two factor authentication, I > > > hope mutt will support this security system! > > > > Doesn't mutt already "support" this? I use Fastmail with 2FA enabled. > > What I do then is to generate an app-specific password which is the one > > I use in the mutt configuration. There's not much to support, it's just > > a different password, unless there's something I'm not getting right. > > > > Cheers, > > > > -- > > José María (Chema) Mateos > > https://rinzewind.org/blog-es || https://rinzewind.org/blog-en > > Jose, > In what little I've read, I'd thought one needed to authenticate with two > passwords, but I'm probably wrong. > > Thanks, I'll try it if it becomes necessary. > Tom Fowle tl;dr - 2FA/MFA = what you know + what you have + what you are. 2 passwords = 2 * what you know = 1FA. 2FA/MFA is mostly for websites, not pop/imap. however, pop/imap + tls + client certificate = 2FA/MFA (?). however, can't really see that happening. off-topic nonsense about credential stuffing, 2FA/MFA, password managers. long version 2FA/MFA isn't two passwords. It's something you know (like usernames and passwords) and something you have (like access to an email account or mobile/cell/handy phone), and/or something you are (like fingerprints or iris patterns or voice pstterns). Two passwords is just two of something you know so it's still a single factor. However, it should be pointed out that 2FA/MFA is mostly for websites. The IMAP/POP protocols have no support for it. It's unlikely that the POP/IMAP protocols will be changed to incorporate 2FA/MFA. And until that happens, I doubt there's much that mutt (or POP/IMAP servers) can do about it. Actually, I'm probably completely wrong about that. It's probably quite possible for a POP/IMAP server to require the use of TLS and to require that you have a client certificate that it recognises as well as your username and password. That would be 2FA/MFA and mutt might not even need to know about it. The underlying TLS library would take care of it. But the email service provider would have to have some way of issuing you with a client certificate and instructions on how to install it. If the client certificate is encrypted then mutt might need to know about it to support gathering the passphrase needed to decrypt the client certificate. I don't know. But I can't see too many email service providers requiring all of their users to install (and possibly encrypt) client certificates on all of their devices where they read email. But it could be an opt-in thing where if you ask for a client certificate, then you always need to use it. The biggest threat that is mitigated by 2FA/MFA is credential stuffing where someone hacks one website, steals the usernames (usually email addresses) and passwords, cracks the passwords, then re-uses them on all the other websites to see if they work. Last I heard, 40% of website logins attempts worldwide are automated using stolen credentials. The attempts that succeed are worth more in criminal markets than untested stolen credentials. Where there's a business model, there's a way. Credential stuffing is here to stay. The best defense against this is for all websites to store passwords in a way that can't be cracked or at least can't be cracked without spending vast sums of money on hardware (e.g. scrypt+hmac). But of course website users have no control over that. Just having unique strong passwords for every website is enough to mitigate against credential stuffing. Real 2FA/MFA is more for protecting against attacks that target you specifically. But even then, some 2FA/MFA systems send an email with a code to an email account that you might only have 2FA/MFA access to, but most send a text message and, at least in Australia, it's very easy to steal someone's mobile/cell/handy phone number (not the handset, just the number), so 2FA/MFA doesn't really protect against targeted attacks either. So it only really protects against credential stuffing. But it does make targeted attacks harder to perform so it is worthwhile for that too. Anyway, if you're just concerned about credential stuffing, use a password manager and use it (or at least unique strong passwords) for any POP/IMAP accounts you have as well as for any website accounts. I think the reason that some websites require 2FA/MFA is because they can't force you to use strong unique passwords for every website. But if you choose to use strong unique passwords for everything, then you don't really need 2FA/MFA (unless you also want to defend yourself against targeted attacks by people who aren't willing to put too much effort into the targeted attack). Having said all that, 2FA/MFA may well be easier than using a password manager. If so, that's a good enough rea
Re: support of two factor authentication?
On Wed, Jun 13, 2018 at 02:56:03PM +1000, m...@raf.org wrote: > However, it should be pointed out that 2FA/MFA is mostly for > websites. The IMAP/POP protocols have no support for it. It's > unlikely that the POP/IMAP protocols will be changed to > incorporate 2FA/MFA. And until that happens, I doubt there's > much that mutt (or POP/IMAP servers) can do about it. There is a recent patch to support OAUTH in Mutt (rfc 7628) (see mutt-dev archives). With that, you'd need to visit a link to authenticate when 2FA is required, and an external script is required, but that I think would essentially add 2FA support, and also avoid the need for an application specific password to be used. See thread starting at: http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180611/000121.html With some further discussion of the 2FA bit at: http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180611/000128.html I'd imagine that, eventually, the external scripts used to do this could support passing in the token via console vs. following a web link that has to be clicked on or cut / pasted into browser bar. w
