The "real" SSO with
-
I onboarded my entire team to Cloudron; signed up, mailboxes set up, 2FA enabled, and more. Then I realized that the 2FA setting enabled on Cloudron is useless for other apps. Some apps don't have a 2FA option yet; for example, Taiga, which we use to manage all the projects. Also, Bookstack, where all our internal docs go, supports 2FA.
I have understood how Cloudron works, and that this topic has already been discussed in the forum. I started looking for ways to leverage 2FA settings of Cloudron to protect access to other apps. I have thought of a possible solution.
After researching for a while I discovered a solution. Cloudron itself has an active directory server. 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 pretty trivial because the Cloudron login page has an optional 2FA token field, and the token is only looked required if the user has enabled 2FA.
One of the service offerings I came across has a simple but complete description of this method of using 2FA with LDAP with a dynamic password. https://www.protectimus.com/blog/active-directory-two-factor-authentication/.
This feature is absolutely necessary for me, and I believe there are other people like me. Do you think we could pull this off?
-
No idea if it's possible, but I like the idea. I've mentioned adding client-side certificate authentication to any Cloudron-hosted apps/domains before as well, which I think would be really neat, though probably pretty niche.
-
@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.
One workaround until we implement this is to get your team to create an app specific password - https://cloudron.io/documentation/profile/#app-passwords . With this, each user can generate a new password for each app. If you have a password manager, it will remember it and get you similar security like 2FA.
-
@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.
One workaround until we implement this is to get your team to create an app specific password - https://cloudron.io/documentation/profile/#app-passwords . With this, each user can generate a new password for each app. If you have a password manager, it will remember it and get you similar security like 2FA.
@girish said in The "real" SSO with:
I think this suggestion can work.
Can, but does not have to. If you decide to got this path, for some apps it may not work. Basically all applications that would require you to re authenticate, when you change the password in the backend, would play well with this.
Better would of course be some kind of token authentication (oauth/oidc), but that is not offered by all applications.
-
@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.
One workaround until we implement this is to get your team to create an app specific password - https://cloudron.io/documentation/profile/#app-passwords . With this, each user can generate a new password for each app. If you have a password manager, it will remember it and get you similar security like 2FA.
@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?
--
Dustin Dauncey
www.d19.ca -
@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 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?
-
@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.
One workaround until we implement this is to get your team to create an app specific password - https://cloudron.io/documentation/profile/#app-passwords . With this, each user can generate a new password for each app. If you have a password manager, it will remember it and get you similar security like 2FA.
@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.
-
I onboarded my entire team to Cloudron; signed up, mailboxes set up, 2FA enabled, and more. Then I realized that the 2FA setting enabled on Cloudron is useless for other apps. Some apps don't have a 2FA option yet; for example, Taiga, which we use to manage all the projects. Also, Bookstack, where all our internal docs go, supports 2FA.
I have understood how Cloudron works, and that this topic has already been discussed in the forum. I started looking for ways to leverage 2FA settings of Cloudron to protect access to other apps. I have thought of a possible solution.
After researching for a while I discovered a solution. Cloudron itself has an active directory server. 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 pretty trivial because the Cloudron login page has an optional 2FA token field, and the token is only looked required if the user has enabled 2FA.
One of the service offerings I came across has a simple but complete description of this method of using 2FA with LDAP with a dynamic password. https://www.protectimus.com/blog/active-directory-two-factor-authentication/.
This feature is absolutely necessary for me, and I believe there are other people like me. Do you think we could pull this off?
@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..
--
https://urgero.org
~ Professional Nerd. Freelance Programmer. ~ -
@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.
-
@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 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!
-
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.
-
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.
-
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 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.
