[keycloak-user] Securely setting admin passwords

Tue Feb 23 04:10:07 EST 2016

On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at 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: *<keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
> <ssilvert at redhat.com>
> *Date: *Thursday, February 18, 2016 at 12:26 PM
> *To: *"stian at redhat.com" <stian at redhat.com>
> *Cc: *Stian Thorgersen <sthorger at redhat.com>, keycloak-user <
> keycloak-user at 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 at 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 at 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 at 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 at redhat.com>
>>>> wrote:
>>>>
>>>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at 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 - Access your email from home and the web
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user <keycloak-user at lists.jboss.org>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/0e2c8648/attachment-0001.html 