K-9: Add support for SCRAM-SHA1

[philipwhiuk]

Expected behaviour

User should be able to select SCRAM-SHA1 as a form of authentication for IMAP.

Rationale

CRAM-MD5 is deprecated. SCRAM-SHA1 is fairly well adopted. If SSL/TLS is deployed we don't gain much security, but SSL/TLS isn't everywhere and CRAM-MD5 is obsolete.

Issues arising

The algorithm is more complex than others. It involves generating random nonces and the actual schema is quite difficult to follow. Deployment is less common so it's more complex to test but the original requester did offer a temporary test host.

On a UX level we don't actually expose the encryption method. We allow them to select from 'Plain', 'Encrypted' and 'Client certificate'.

According to the code documentation :

PLAIN and CRAM_MD5 originally referred to specific SASL authentication
* mechanisms. Their meaning has since been broadened to mean authentication
* with unencrypted and encrypted passwords, respectively.

In theory this is nice. In practice it's a white lie - it does translate to that in the UI but we don't support any encryption except CRAM_MD5.

Source of request:

Google Groups Feedback https://groups.google.com/forum/#!topic/k-9-mail/UHhXyRY74SU

[philipwhiuk]

See also similar potential enhancements on authentication:

• GSSAPI (instead of SASL) / Kerberos (weird certificate): #644
• XOAuth 2 for Gmail (OAuth 2.0 (RFC 6749) token based) #655
• DANE (for secure SMTP) - RFC 7672

[rugk]

DANE is not a way to authenticate users, see https://github.com/k9mail/k-9/issues/1776 for this.

[legrosgore]

Could you please support a better authentication than CRAM-MD5 ?
Security matters... I need to allow unsecure apps on gmail because of that. Is K-9 insecure ?

[rugk]

Sorry, but this is nonsense. Neither SCRAM-SHA1 nor CRAM-MD5 are secure. MD5 hashes can be broken in seconds, the same for SHA-1, depending on the password of course. Both are just not intended for password-hashing, these are mostly legacy algorithms.
Edit (2019): This is wrong. Correction here: https://github.com/k9mail/k-9/issues/1231#issuecomment-567173176

So the only way to make your setup secure is: Use TLS!. I think all mail providers support that currently.

And if you use TLS, there is no reason to use these strange SCRAM thing anymore. Your password is protected at transport level thanks to TLS.
And the best thing: TLS actually protects your mails, while SCRAM is only about your password. So as you actually maybe want to protect your mails, use a secure connection to your mail server (i.e. TLS) and forget this SCRAM thing.

And BTW: It's 2017. TLS is (going/supposed to be) everywhere. And if not, use another mail provider.

[nogweii]

@rugk I think most users are using TLS already now. But Google denies access via all authentication methods except XOAuth2 in IMAP by default. And adds a bunch of scary language when you want to bypass it.

[rugk]

Yeah, but they also do not allow SCAM then. AFAIK Gmail does not allow access by SMTP/POP3 or so at all generally. There may be a setting to activate it in the settings, then it should work – with per-device passwords, possibly.
And OAuth is, unfortunately, not yet supported by IMAP or so.

[philipwhiuk]

I managed to setup a Dovecot server to test this against. I'm mid-way through implementation.

[ntninja]

@philipwhiuk: What's your status on this? Is there any code?

[Neustradamus]

Any news?

Maybe good to see for SCRAM-SHA-1(-PLUS), SCRAM-SHA-224(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-384(-PLUS), SCRAM-SHA-512(-PLUS)

[Neustradamus]

A best issue here:

• https://github.com/k9mail/k-9/issues/4191

[Zash]

Sorry, but this is nonsense. Neither SCRAM-SHA1 nor CRAM-MD5 are secure. MD5 hashes can be broken in seconds, the same for SHA-1, depending on the password of course

Sorry, but this is incorrect. SCRAM-SHA-1 isn't CRAM-MD5 but with SHA-1, it's using a key derivation function (PBKDF2), precisely the kind of thing you should use to deal with passwords. SCRAM allows storing the password in hashed form on both the client and the server side, and only hashes are sent on the wire.

[rugk]

@Zash Read through the wiki article and yeah, you're right. I guess I was misleaded by it's name.

SCRAM-SHA-1 uses PBKDF2 (which uses a HMAC, which is still secure with MD5/SHA-1 even if collisions in MD5 or SHA1 or AFAIK even preimage attacks are known).
Anyway, yes, I have to correct myself: It's actually pretty secure! It even salts passwords! :smiley:

Though in 2020 you'd maybe switch to even nicer password hashing functions than PBKDF2. YOu know, we have Argon2 or just the already nice scrypt or so.

Also, of course I'd still argue there is no security advantage of SCRAM-SHA1 compared to a mail server ~hashing~ stretching the passwords on the server instead of on the client, as TLS is there and the server has to be trusted anyway. :smile:

That said, I see no argument against implementing this in K9 mail anymore, expect of potential complexity, maybe?

Edit: also corrected initial comment, thx @Zash for making me aware of that. :smile:

[Neustradamus]

Any news on it?