With regard to Docker, things get more complicated. I believe it's not just the bash history but the Docker history itself that stores the commands. Also, per one of the messages earlier on this chain, it is not advised to put secrets into Docker environment variables. These are accessible in many different ways. *From: *&lt;keycloak-user-bounces(a)lists.jboss.org <mailto:keycloak-user-bounces@lists.jboss.org>> on behalf of Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> *Date: *Thursday, February 18, 2016 at 12:26 PM *To: *&quot;stian(a)redhat.com <mailto:stian@redhat.com>" <stian(a)redhat.com <mailto:stian@redhat.com>> *Cc: *Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>, keycloak-user <keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> *Subject: *Re: [keycloak-user] Securely setting admin passwords On 2/18/2016 12:14 PM, Stian Thorgersen wrote: > It's security vs usability as usual. Allowing passing the password > directly is convenient for developers, for Docker image, for > provisioning tools, etc.. So we're not going to remove that it's > required, but I do appreciate that if not used correctly it's a > potential security risk. The worst case scenario here is really that > someone gets an admins favorite password, as someone that has access > to getting the bash history of that particular user will also be able > to run the add-user script themselves. So if the admin wants to print > his favorite password in clear text in the bash history we should not > stop him. > It's not our responsibility to clear the bash history, so we should > not do that either. If there is a way to stop that one command from being saved in the bash history then we should do it. At the very least, we should print a warning message to let the administrator know he has done something that is potentially insecure. > On 18 February 2016 at 16:53, Bruno Oliveira <bruno(a)abstractj.org > <mailto:bruno@abstractj.org>> wrote: > > It's about balance. I'm not arguing here against it, I just don't > see how it could strengthen security. Nothing will stop people to > get their own gun and automate it with stdin :) > On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert > <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: > > On 2/18/2016 9:29 AM, Bruno Oliveira wrote: >> I can be wrong, but this is not only our responsibility. For >> example, on Linux you are prompted for the password with >> passwd, but at the same time you could circumvent this >> using: echo 12345678 | sudo passwd admin --stdin. >> In this scenario security auditors won't blame the OS for >> this, but pretty much sysadmins and bad security practices. >> Anyways, whatever people think is the best, I'm fine. > I agree with you there. In that case you are doing something > extra to shoot yourself in the foot. We can't guard against > that. > We just shouldn't put the gun in your hand. >> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert >> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: >> >> On 2/18/2016 9:10 AM, Bruno Oliveira wrote: >>> I think the Jira created by Stian pretty much fixes the >>> problem. Nope? >> Stian's JIRA says that if it is not specified on the >> command line then do the prompt. But if we still allow >> setting it from the command line then the password can >> still be saved to the log in plain text. Security >> auditors will always frown on that. >> So I'm saying we should either disallow setting on the >> command line or somehow disable saving to the log. We >> shouldn't rely on an administrator to do the right thing. >>> Something like: >>> ./add-user-keycloak.sh -u user >>> Password: ****** >>> Or >>> ./add-user-keycloak-sh >>> Username: joe >>> Password: ****** >>> If this can't fix the issue, is also possible to >>> disable bash_history temporarily. But I wouldn't take >>> this route, because this is pretty much system >>> administration responsibility. >>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert >>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: >>> >>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote: >>>> On 17 February 2016 at 17:09, Aikeaguinea >>>> <aikeaguinea(a)xsmail.com >>>> <mailto:aikeaguinea@xsmail.com>> wrote: >>>> >>>> It seems the add-user.sh script for changing >>>> the admin password only >>>> accepts the password as a -p command-line >>>> parameter. This would expose >>>> the password in the command history, so I'd >>>> prefer not to use the >>>> command in its current form. >>>> >>>> That's a mistake we'll fix that. If not specified >>>> it should prompt for it. Added >>>> https://issues.jboss.org/browse/KEYCLOAK-2501 >>> After attending several security talks the last >>> couple of days, I've become rather sensitized to >>> this kind of issue. I feel quite strongly that we >>> should never allow the password to be written to >>> history in plain text. I'm also afraid it could >>> cause us to flunk government certifications. >>> On Windows, this really isn't a problem because >>> command history is not saved. After a CMD session >>> ends, the history is lost (unless you install some >>> third-party tool). >>> Perhaps there is a way to temporarily disable >>> logging of command history in the add-user-keycloak.sh? >>>> >>>> Is there another way to do this? >>>> The situation is even more complicated with >>>> Docker, since running the >>>> script to change the Wildfly admin password >>>> requires restarting the >>>> server, which shuts down the container. If you >>>> have an autoscaling >>>> group, the container that gets brought up is >>>> not the container where you >>>> changed the password, but instead the original >>>> container. This seems to >>>> mean that the only way to have Keycloak run in >>>> Dockers in an autoscaling >>>> group is to bake the admin passwords into the >>>> Docker image beforehand. >>>> This isn't ideal; less so if the only way to >>>> add those passwords during >>>> build time is to run the shell script that >>>> exposes the password on the >>>> command line. >>>> >>>> You need to set the password once for your >>>> database. This can be done prior to accessing the >>>> admin console the first time. Take a look at >>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md, >>>> you can use docker exec to do this. >>>> >>>> >>>> -- >>>> http://www.fastmail.com >>>> <http://www.fastmail.com/> - Access your email >>>> from home and the web >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> <mailto:keycloak-user@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>>> <mailto:keycloak-user@lists.jboss.org> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- http://www.fastmail.com - Choose from over 50 domains or use your own _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea(a)xsmail.com <mailto:aikeaguinea@xsmail.com>> wrote: With regard to Docker, things get more complicated. I believe it's not just the bash history but the Docker history itself that stores the commands. What about "docker exec" approach? We've fixed it in 1.9.0.Final so that it'll now prompt for a password if one isn't specified. Also, per one of the messages earlier on this chain, it is not advised to put secrets into Docker environment variables. These are accessible in many different ways. *From: *&lt;keycloak-user-bounces(a)lists.jboss.org <mailto:keycloak-user-bounces@lists.jboss.org>> on behalf of Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> *Date: *Thursday, February 18, 2016 at 12:26 PM *To: *&quot;stian(a)redhat.com <mailto:stian@redhat.com>" <stian(a)redhat.com <mailto:stian@redhat.com>> *Cc: *Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>, keycloak-user <keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>> *Subject: *Re: [keycloak-user] Securely setting admin passwords On 2/18/2016 12:14 PM, Stian Thorgersen wrote: > It's security vs usability as usual. Allowing passing the > password directly is convenient for developers, for Docker image, > for provisioning tools, etc.. So we're not going to remove that > it's required, but I do appreciate that if not used correctly > it's a potential security risk. The worst case scenario here is > really that someone gets an admins favorite password, as someone > that has access to getting the bash history of that particular > user will also be able to run the add-user script themselves. So > if the admin wants to print his favorite password in clear text > in the bash history we should not stop him. > It's not our responsibility to clear the bash history, so we > should not do that either. If there is a way to stop that one command from being saved in the bash history then we should do it. At the very least, we should print a warning message to let the administrator know he has done something that is potentially insecure. > On 18 February 2016 at 16:53, Bruno Oliveira <bruno(a)abstractj.org > <mailto:bruno@abstractj.org>> wrote: > > It's about balance. I'm not arguing here against it, I just > don't see how it could strengthen security. Nothing will stop > people to get their own gun and automate it with stdin :) > On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert > <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: > > On 2/18/2016 9:29 AM, Bruno Oliveira wrote: >> I can be wrong, but this is not only our responsibility. >> For example, on Linux you are prompted for the password >> with passwd, but at the same time you could circumvent >> this using: echo 12345678 | sudo passwd admin --stdin. >> In this scenario security auditors won't blame the OS >> for this, but pretty much sysadmins and bad security >> practices. Anyways, whatever people think is the best, >> I'm fine. > I agree with you there. In that case you are doing > something extra to shoot yourself in the foot. We can't > guard against that. > We just shouldn't put the gun in your hand. >> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert >> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: >> >> On 2/18/2016 9:10 AM, Bruno Oliveira wrote: >>> I think the Jira created by Stian pretty much fixes >>> the problem. Nope? >> Stian's JIRA says that if it is not specified on the >> command line then do the prompt. But if we still >> allow setting it from the command line then the >> password can still be saved to the log in plain >> text. Security auditors will always frown on that. >> So I'm saying we should either disallow setting on >> the command line or somehow disable saving to the >> log. We shouldn't rely on an administrator to do the >> right thing. >>> Something like: >>> ./add-user-keycloak.sh -u user >>> Password: ****** >>> Or >>> ./add-user-keycloak-sh >>> Username: joe >>> Password: ****** >>> If this can't fix the issue, is also possible to >>> disable bash_history temporarily. But I wouldn't >>> take this route, because this is pretty much system >>> administration responsibility. >>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert >>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> >>> wrote: >>> >>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote: >>>> On 17 February 2016 at 17:09, Aikeaguinea >>>> <aikeaguinea(a)xsmail.com >>>> <mailto:aikeaguinea@xsmail.com>> wrote: >>>> >>>> It seems the add-user.sh script for >>>> changing the admin password only >>>> accepts the password as a -p command-line >>>> parameter. This would expose >>>> the password in the command history, so >>>> I'd prefer not to use the >>>> command in its current form. >>>> >>>> That's a mistake we'll fix that. If not >>>> specified it should prompt for it. Added >>>> https://issues.jboss.org/browse/KEYCLOAK-2501 >>> After attending several security talks the last >>> couple of days, I've become rather sensitized >>> to this kind of issue. I feel quite strongly >>> that we should never allow the password to be >>> written to history in plain text. I'm also >>> afraid it could cause us to flunk government >>> certifications. >>> On Windows, this really isn't a problem because >>> command history is not saved. After a CMD >>> session ends, the history is lost (unless you >>> install some third-party tool). >>> Perhaps there is a way to temporarily disable >>> logging of command history in the >>> add-user-keycloak.sh? >>>> >>>> Is there another way to do this? >>>> The situation is even more complicated >>>> with Docker, since running the >>>> script to change the Wildfly admin >>>> password requires restarting the >>>> server, which shuts down the container. If >>>> you have an autoscaling >>>> group, the container that gets brought up >>>> is not the container where you >>>> changed the password, but instead the >>>> original container. This seems to >>>> mean that the only way to have Keycloak >>>> run in Dockers in an autoscaling >>>> group is to bake the admin passwords into >>>> the Docker image beforehand. >>>> This isn't ideal; less so if the only way >>>> to add those passwords during >>>> build time is to run the shell script that >>>> exposes the password on the >>>> command line. >>>> >>>> You need to set the password once for your >>>> database. This can be done prior to accessing >>>> the admin console the first time. Take a look >>>> at >>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md, >>>> you can use docker exec to do this. >>>> >>>> >>>> -- >>>> http://www.fastmail.com >>>> <http://www.fastmail.com/> - Access your >>>> email from home and the web >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> <mailto:keycloak-user@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>>> <mailto:keycloak-user@lists.jboss.org> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- http://www.fastmail.com - Choose from over 50 domains or use your own _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user