• 5
    • 7
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      Passwords are not encrypted in confluence-mail.cfg.xml nor in confluence.cfg.xml; they should be.

      Resolve an encryption scheme for anything requiring security stored on the file system.

            [CONFSERVER-99994] Encrypt all passwords stored on the file system

            Many apps store an encrypted password in a config file.  If you're worried about the ability to update the password in the event that the encrypted password is wrong, either ensure there's a separate utility available to update it and/or allow the user to enter a plaintext password temporarily in the file to get the server to start (that will later be encrypted).  

            There are of course many other options, but at a minimum get rid of the PlainText-By-Default approach currently in use quickly - and implement fancier options in future releases.  It is difficult to understand how this has been open for 12+ years!

            Michael Ferry added a comment - Many apps store an encrypted password in a config file.  If you're worried about the ability to update the password in the event that the encrypted password is wrong, either ensure there's a separate utility available to update it and/or allow the user to enter a plaintext password temporarily in the file to get the server to start (that will later be encrypted).   There are of course many other options, but at a minimum get rid of the PlainText-By-Default approach currently in use quickly - and implement fancier options in future releases.  It is difficult to understand how this has been open for 12+ years!

            Whitebox cryptography is the actual answer you are looking for. See http://www.whiteboxcrypto.com/ for details. There are now a number of companies beginning to offer this technology.

            However, even if you don't use white box cryptography it is not acceptable to say that since "it's possible" for a hacker to gain access to the key that you shouldn't attempt to hide it. Any reasonable level of obfuscation means that a knowledgeable hacker will have to decipher the system's code and figure out where the various decryptions occur. This is significantly harder than just running "strings" on the file. So ANY level of obfuscation is better than none at all.

            Ted Schroeder added a comment - Whitebox cryptography is the actual answer you are looking for. See http://www.whiteboxcrypto.com/ for details. There are now a number of companies beginning to offer this technology. However, even if you don't use white box cryptography it is not acceptable to say that since "it's possible" for a hacker to gain access to the key that you shouldn't attempt to hide it. Any reasonable level of obfuscation means that a knowledgeable hacker will have to decipher the system's code and figure out where the various decryptions occur. This is significantly harder than just running "strings" on the file. So ANY level of obfuscation is better than none at all.

            One possible way to store the passphrase/key for decrypting application startup passwords is to use an environment variable. Another is an interactive prompt or - in case of web applications - a servlet to enter the passphrase by an administrator before the final application startup takes place. See http://www.jasypt.org/ for a framework that supports these approaches.

            Jan Dittberner added a comment - One possible way to store the passphrase/key for decrypting application startup passwords is to use an environment variable. Another is an interactive prompt or - in case of web applications - a servlet to enter the passphrase by an administrator before the final application startup takes place. See http://www.jasypt.org/ for a framework that supports these approaches.

            The vital caveat to my comment was "...without preventing unattended startup."

            It's technically possible to encrypt the passwords, or even the whole config file, but the application has to read them somehow. As Charles pointed out, this leaves you with the choice of having the application wait on startup until an administrator types in the passphrase, or with storing the key somewhere that the application can retrieve it from.
            It's just not practically feasible to require administrator intervention, unless you're willing to accept that startup delay. It's not too bad if an admin is always on hand whenever the users need the application to be available, and if that's the only application s/he needs to intervene with. If they have to log into two dozen different servers after a power-outage, on the other hand, you'll be waiting a long time for everything to become available again.
            If you store the key on the disk so that the application can start up, you're back to protecting the key with the same means we currently use to protect the configuration file. Attempting to obfuscate it just doesn't work - if the application can find it, so can an intruder.

            It's not that we're taking a laissez-faire approach here; there's a fundamental, practical problem that has to be solved - and it's a hard problem.
            Please also remember that this issue is not unique to Confluence, or even to Atlassian - it affects all applications that need to authenticate to a database on startup.

            James Fleming (Inactive) added a comment - The vital caveat to my comment was "...without preventing unattended startup." It's technically possible to encrypt the passwords, or even the whole config file, but the application has to read them somehow. As Charles pointed out, this leaves you with the choice of having the application wait on startup until an administrator types in the passphrase, or with storing the key somewhere that the application can retrieve it from. It's just not practically feasible to require administrator intervention, unless you're willing to accept that startup delay. It's not too bad if an admin is always on hand whenever the users need the application to be available, and if that's the only application s/he needs to intervene with. If they have to log into two dozen different servers after a power-outage, on the other hand, you'll be waiting a long time for everything to become available again. If you store the key on the disk so that the application can start up, you're back to protecting the key with the same means we currently use to protect the configuration file. Attempting to obfuscate it just doesn't work - if the application can find it, so can an intruder. It's not that we're taking a laissez-faire approach here; there's a fundamental, practical problem that has to be solved - and it's a hard problem. Please also remember that this issue is not unique to Confluence, or even to Atlassian - it affects all applications that need to authenticate to a database on startup.

            Norman Abramovitz added a comment - - edited

            So, if I understand James' comment, configuration files contain database access passwords are in plain text. This is could be extremely dangerous. Security only works when there are multiple levels. The password itself should be encrypted as well as the configuration files using different keys. Have we not learned yet, that applications cannot assume they are fully protected by outside security. That plain text database password exposes all your confluence data at the very least. What will it take to get Atlassian to take a more responsible approach to security?

            Norman Abramovitz added a comment - - edited So, if I understand James' comment, configuration files contain database access passwords are in plain text. This is could be extremely dangerous. Security only works when there are multiple levels. The password itself should be encrypted as well as the configuration files using different keys. Have we not learned yet, that applications cannot assume they are fully protected by outside security. That plain text database password exposes all your confluence data at the very least. What will it take to get Atlassian to take a more responsible approach to security?

            please consider this issue with very HIGH LEVEL!

            Mohamed Gargouri added a comment - please consider this issue with very HIGH LEVEL!

            Well that's good to know, except (at least for Jira/Fisheye, we aren't yet running Confluence) it isn't true. The $FISHEYE_INST/config.xml file has a complete list of all the usernames and passwords in clear text. If Confluence does this correctly and Jira/Fisheye doesn't please let me know so that I can file an appropriate bug in a different place. According to your tech support, "That's just the way it is. It's up to you to protect the data on your systems." Hrmmm.

            Ted Schroeder added a comment - Well that's good to know, except (at least for Jira/Fisheye, we aren't yet running Confluence) it isn't true. The $FISHEYE_INST/config.xml file has a complete list of all the usernames and passwords in clear text. If Confluence does this correctly and Jira/Fisheye doesn't please let me know so that I can file an appropriate bug in a different place. According to your tech support, "That's just the way it is. It's up to you to protect the data on your systems." Hrmmm.

            It may be worth clarifying this issue a little. This doesn't relate to user authentication; Confluence has always done the correct thing here, storing hash-digests of user passwords in the database.

            The passwords at issue here are those that Confluence uses when authenticating to its data stores, which are stored in config files for the application (when using the built-in approach) or for the application server (when using JNDI datasources). The application/appserver needs to be able to access these when starting up, in order to authenticate itself to the database server(s). The difficulty lies in making it hard for an attacker to obtain these credentials, without preventing unattended startup of the application.

            James Fleming [Administrative Account] added a comment - It may be worth clarifying this issue a little. This doesn't relate to user authentication; Confluence has always done the correct thing here, storing hash-digests of user passwords in the database. The passwords at issue here are those that Confluence uses when authenticating to its data stores, which are stored in config files for the application (when using the built-in approach) or for the application server (when using JNDI datasources). The application/appserver needs to be able to access these when starting up, in order to authenticate itself to the database server(s). The difficulty lies in making it hard for an attacker to obtain these credentials, without preventing unattended startup of the application.

            I am STUNNED that this issue has been here since 2004 and hasn't been dealt with. This is SO bad, that as a security company, if this problem is not able to be solved I will be forced to stop using Atlassian products. I cannot have any passwords sitting in the clear on any of my file systems. Ever. Not once. Not for any length of time.

            In response to Sulka Hara's original comment, "Figure out some other way to handle this. Just because it's a little bit hard doesn't mean that you should just not do it."

            In response to Charles Miller's absurd comment, "Seriously. Do you think that encrypting passwords is 'of limited value'? You don't encrypt the password in a reversible way. You store a hash (and a salt) for the password. Then when someone enters the password the system adds the salt and hashes the password + salt. If it matches the stored password + salt, then you allow the user in. This isn't new technology. This is the way that all competent password protection systems have worked for years and years."

            Even R Scott Emley who at least expresses the right sentiment doesn't understand the cryptography and security. You can't do things by obscuring them. You have to do things in cryptographically correct ways. I've just explained the usual cryptographically sound method that most systems use.

            So, please, please, please put in the 1-2 weeks that you claim is necessary and get this feature into ALL of your products. We use Jira, Fisheye/Crucible, GreenHopper and were, until finding this problem in all the products considering using confluence.

            Ted Schroeder added a comment - I am STUNNED that this issue has been here since 2004 and hasn't been dealt with. This is SO bad, that as a security company, if this problem is not able to be solved I will be forced to stop using Atlassian products. I cannot have any passwords sitting in the clear on any of my file systems. Ever. Not once. Not for any length of time. In response to Sulka Hara's original comment, "Figure out some other way to handle this. Just because it's a little bit hard doesn't mean that you should just not do it." In response to Charles Miller's absurd comment, "Seriously. Do you think that encrypting passwords is 'of limited value'? You don't encrypt the password in a reversible way. You store a hash (and a salt) for the password. Then when someone enters the password the system adds the salt and hashes the password + salt. If it matches the stored password + salt, then you allow the user in. This isn't new technology. This is the way that all competent password protection systems have worked for years and years." Even R Scott Emley who at least expresses the right sentiment doesn't understand the cryptography and security. You can't do things by obscuring them. You have to do things in cryptographically correct ways. I've just explained the usual cryptographically sound method that most systems use. So, please, please, please put in the 1-2 weeks that you claim is necessary and get this feature into ALL of your products. We use Jira, Fisheye/Crucible, GreenHopper and were, until finding this problem in all the products considering using confluence.

            This feature was requested by Ian Menard of tma.osd.mil via https://support.atlassian.com/browse/JSP-72360

            Brad Mallow [Atlassian] added a comment - This feature was requested by Ian Menard of tma.osd.mil via https://support.atlassian.com/browse/JSP-72360

              Unassigned Unassigned
              nick@atlassian.com Nick Faiz [OLD] (Inactive)
              Votes:
              89 Vote for this issue
              Watchers:
              51 Start watching this issue

                Created:
                Updated: