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


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Feature Requests
  3. Provide app password during app installation flow

Provide app password during app installation flow

Scheduled Pinned Locked Moved Feature Requests
7 Posts 4 Posters 966 Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      R Offline
      Robin
      wrote on last edited by
      #1

      A number of applications don't have LDAP. This is unfortunate, but what really makes me nervous is the "admin/changeme" credentials that are used by default in a number of applications.

      I understand why this is, but I don't think it's a great solution. I think that a better solution for these cases would be to suggest (or perhaps even require) that a password should be provided during setup, ideally before the image is ever started, so there's no window where someone can log in and cause mischief.

      I guess this would require an install step per-app (to e.g. chuck the password through htpasswd, or whatever the application requires, and then figure out where in the target image to stick the password...) - but I think this would be way better than the current day situation, if not quite as perfect as the grand single-signon utopia I'd like to see.

      1 Reply Last reply
      3
      • nebulonN Offline
        nebulonN Offline
        nebulon
        Staff
        wrote on last edited by
        #2

        I think this was done like it is mostly out of simplicity as well as some apps come pre-setup with admin account via their installers, and those tend to use some admin/admin or admin/changeme or such pattern. So it was/is kinda hard to have code in the package which changes or injects a custom password for those.

        I understand that window of opportunity for a potential malicious actor, however those are apps just installed and on a new subdomain, so it will require quite a bit of dedication to exploit this. But what was making me nervous in the past were instances where changing the admin password was just not done or forgotten, so the changeme was simply used as is.

        In the end I guess we just have to stash the password or an autogenerated unique one in the database and for apps, where we can pre-provision this we support that flow instead of the hardcoded one we currently have. Then there is only one bit off, but that is the case already, the platform has no chance to know if that password was changed within the app, so that information might be out of sync at some point.

        robiR 1 Reply Last reply
        1
        • nebulonN nebulon

          I think this was done like it is mostly out of simplicity as well as some apps come pre-setup with admin account via their installers, and those tend to use some admin/admin or admin/changeme or such pattern. So it was/is kinda hard to have code in the package which changes or injects a custom password for those.

          I understand that window of opportunity for a potential malicious actor, however those are apps just installed and on a new subdomain, so it will require quite a bit of dedication to exploit this. But what was making me nervous in the past were instances where changing the admin password was just not done or forgotten, so the changeme was simply used as is.

          In the end I guess we just have to stash the password or an autogenerated unique one in the database and for apps, where we can pre-provision this we support that flow instead of the hardcoded one we currently have. Then there is only one bit off, but that is the case already, the platform has no chance to know if that password was changed within the app, so that information might be out of sync at some point.

          robiR Offline
          robiR Offline
          robi
          wrote on last edited by
          #3

          @nebulon Perhaps it could be a dual use purpose of doing so, by providing a platform pw reset for the admin acct to initial conditions.

          How many different ways are pw's stored?
          File & DB & ..??

          Conscious tech

          nebulonN 1 Reply Last reply
          0
          • robiR robi

            @nebulon Perhaps it could be a dual use purpose of doing so, by providing a platform pw reset for the admin acct to initial conditions.

            How many different ways are pw's stored?
            File & DB & ..??

            nebulonN Offline
            nebulonN Offline
            nebulon
            Staff
            wrote on last edited by
            #4

            @robi well in this case we talk about the app local admin credentials, those are always stored within the app and that depends on how the app stores local accounts.

            I don't quite see what a password reset from the platform side would do. Often the admin account also has some pre-set dummy email address and generally those flows are highly app specific and hard to cover reliably.

            robiR 1 Reply Last reply
            0
            • nebulonN nebulon

              @robi well in this case we talk about the app local admin credentials, those are always stored within the app and that depends on how the app stores local accounts.

              I don't quite see what a password reset from the platform side would do. Often the admin account also has some pre-set dummy email address and generally those flows are highly app specific and hard to cover reliably.

              robiR Offline
              robiR Offline
              robi
              wrote on last edited by
              #5

              @nebulon My point still stands, as there are only so many ways that apps store credentials. If it can be mapped out for the majority of cases then the install packaging includes a function to set a pw by pulling it from the Install UI or separate integration with a Vault or PW Mgr.

              Conscious tech

              1 Reply Last reply
              0
              • R Offline
                R Offline
                Robin
                wrote on last edited by
                #6

                @nebulon The way I was thinking about this working would be to leave this entirely up to the apps rather than involving box/db in this much at all. Come up with a decent abstraction for it, and offering that as part of the manifest perhaps? Something like this:

                "credentialSetup": {
                	"path": "/app/code/foo",
                        "arguments": [ "--user", "CLOUDRON_INSTALL_USER", " --password", "CLOUDRON_INSTALL_PASSWORD" ],
                	"username": {
                	    "default": "admin",
                	    "canChangeAtInstallation": true,
                	    "canChangeAfterInstallation": true,
                	},
                	"password": {
                	    "default": "changeme",
                	    "canChangeAtInstallation": true,
                	    "canChangeAfterInstallation": true,
                	}
                }
                

                Use would be as follows.

                On install, check for credentialSetup presence.
                If it's not present, then don't do anything.
                If it's present, validate it (path must be present).

                If at least one canChangeAtInstallation is true, then show a workflow asking them to set up an account/password before allowing the thing to be started.
                The initial value for fields is set to its default if present (we should ideally not provide a default password, but it's just there for completeness).
                If a field doesn't have canChangeAtInstallation, then it is set to read-only.

                (The same logic exists for AfterInstallation, but it's separate in my manifest suggestion, as I can imagine that some apps won't be able to allow changing either user or password easily. But this could also be done later, as a separate feature. I think the installation flow is the most important part.)

                When the user enters the login information, run credentialSetup.path in the image, replacing CLOUDRON_INSTALL_USER and CLOUDRON_INSTALL_PASSWORD in any of the arguments with the user-provided information.

                Treat exit code 0 as "login information was successfully set", anything else is an error (and intercept anything on stderr back to send back to the user).

                --

                This will rely on then updating apps to have a helper script to actually make this work, but it's a low priority task anyway...

                ... and I guess it would also mean that older box's wouldn't be able to install apps updated to use this, unless they still also defaulted to admin/changeme on the image itself, but that's not really a problem I think.

                mehdiM 1 Reply Last reply
                2
                • R Robin

                  @nebulon The way I was thinking about this working would be to leave this entirely up to the apps rather than involving box/db in this much at all. Come up with a decent abstraction for it, and offering that as part of the manifest perhaps? Something like this:

                  "credentialSetup": {
                  	"path": "/app/code/foo",
                          "arguments": [ "--user", "CLOUDRON_INSTALL_USER", " --password", "CLOUDRON_INSTALL_PASSWORD" ],
                  	"username": {
                  	    "default": "admin",
                  	    "canChangeAtInstallation": true,
                  	    "canChangeAfterInstallation": true,
                  	},
                  	"password": {
                  	    "default": "changeme",
                  	    "canChangeAtInstallation": true,
                  	    "canChangeAfterInstallation": true,
                  	}
                  }
                  

                  Use would be as follows.

                  On install, check for credentialSetup presence.
                  If it's not present, then don't do anything.
                  If it's present, validate it (path must be present).

                  If at least one canChangeAtInstallation is true, then show a workflow asking them to set up an account/password before allowing the thing to be started.
                  The initial value for fields is set to its default if present (we should ideally not provide a default password, but it's just there for completeness).
                  If a field doesn't have canChangeAtInstallation, then it is set to read-only.

                  (The same logic exists for AfterInstallation, but it's separate in my manifest suggestion, as I can imagine that some apps won't be able to allow changing either user or password easily. But this could also be done later, as a separate feature. I think the installation flow is the most important part.)

                  When the user enters the login information, run credentialSetup.path in the image, replacing CLOUDRON_INSTALL_USER and CLOUDRON_INSTALL_PASSWORD in any of the arguments with the user-provided information.

                  Treat exit code 0 as "login information was successfully set", anything else is an error (and intercept anything on stderr back to send back to the user).

                  --

                  This will rely on then updating apps to have a helper script to actually make this work, but it's a low priority task anyway...

                  ... and I guess it would also mean that older box's wouldn't be able to install apps updated to use this, unless they still also defaulted to admin/changeme on the image itself, but that's not really a problem I think.

                  mehdiM Offline
                  mehdiM Offline
                  mehdi
                  App Dev
                  wrote on last edited by
                  #7

                  I think @robin 's suggestion seems well thought out. The big advantage is that it would be totally optional to do it for apps for which it would be hard, while providing a significantly better UX for apps which do support it.

                  1 Reply Last reply
                  1
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Bookmarks
                    • Search