2FA for all LDAP apps
-
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
-
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. -
@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
-
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.
-
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 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.
-
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.
-
@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?
-
@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.
-
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).
-
@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)
-
@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.
-
-
@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.
-
@marcusquinn Security has become my newest point of interest in the programming world - amazing how ridiculously insecure things were even 15 years ago.
-
@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.
-
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.