Mailkit: Authentication to gmail fails with example app

[matt2003]

The example app fails on google authentication and sends the users mail an email about using a modern client. In the xamarin.ios app itself it says web login required.

MailKit.Security.AuthenticationException: Web login required

Thanks

[jstedfast]

You have to go into your GMail settings and enable IMAP access for "less secure apps" (which is a BS label, but that's what they call it).

Unfortunately I don't know of a workaround for this other than perhaps using OAuth2 credentials which is very GMail-specific.

[jvilhuber]

Oauth2 is becoming more and more prevalent (I believe hotmail and yahoo
support it as well). Having an App know the user's credentials is not
optimal from a security perspective (you can divulge what you don't know!),
which is why google (and soon others) categorize apps that use a
username/password login as 'insecure'. OAuth2 is definitely the way around
having to set the 'insecure apps' toggle in google. Google provides C# code
to integrate this into an app, and there's some general purpose Oauth2
library as well that works with google (and others).

If you're testing, username/password is fine (and you can expect your users
or testers to turn that on). For a released product, I highly recommend
staying away from collecting usernames and passwords from your users
(whenever possible, and it often isn't possible).

Not that Oauth2 is the panacea, but it is what a lot of companies are
standardizing on.

On Wed, Sep 2, 2015 at 8:06 AM, Jeffrey Stedfast [email protected]
wrote:

Closed #239 https://github.com/jstedfast/MailKit/issues/239.

—
Reply to this email directly or view it on GitHub
https://github.com/jstedfast/MailKit/issues/239#event-398972800.

[jstedfast]

I'm not sure that you can actually make the claim that the client doesn't need to know the user's password when using OAuth2 because in order to get the auth_token to use with IMAP, the client must first send the username/password strings to an HTTP server to get said auth_token.

Or at least that's my understanding of how OAuth2 works... (how else would the HTTP server be able to know you are who you say you are otherwise?)

[matt2003]

Hi
Thank you for the explanation for the workaround.
Matt

On Wednesday, September 2, 2015, Jeffrey Stedfast [email protected]
wrote:

You have to go into your GMail settings and enable IMAP access for "less
secure apps" (which is a BS label, but that's what they call it).

Unfortunately I don't know of a workaround for this other than perhaps
using OAuth2 credentials which is very GMail-specific.

—
Reply to this email directly or view it on GitHub
https://github.com/jstedfast/MailKit/issues/239#issuecomment-137093433.

[jstedfast]

No problem. I'll look into adding OAuth2 logic to the samples since this will probably come up again.

[jvilhuber]

Jeff, the way most OAUTH2 libraries work (including the two I've played with) is that they open a web-view, and the user talks 'directly' to google (or some oauth2 server). When the exchange is done (and it can be more than a simple request response, especially if you have 2FA enabled), there's a cookie you get back in some manner, containing the OAUTH2 token.

Clearly there's opportunities to intercept the password (which is why I put 'directly' in quotes), depending on how the web-view is implemented (assuming one is used; I'm not sure how that is enforced on the server-end). I believe google's oauth library switches to a different app altogether, and does an open-in with the resulting oauth token to pass it back to the app. I'm not sure other oauth2 libraries do it that way (and we've had problems with the google library and are no longer using it).

[jstedfast]

I guess if you trust browser controls more than email clients, then I suppose that's more "secure"... but it sounds more like the "security" strategy is to not allow passwords to be saved, which means you could just make clients not save the password and prompt every time.

In other words, OAuth2 is really just a kludge to work around the fact that many email clients offer to save the user's password for their own convenience (just like web browsers do) and some people feel that by forcing users to enter their credentials manually every time, it makes it more secure?

In my experience, that means most users just choose easier passwords to remember (meaning less secure) or they tell their browser to save it (overriding the whole purpose of the OAuth2 security strategy), or... at best, they just store it in something like 1Password or LastPass (which is what I do).

Apparently security experts don't feel it's very secure.

OAuth 2.0 doesn't support signature, encryption, channel binding, or client verification.
It relies completely on SSL for some degree of confidentiality and server authentication.

OAuth 2.0 has had numerous security flaws exposed in implementations. The protocol
itself has been described as inherently insecure by security experts and a primary
contributor to the specification stated that implementation mistakes are almost inevitable.

The first sentence suggests to me that the purpose was to enforce the idea that passwords aren't sent over the wire in the clear, thus allowing non-SSL/STARTTLS IMAP clients to login w/o the use of a cleartext password (such as the LOGIN command or the LOGIN and/or PLAIN SASL mechanisms). The solution, here, though, is to simply not support those mechanisms on the server and to instead only offer mechanisms such as CRAM-MD5, SCRAM-SHA-1, NTLM, or one of the many other challenge-response mechanisms that do not send any form of the password across the wire at all.

The only counter-argument that I can think of for that (and I'd have to double-check to confirm) is that all of those SASL mechanisms require that the server be able to get access to the raw password string which means that it'd have to store the cleartext password somewhere (e.g. /etc/shadow) whereas in cases where the authentication protocol requires the raw password be sent, then the server could just store a hash of the password and hash the raw password that it receives across the wire and match it against what it has in its database.

But that just trades trust in the server not being compromised with a much more likely scenario of the SSL protocol being compromised or a MITM attack.

I haven't read what the security experts have said about OAuth2, but my guess is that I'm probably pretty close :-)

[jstedfast]

Anyway... sorry for my rant on OAuth2 :-)

[jvilhuber]

No worries at all. I like the concept of this sort of thing, but note I did mention that oauth2 is not the panacea. 😀 SAML is more secure but also a bit of a pain. You should check out what the original author of oauth2 has to say about it! He had his name removed from all rfc's...

[jvilhuber]

Ultimately I really like the idea a that a client that means well (and security tends to be a reputation game, since ordinary users won't be able to audit the code) can do its best to not have (or have for as small a time as possible) the user's credentials. If the client gets compromised, it reduces the amount of time the credentials could be stolen. We can talk about whether oauth2 accomplishes that securely, offline 😀 I suspect were in full agreement there.

[jstedfast]

It looks like in order to support OAuth2, I'd have to create an API Key and register my app, etc... this all sounds like not a good idea to do for a demo app that everyone would have the source code to (they'd likely just end up copy/pasting my API Key everywhere at best and at worst they might be able to use it in mischievous ways).

[jvilhuber]

Yea don't do that. Better to just include instructions on what to do on Google's end and why and leave it at that.

Jan

Sent from Nacho Mail

[Muraad]

OAuth(2) was never designed for native apps. The problem you described "where do i put my client secret/credentials/api key" is not only a problem for a test app that is published on github. It is a real problem for all native apps, if you know how easy it is to "decompile" apps. This applies to interpreted languages like C# and Java even more. OAuth(2) was (sadly) designed for server-to-server communication, where the OAuth credentials are never shipped to a client/user and are instead some where ("safe") in your backend code/config.

[matt2003]

I agree you with you in the Java side and android without pro guard though
for iPad this is a lot less likely as everything is compiled to native arm
binary, so it would be much more challenging, there is no interpreted code
on the device.

On Wednesday, September 9, 2015, Muraad Nofal [email protected]
wrote:

OAuth(2) was never designed for native apps. The problem you described
"where do i put my client secret/credentials/api key" is not only a problem
for a test app that is published on github. It is a real problem for all
native apps, if you know how easy it is to "decompile" apps. This applies
to interpreted languages like C# and Java even more. OAuth(2) was (sadly)
designed for server-to-server communication, where the OAuth credentials
are never shipped to a client/user and are instead some where ("safe") in
your backend code/config.

—
Reply to this email directly or view it on GitHub
https://github.com/jstedfast/MailKit/issues/239#issuecomment-138556189.

[Muraad]

@jvilhuber Thanks for pointing to then Eran Hammer the inventor of OAuth. His conclusion about OAuth2 is devastating. And his talk is good and entertaining :-) https://vimeo.com/52882780
(RealtimeConf - "OAuth 2.0 - Looking Back and Moving On" by Eran Hammer)

[zpeleg]

I think that adding Gmail OAuth support would be very big scope creep for this project, but I suggest looking how This spotify API did it if anyone plans on implementing this in their program.

btw, while OAuth 2.0 is flawed, it's still much better than storing plaintext username and password on an unsecured device.