2FA for all LDAP apps
-
@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...
@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.
-
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'smfa_secretvalue 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.
Founder / Coder • My Apps
-
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'smfa_secretvalue 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.
@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.
-
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'smfa_secretvalue 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.
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. -
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. -
@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.
-
@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?
@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.
-
G girish marked this topic as a question on
-
G girish has marked this topic as solved on
