password protection.

[atarjoe]

Please add an option to secure the mail accounts inside your app by adding a password/template protection in order to access your app.

[philipwhiuk]

The code is open source. Perhaps you'd like to contribute :-)

[vt0r]

I think it's still ok to suggest enhancements, even if you're not able to implement them yourself.

Anyway, Facebook just open-sourced another tool we could possibly use for this specific purpose, known as Conceal: https://facebook.github.io/conceal/

Might be worth taking a look at it as a possible solution for whoever is able to work on this feature.

[cketti]

I'm not a huge fan of this because I believe access control should be handled by the OS. Modern Android versions support multiple user accounts and a guest mode.

However, this is an often requested feature. So code contributions are certainly welcome. The fact that the app has multiple entry points (launcher icon, shortcuts, notifications, …) doesn't make this an easy task, though.

[ocdtrekkie]

This is a cool thing TouchDown (a paid proprietary app) does very well. The cool part is you can make a mail app compliant with Exchange security policies (like PINs to unlock) without requiring giving Exchange "device administrator" status. Essentially, it's a way to separate your employer's data from your personal device on your phone.

[pmasereeuw]

@cketti In my view, access control by the OS is not enough. Sometimes I hand my phone to someone else, for instance to speak on the phone. In such situations, I may not want that person to see my mail. So, an extra password may be useful.

[da-mkay]

I was working on this the last days. I came up with a master lock that works pretty well till now. But it definitely needs some more testers.

Feel free to install and test it and leave a comment. You can download a ready-to-use apk on the releases-page. Or maybe first take a look at the screenshots on my fork page.
You can find the source code changes in the masterlock branch.

Note: I just added a master lock/password. No encryption of the app data. If everything is fine I will fire a pull-request for this.

[cketti]

I thought some more about this and came to the conclusion that I don't want to support this in K-9 Mail at all.

It makes the user interaction model far more complex than necessary. And there are lots of situations where it's not immediately obvious what the right behavior should be, e.g. notification actions. There'd be always the risk that we add a new feature that accidentally allows bypassing the access protection.

Modern Android versions support multiple users and/or guest accounts, also screen pinning. With that in mind I don't see a valid reason to add a user authentication mechanism to K-9 Mail.

[paulcmal]

There'd be always the risk that we add a new feature that accidentally allows bypassing the access protection.

This is always a risk, but not as great a risk as not implementing security at all. I think on-device security is a killer-feature, especially for a mail client that supports end-to-end encryption.

With that in mind I don't see a valid reason to add a user authentication mechanism to K-9 Mail.

You never know how people are going to be able to bypass Android (or any other system) security. Adding another layer of protection is not wasted time when many things depend on protecting your data. I think password protecting in itself may not be useful, but it lays down the basis for locally-encrypted storage which is super useful and in some situations literally life-saving.

You may find examples of such implementations in andotp and silence for instance.

@da-mkay Thank you for your time starting to implement this. If you can port your patches to a more recent K9, i would be glad to help you test it out :)

[nickalcock]

As a side note, I'm adding something vaguely similar (only different). Right now, if you secure your IMAP server with an OTP system (like an NFC-capable YubiKey in OTP mode or something like that, but it doesn't matter what it is, just something where the password is different every time) it is wholly unusable with K9, because K9 can only associate passwords with connections statically. So I'm planning to add something that gets it to ask every time, so you can paste the password in from whatever thing provides it. (And, while I'm about it, I'll boost the max password length, because I can't even authenticate to my mailserver statically: the static password is a response to an HMAC-SHA1 challenge, which at 41 chars is too long for K9's existing password input field!)

