The "real" SSO with
-
@girish said in The "real" SSO with:
@nj I think this suggestion can work. I think Duo also has a similar idea - https://duo.com/docs/ldap#test-your-setup (you add the 2FA after the password separated by a comma). The main issue is only to communicate this to all the users, but maybe it's not a problem within small teams.
What happens when the password contains a comma though?
-
-
@girish I think creating separate passwords for individual apps is against what I'm trying to achieve using SSO. The TOTP 2FA is actually more secure, unlike yet another password saved in the same password manager. App passwords stored in the same password manager only protect the password from rogue clients that may leak passwords. But adding the dynamic password feature protects even if the password is compromised.
-
@nj said in The "real" SSO with:
We could have the users append/prepend the 2FA token with their password every time they log in; the Cloudron LDAP server would see if 2FA is enabled on the account, and if enabled, it will extract the password & 2FA code from the password input and perform authentication.
This is bad practice as it needs to assume the password is stored in plain text - Which is not OK.
Best practice dictates that each app that supports MFA (2FA) should have it's own secret code and what not anyway..
-
@murgero This does not need the password to be stored in plaintext in the DB. While checking the credentials, the server has access to the password in plaintext that was just sent by the client.
The problem in what you said is the "each app that supports MFA" part. A lot of apps don't.
-
@nj I think your initial idea/suggestion is valid.
I think there are two separate attack vectors. One that a random mobile app steals your raw password. This is what app password feature tries to solve - it provides you a password that is only valid for that one app. The other is that if your password is leaked because you re-used Cloudron password in some other place (i.e it got into https://haveibeenpwned.com/ and the likes), then having a 2FA atleast protects all services despite password being compromised.
-
If a rogue client is an attack vector, the app-specific password doesn't really save from the damage on that particular app. App-specific password have a long lifetime, so they can be silently misused without your knowledge for a relatively long time.
Whereas, the TOTP tokens are refreshed every 30 seconds or so. Even if someone stole your password, they must (MUST) brute-force the TOTP code after 30 seconds, which is going to trigger the brute-force detection mechanism. With immediate session revocation, the damage can be contained.
Hence I believe the only savior is 2FA if that particular app supports. Unfortunately, not all apps support 2FA; even if they did, it's not really fun to enable 2FA, manage backup codes, and in case the authenticator & backup codes are lost, it's not easy to have the admin bypass 2FA on all services. For example, RocketChat admins should do that by directly changing the user's data using the
mongoshell.I haven't looked into the source code of Cloudron yet, but I'm sure we can also have the app-specific passwords to be appended with a TOTP code if 2FA is enabled on the account. The app-specific password and TOTP will be validated by Cloudron in the same way it would validate the account password.
I believe this system reduces friction:
- users don't fall into a victim of silent misuse of passwords
- users don't need to configure multiple 2fa
- users don't need to print even more backup codes
- admins don't don't need to disable 2fa for individual accounts in worst cases
- Cloudron will have a solid mechanism of authentication
- we can start using more apps [that don't support 2FA yet] as well as custom apps in Cloudron without worrying about 2FA
I'm sorry if this comment sounded like a marketing pitch, but I genuinely believe we should pull this off. I'm fascinated by Cloudron because it has saved me a lot of hassle, and by @girish's support, which is by far the best I've ever received from any service provider!
-
@nj I agree, this should be implemented.
However, this cannot be "app-specific passwords to be appended with a TOTP code". App-specific passwords are made to be stored by mobile / desktop clients, so they will be reused at a later date, at which point the appended TOTP code won't be valid anymore.
This scheme may also break certain apps that rely on basic-auth or something similar, so it should be possible to disable it.
In any case, still seems a great idea
-
Any suggestions on whether this should be app level or cloudron level? per-app, while flexible, might be confusing. Another option, in theory, we can go through each of the apps, find out what supports 2FA and what doesn't and enable this only for apps that don't support 2FA.
-
@girish I think it should be a boolean in the
ldapaddon in CloudronManifest. Of course, there would be no need to enable this for apps that natively support their own 2FA.If the flag is true, and 2FA is enabled on the main server, the ldap addon verifies that the password is of the form
ACTUAL_PASSWORD;TOTP, or is an app-specific password.Also, it would be great to have an env var that says whether or not 2FA is enabled on the main server, so the app package can possibly adapt its interface / show a warning that explains the format / something
It could also be controlled /enabled by each user for each app, with a different TOTP per-app.
-
@girish after giving some more thoughts, I don't see a reason to go through all the apps to see if they support 2FA? This only makes stuff more complicated. Even if the app supports 2FA, the Cloudron 2FA will make it redundant; so we can skip that. If someone would like to skip Cloudron 2FA they're free to use the app's own 2FA if it supports.
There could be a choice of ["Use Cloudron 2FA / Let the app handle it"] just like the choice of user management. If the first option is selected, TOTP is checked, otherwise it is not.
