2FA for all LDAP apps

marcusquinn

The absence of 2FA on the LDAP login Apps makes me nervous for GDPR and typical security needs nowadays.

I don't know that anyone's ever had a break-in yet, and fail2ban is a good start but expectations for 2FA are increasing.

I wonder if a global solution would be for all Cloudron packaged apps to use a Cloudron login screen with 2FA instead of the app's native logins?

Realising this is development overhead in packaging, open to discussion and alternative suggestions. Hoping this idea is more evolution than revolution.

The more we use any data-silo, the potentially more valuable or attractive it becomes for unscrupulous targeting.

Thoughts?

marcusquinn

To add weight to my own argument, and product differentiation for Cloudron:

Many of these FOSS apps are funded from their own hosted/enterprise/supported offering. Sort of meaning Cloudron is benefiting from the apps development and maintenance but also competing for that revenue.

This sort of global enhancement, just like the consolidation of LDAP/email/backups/DNS admin etc is more of a genuine value-addition.

So, making the LDAP apps logins at-least use a Cloudron LDAP login page would be an extension of that concept and further distinguish from the app devs own hosted options.

mehdi

@marcusquinn said in 2FA for all LDAP apps:

I wonder if a global solution would be for all Cloudron packaged apps to use a Cloudron login screen with 2FA instead of the app's native logins?

This idea would definitely break a lot of stuff, at least for any app which is not strictly limited to a web front-end only. Off the top of my head : nextcloud's desktop apps, anything git, mobile/TV apps for Jellyfin/Emby ...

The cleanest way to support 2FA would be to go back to OAuth login, instead of only LDAP. Then, it would be normal to have a Cloudron-controlled page to log in. The problem is that many apps don't support it, and don't really want to.

The other way clean to do it is to support it at the app level, like Gitlab. Again, many apps don't support it, but I think it would be easier to convince app developers to support it.

The "ugly" way would be to customize the password-verification process for apps, so that in the normal login screen of the app the user can type something like PASSWORD;OTP or something. Bonus: no support from the apps themselves required, only on the platform level. Problem: educating users is gonna be hard. And it's not really neat ^^

marcusquinn

What @medhi says you explain it much better

My main concern apps are Nextcloud, Webmail apps, Mautic, CRM apps, Project Management apps.

Obviously things like Privatebin etc don't need.

I think a solution that was an option for the most sensitive apps would be more desirable than holding out for a solution that covered all of them.

Think of it is as a "2FA supported" or "SSO supported" tag on the apps or something.

In practice, I think the combo of decent firewall settings and using a password manager still give 99%+ security.

It's just that last box to tick, as much as I hate 2FA for user-friendlyness, with my business head, achieving GDPR/PCI/HIPAA compliance standards in this area is both valuable and I don't think is an expectation that will go away.

I'd hope we're all here because we work with data that is important to us and those we work with, and we choose these platforms to keep that safe.

nebulon

As @mehdi mentioned, the root issue is that a good solution needs to have support by the app itself. This either means the app, including all related mobile/desktop clients, need to support this OR they would have a proper OAuth implementation, which also is supported again by those mobile/desktop clients.

The reality is simply that OAuth often is only supported for signup or in a very specific flavor, if at all. We have been there already, in fact we started out with OAuth instead of LDAP. Unfortunately this didn't work out as we wanted it.

The other option really depends on the app authors implementing that.

I think the best way to bring this issue further is to go into the app communities, which currently lack this feature and raise awareness or even better try to help them implement it.

mehdi

Yeah, I think the best way forward is to list which apps are important for you, and start a campaign to lobby for 2FA support in them ^^

Most big apps already do (Gitlab, NextCloud, ...). The rest should be possible to convince, as it's considered an important security feature nowadays

girish

This was brought up by @nj in https://forum.cloudron.io/topic/2433/the-real-sso-with as well. I am open to @mehdi 's idea of password;totp but the UX worries me since you have to communicate this to all your users and they will also need to know which apps support this format and which don't.

mehdi

@girish Yeah, the UX would not be great...

I guess it would be acceptable to allow admins to enable it on a per-app basis, with lots of warnings that they should warn their users. Some people may need it for compliance reason.

I actually used a system that worked like this once. It's weird at first but you get used to it pretty quickly

marcusquinn

OK, I see what you're all saying, and I'm a fan of simple solutions, so I think there's lots of good reasoning here. Save your time and let's put the thread on ice. I'll think about it app by app instead as some should already have the option and I'd not looked into that until exploring the global solution discussion.