If I get this working (no promises, I'm used to systems programming and this is my first ever attempt at Android development), I'll open another issue, since it's only tangentially associated with this one.

[vldmrrr]

I'd say create an issue now regardless if you will implement it yourself - someone else might work on it as well.

[paulcmal]

So I'm planning to add something that gets it to ask every time, so you can paste the password in from whatever thing provides it.

Great idea!

NFC-capable YubiKey in OTP mode

On a personal and off-topic note, i wouldn't consider this secure at all : commercial manufacturer (has incentives to sell backdoors like RSA did for the NSA), not free software / free hardware (see RNG compromission), plus the many potential vulnerabilities on the NFC chip on your phone or yubikey. That's many layers of potential problems in addition to the already many layers of issues on our devices.

[nickalcock]

paulcmal: going even more wildly off-topic (sorry!) particularly given that the thing I plan to implement is in no way Yubikey-specific and will work with anything that generates changing passwords...

... I consider the Yubikey generating old-style non-CCID OTPs "secure enough" because the format of the passwords is known, as is the process by which they are generated; I generated the AES secret it's using to generate those passwords on hardware I control and imported it into the key; I run the authentication server the key is authenticating against and know what every line of it does; and that server is on a network where all access is controlled by authenticating against that very server. The secure element in the key is definitely using AES, I know because the free software library that does the decoding is using AES to do so. So anyone who can crack my passwords in transit and predict the next one has either picked my pocket and physically stolen my key and extracted the AES secret via undocumented magic secret agent sauce, perhaps via a government backdoor that can NFC-emit the AES key (good luck getting the key back to me unnoticed in that case, since it's on a keyring with my front door key on it) or has managed to break AES encryption pretty catastrophically. If they can do that... :)

Oh also the only NFC-capable Yubikey is the Neo, which is using free software (though this is not much use since it's baked into the key and you can't upgrade it) and is not using the Infineon elements vulnerable to the attack you cite. Also, that attack only affects generation of PIV keys on the card, which is a completely different thing to OTP key generation, with no code in common. OTP generation never generates any keys at all, and does not need a source of random numbers (it only AES-encrypts a bunch of incrementing counters with a static secret).

Given all that, the Yubikey in OTP mode seems to be secure against entities smaller than governments: the weak link is not compromising the key, it's attacking my home network, breaking in, and compromising the auth server (though if you've already broken in, I don't see why you'd bother, you already have access to everything it's guarding). If a government wants to see my stuff badly enough, there's really not much I can do -- but doing this at least keeps my mobile phone carrier and anyone spying on the packet stream from getting in.

(Also, it's not really likely to be the NSA nobbling the design of the key. It's MUST, the Swedish external security service. :) )

[paulcmal]

Thanks for your clear and thorough explanation of why you consider your OTP setup secure enough. I had no idea this was possible with the Yubikey NEO :) (i had also no idea Yubikey reverted to using free software, although as you pointed out it's kind of pointless if you can't flash an update)

the thing I plan to implement is in no way Yubikey-specific and will work with anything that generates changing passwords

Sorry in my previous post i meant to say thank you, not "great idea". Thank you for contributing this feature to our beloved mobile mail client :)

Now, as @vldmrrr pointed out, maybe we're off-topic and this discussion should move to a dedicated thread. I mean the discussion about OTP possibilities, for the rest, i'd be glad to read some more on your NFC OTP setup if you ever publish a blog post on the matter.

[nickalcock]

Side side note: they didn't revert to using free software: the Neo is an older key than the Yubikey 4. The Neo's free software is what they used before they decided to go non-free and unreviewable (which was indubitably a terrible move on their part).

I'll get hacking on that feature soon, once I've got down to it in the massive bulging to-do list :)

[Meteor0id]

I don't see a valid reason to add a user authentication mechanism to K-9 Mail.

Request to reopen based on the following:

• Enabling a lock screen for the app can be optional, and this option can be disabled by default. It wouldn't complicate user interaction unless the user himself decides to set a lock screen.
• Yes the OS has protection. But security is never just one layer. Adding additional security is not an obsolete function. My Android pone recently got stolen right after I used it. I can only hope that whomever stole it turned it off, or waited to long and let the phone lock itself, otherwise he had full access to my e-mail. On top of that, Android security isn't perfect, no security is. But if the app itself would also have a lock on it, that would make it much less likely that anyone gains access to it.
• Any banking app I have used ever also uses their own lock screen. They don't do that just because it feels secure, they know fully well that relying solely on the device encryption is still unnecessary high risk.
• e-mail is especially important to secure, it is used to verify ones identity for various app, accounts and services, and it often contains highly private information such as even copies of bank receipts and passports. If there is anything worth some extra security it is your e-mail!
• To those who argue Androids own security is enough: My computer has a password on it, both at work and at home. At home I always lock the door, and at work everyone has to pass the front door and security before reaching my computer. Would you not place a password on your computer anyway? To me it is a no-brainer, of course additional security is necessary!

Yes I understand it would take a lot of effort to add this feature, and it would complicate development in the future as well as we will have to keep checking that we don't accidentally add any bypass for this. But it really is worth it to have some basic security. E-mail is too sensitive. Security deserves a very high if not the first priority, and compromises on security should be an absolutely last resort.