Another thought for anyone else following this thread, and it's something I might do. Not 100% secure but might be safer:

Issue Bitwarden login credentials, and enforce 2FA there.
Issue all other credentials (with or without 2FA as appropriate) through Bitwarden, using shared credentials with the password hidden feature.

I know the hidden password isn't completely secure from javascript spying - but it would help protect against user phishing as a vector as the users wouldn't know their own non-2FA credentials to be able to enter them in any other URL or place than Bitwarden will submit them to as the URL from the credentials shared.

It's a teeny bit more setup admin that makes Bitwarden installation and login essential to being able to login to other apps - but Bitwarden can have 2FA enforced.

It doesn't protect from brute-forcing but either the DNS proxy (Cloudflare etc) or the server firewall should make that inefficient and uneconomical without a large IP pool.

Noting some on here have medical clients, hopefully this helps.

It might also help with that usability question on remembering if the login username is a username or an email address.

marcusquinn

The above solution could be a Cloudron Feature too if the Bitwarden API were able to receive and update the Cloudron user's LDAP credentials and share them with their main Cloudron email account with a selected Bitwarden instance.

https://bitwarden.com/help/api/

Maybe the kind of thing @lonk would enjoy making a 200 comment thread on

robi

or we wait and see what happens with Oauth3 and CapTP

marcusquinn

@robi waiting is never a luxury in my business I'm afraid.

We have 20+ staff working our help-desk every day, and they do receive constant phishing attempts, currently all their systems are protected with 2FA systems and a password manager policy for entering credentials in any logins.

The cost of one systems breach could be tens to hundreds of thousands or total business failure, in addition to annual PCI Compliance audits, so the luxury of waiting for security isn't an option when the numbers and risk isn't an option for us at least.

The password manager and good password practice workaround, coupled with a good firewall setup is adequate, it's just something that doesn't happen without a personal or business policy to make that so, hence thinking through options so that the Cloudron apps could have that policy by design.

So, I'm not saying the apps are insecure, just that social engineering and personal computer security are more vulnerable without 2FA. Nothing's perfect but we can still keep the odds in our favour with at least a policy and awareness.

robi

I hear you, not the spirit of my comment.

I've been impressed lately with the WP WAF plugins like WP Cerber that do a good job to notice, escalate and block nefarious IPs probing to get in.

Cloudron could benefit from something similar at the system level.

fail2ban is ok, but could use a dashboard and configurator as an Cloudron App.

Lonkle

@marcusquinn Haha, the only reason for that one million comment thread was because I constantly needed to reference back. I've actually got box down pretty well. And, hey, now a random live blog of me doing 1000 things wrong, and finally getting 1002nd attempt right exists in the world! I'll always get to go back and say "hey, that was my first attempt at learning docker, and cloudron." ️

What are the benefits of this Bitwarden connection with Cloudron?

marcusquinn

@Lonk Based on my policy suggestion above, assuming Bitwarden is installed and 2FA enforced:

Current flow:

Create a Cloudron User.
Create a Bitwarden User.
Create an Organisation called Users.
Create a Collection for each User, including just that User, with Hide Password and Read Only enabled settings.
Create a Bitwarden Login record containing said User Cloudron LDAP Login credentials.
Share said record with said User Collection.
Add all URLs to all allowed Cloudron Apps to said record.
User can now only login to those Cloudron Apps using the Bitwarden extension and can't see or know their Cloudron LDAP password as it is hidden and read-only..

Proposed flow:

Have a setting for each App that selects an available Bitwarden instance.
Complete the above steps from Cloudron to Bitwarden API.
Relax.

Lonkle

Let me mull this over and look into Bitwarden and I'll get back to you.

mehdi

Honestly, I do not like this idea.

It would be great to have it in an external script or something. But integrated into the Cloudron platform ? ... It seems too much of a hack, in my opinion.

fbartels

I agree with @mehdi. That workflow also comes with the downside that while the actual owner of the account does not know his/her own password, you (as the admin) actually now it yourself.

Rather enforce secure passwords and rotate them regularly (in addition to encouraging users to use password managers).

mehdi

@fbartels said in 2FA for all LDAP apps:

and rotate them regularly

(Forcing password rotation when there has been no indication of compromise has actually been proven experimentally to lower security, rather than enhance it : if encourages users to chose simpler passwords, because they're gonna have to remember more passwords)

girish

@mehdi said in 2FA for all LDAP apps:

Forcing password rotation when there has been no indication of compromise has actually been proven experimentally to lower security

This seems to be one of those counter-intuitive ideas. I had no idea it actually lowers security.

Lonkle

I never realized it, but on sites that make me change the password periodically, I totally do keep making them simpler because it's confusing even with password managers cause they mess up saving passwords a lot on password reset pages.

marcusquinn

@Lonk yeah, I hate those forced password changing policies, they are a security risk in themselves as they just increase the likelihood of a keystroke logger being able to capture.

I wrote more on the subject of password security for our team policy here:

https://brandlight.org/h/policies/password-security-policy/

And my thoughts on Security here:

https://www.marcusquinn.com/security/

Hopefully something of interest there to those with similar responsibilities for data security.

Lonkle

@marcusquinn Security has become my newest point of interest in the programming world - amazing how ridiculously insecure things were even 15 years ago.

marcusquinn

@Lonk agreed, and misinformation and information-overload cause a lot of vulnerabilities for people that don't know what we do, and even we find difficult to truly solve. Steps in the right direction though.

marcusquinn

What most people don't realise is that all the add-ons, extensions and social-logins would once have been considered trojans for the snooping capabilities they have.

I mentioned "coffee machine" on a phone call to a friend, hadn't typed it in anywhere or searched anything. Next time I look at Twitter the first ad is for a Nespresso machine.

So, it doesn't matter how good my security is, we all rely on the security of everyone we are connected to.

jdaviescoates

@marcusquinn said in 2FA for all LDAP apps:

Next time I look at Twitter the first ad is for a Nespresso machine.

I only ever look at Twitter through Firefox with ublock origin installed, so don't see ads on there.

The UX is a bit shit in the mobile browser (especially since recent Firefox update, ironically), but that helps me to use it less on my mobile!

marcusquinn

@jdaviescoates Interesting, I deleted the Facebook app a long time ago. Makes me think I should do the same for other social spyware too. Will give it a try.

jdaviescoates

@marcusquinn see also Nitter and similar apps for accessing other platforms.

jdaviescoates

@marcusquinn said in 2FA for all LDAP apps:

I deleted the Facebook app a long time ago

I never even installed it as it asked for such a ridiculous number of permissions.

marcusquinn

@jdaviescoates Nice. will try. Been looking at https://jarvee.com/ - maybe of interest in a similar API access approach but more for data-mining and marketing.

mehdi

@Lonk said in 2FA for all LDAP apps:

amazing how ridiculously insecure things were even 15 years ago.

I think people are going to think the same 15 years from now ^^

mehdi

@marcusquinn said in 2FA for all LDAP apps:

I mentioned "coffee machine" on a phone call to a friend, hadn't typed it in anywhere or searched anything. Next time I look at Twitter the first ad is for a Nespresso machine.

I think it's just a coincidence ^^ There is no reason to think ad companies are literally listening to you 24/7 : it's too costly from a computing power standpoint, so not worth it.

What they're doing is "just" knowing everything else about you : who you're talking to, what your looking at online, what are your interests, your age, where you live ... And based on that, they can just guess that you may be interested in coffee machines.

(Which, if you ask me, is even scarier that being listened to ^^)

marcusquinn

@mehdi I think more likely the person I was talking to had been searching for coffee machine related recently.

I hear a lot of the claims that you'd be able to see the bandwidth if audio was going to central servers but with the computing power in phones I'm pretty sure they can do the local transcription and just send the data encoded for minimal footprint.

It mostly appears to be contact cross-referencing interests but given that any big ad network could acquire data by proxy from a chain of apps to keep their distance from the actual spyware themselves, I'm just increasingly aware of coincidences.

fbartels

@marcusquinn said in 2FA for all LDAP apps:

I hear a lot of the claims that you'd be able to see the bandwidth if audio was going to central servers

You need a ridiculously low amount of bandwidth to transmit proper audio: https://www.wowza.com/blog/opus-codec-the-audio-format-explained

But the discussion has already went off topic enough.

Let's just hope applications will be faster I'm adopting webauthn, than they are at implementing oidc.

jdaviescoates

@marcusquinn said in 2FA for all LDAP apps:

@jdaviescoates Interesting, I deleted the Facebook app a long time ago. Makes me think I should do the same for other social spyware too. Will give it a try.

One thing I've started doing is using the browser "install app/ add to homepage" whatever they call it feature for various things like Twitter/ Mastodon/ this and other Forums I use so they kinda sorta work like apps but really I'm just using the browser (but I stay logged in and don't have to install the actual app)

marcusquinn

@jdaviescoates Ditto! If you install Firefox Focus, that adds a bit more privacy capability to all other browsers too. (iOS at least)

jdaviescoates

@marcusquinn nice, I might give that a spin. I've actually got uBlock Origin and Privacy Badger addons installed on my Firefox Android... but now I'm wondering if they get used/ included in app instances... hope/ guess so!

I've recently tried out Bromite (a privacy focused fork of Chromium) after someone mentioned when I tweeted about an annoyance with using Mastodon using Firefox on Andriod (with long toots it's impossible to reply because you can't get down to the Toot button)... I quite like it but even though it's using uBlock and other filters it doesn't seem to actually block as much as Firefox + uBlock (possible because Bromite doesn't support CSS filter, I think).

Have you looked into good open source source Chromium forks before? Ideally ones that block ads. I find Twitter works better in Chromium based browsers on Android than on Firefox, but I can't stand seeing ads and I don't see them on Firefox with uBlock...

marcusquinn

@jdaviescoates Big fan of Vivaldi browser on macOS but there's no iOS version, there is an Android though, so worth a play, being a Chromium iteration as I understand.

nj

The comment thread on this post seems to have diverted from the original topic. I would like to comment on @marcusquinn's request for 2FA for LDAP apps. As @girish has said, we have had a long discussion about it, and the team couldn't come up with a one-size-fits-all solution. I was expecting the PASSWORD;TOTP feature in version 6 too. Here's my understanding and proposed solution:

1. Apps that have their own 2FA system, like Gogs, Gitlab, Wiki.JS, etc.
NOTE: I have used this trick in quite a few apps to save myself from having dozens of 2FA secrets. I simply replace the app's mfa_secret value with the secret from Cloudron (Hint: while setting up 2FA on your Cloudron account, select to enter code manually, and write the displayed secret in a piece of paper so you can copy it elsewhere).

Cloudron has access to the database so Cloudron could automate this process:

enabling 2FA for that user in the app by authenticating as that user.
replacing the TOTP secret in the app with the TOTP secret from the Cloudron user account.

The 2FA code from Cloudron will also work on the app, so no need to have per-app 2FA codes. But this approach has downsides:

The maintainer of this feature needs to keep things updated when the app's database schema changes!
The apps usually create a new account when the user logs in using LDAP. For the above approach to work, Cloudron should make those changes before the user's account is created on the app.

I have only done this with my own account because it's quite time consuming to replace the TOTP Secret for all users of my Cloudron instance; a script would certainly help.

2. Apps that do note have native support for 2FA
Proposed solutions:

Cloudron adds a feature to support PASSWORD;TOTP as password, and validate TOTP by extracting it from the input. For this to work, all users must be informed. I wish password managers and authenticator apps had a feature to make it easier to auto-fill 2FA codes as well...
can't think of another way, will add if I can come up with something

Enabling 2FA for all apps is an important feature for some users like me, because of compliance reasons & a bit of paranoia. I can't trust everyone to not fall for phishing attacks, so I really wish Cloudron team kept this feature in priority. For the time being, I'm enabling 2FA in per-app basis, and avoiding apps that don't have 2FA built in.

girish

@nj Apart from what you mentioned, I think for 1) there is also the issue that we somehow need to update the 2FA inside the app's database when the cloudron 2fa changes. Recently, I saw that some apps like rocket.chat can pull 2FA from LDAP. I haven't looked into it closely but maybe some sort of standardization is happening in this space.

Can consider this for next release nevertheless. It's actually very easy to implement, the hard part is to not confuse end users. But really, all the hard work has to be done the Cloudron admin to communicate to their users.

hendrikvl

Just searched the forum for any news on 2FA and am happy that the discussion came up again. I would also endorse the proposal of PASSWORD;TOTP. Having no 2FA for some of the apps makes me somewhat nervous nowadays.
I totally understand that this is less than ideal from an UX perspective, but I don't see how it would hurt if admins can optionally enable it.

girish

@hendrikvl Yes, we will try to add this in the next release. This current release (6.1) we pushed out has 2FA for the proxy auth apps now.

humptydumpty

@girish I just logged into Wordpress (dev) with my CR user that has 2FA enabled and it didn't ask me for the code. Is there an option I need to enable somewhere or is this feature still on the to-do list?

girish

@humptydumpty that's correct, this feature didn't get implemented. The 2FA is only implemented on the Cloudron side and not for the apps. There was a parallel discussion going on about how to show what kind of auth is being used in an app in the dashboard. I think we need to show some indication to the user about how to log in before implementing this feature.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

2FA for all LDAP apps