I understand no one is going to start working on this for at least the coming months, but let's please reopen this ticket to acknowledge that it is on the to-do list and that we are open to people writing a few PRs for this.

[proton-byte]

I don't see a valid reason to add a user authentication mechanism to K-9 Mail.

Request to reopen based on the following:

* Enabling a lock screen for the app can be optional, and this option can be disabled by default. It wouldn't complicate user interaction unless the user himself decides to set a lock screen.

* Yes the OS has protection. But security is never just one layer. Adding additional security is not an obsolete function. My Android pone recently got stolen right after I used it. I can only hope that whomever stole it turned it off, or waited to long and let the phone lock itself, otherwise he had full access to my e-mail. On top of that, Android security isn't perfect, no security is. But if the app itself would also have a lock on it, that would make it much less likely that anyone gains access to it.

* Any banking app I have used ever also uses their own lock screen. They don't do that just  because it feels secure, they know fully well that relying solely on the device encryption is still unnecessary high risk.

* e-mail is especially important to secure, it is used to verify ones identity for various app, accounts and services, and it often contains highly private information such as even copies of bank receipts and passports. If there is anything worth some extra security it is your e-mail!

* To those who argue Androids own security is enough: My computer has a password on it, both at work and at home. At home I always lock the door, and at work everyone has to pass the front door and security before reaching my computer. Would you not place a password on your computer anyway? To me it is a no-brainer, of course additional security is necessary!

Yes I understand it would take a lot of effort to add this feature, and it would complicate development in the future as well as we will have to keep checking that we don't accidentally add any bypass for this. But it really is worth it to have some basic security. E-mail is too sensitive. Security deserves a very high if not the first priority, and compromises on security should be an absolutely last resort.

I understand no one is going to start working on this for at least the coming months, but let's please reopen this ticket to acknowledge that it is on the to-do list and that we are open to people writing a few PRs for this.

I support this request. It is really important that an email application provides the ability to enable PIN protection as well as encryption of the database / locally stored emails. And there are a few good reasons for that:

• The app cannot simply be opened if the phone is stolen in an unlocked state.
• The local database and the locally stored e-mails can then no longer be read or changed without it being noticeable.

I think it's unacceptable that so many applications still lack the possibility of local encryption. I know, of course, that this is still a free application, but such feedback is still important. And if I continue to get involved in the development of Android applications in the future, I will of course contribute to that.

[gantheaume]

Sorry to just bump in like this, but I too, would really be interested in this feature. I'd like to add in complement to the two previous comments that for all the fellows like me with a rooted phone, there is another reason to get app level encryption done: it prevents any other app that may inadvertently have slipped through the superuser management (since it's then to the user to get this controlled) to not just have direct access to the passwords and email database. I know it's a very complicated request and that it won't get done quickly, it's fine, but please acknowledge that it has to be done and re-open the issue.

[Kein]

Unless someone engineers and develops solution and PR it - I dont think it is gonna happen by existing maintainers. Which is understandable in one hand, but this feature is really useful. Custom encryption is a manual control when you dont want to rely on Android encryption or dont have faith in it (and multiple exploits in the past is a proof you might be better off not being so reliant on it).

[GNUDimarik]

What if we will use simple SqlCipher and lock screen with password or pin. But this feature will optional. In fork of k-9 we implemented this feature and also if app inactive some time for example 10 seconds app locks again and passord of pin needs to be entered for continue using of the app. If user doesn't want to use password it's possible just use some default one or use standard DB API instead of SqlCipher. So if @cketti hasn't objections I'd implement it when I've time on it. @nickalcock I've ubikey and I'm open to expirements when I have time on it :-)

[Kein]

Tell me about your fork with this feature

[cketti]

So if @cketti hasn't objections I'd implement it when I've time on it.

Your suggestion contains more technical details but seems to be essentially what has been originally proposed. My position hasn't changed. I don't want to support a lock screen in K-9 Mail.

[Kein]

I don't want to support a lock screen in K-9 Mail.

You also dont want to let others to support it.

[Kein]

@GNUDimarik what is your fork, you never replied

[GNUDimarik]

@GNUDimarik what is your fork, you never replied

Sorry. Been busy. In my fork SQLCipher not implemented. I can do this unfortunately I can't spend time to this as previously.

[GNUDimarik]

hey @Kein in this case I think app needs to be locked by some lock screen. That PIN will be key for sqlcipher