[keycloak-user] Securely setting admin passwords
Stan Silvert
ssilvert at redhat.com
Thu Feb 18 12:26:16 EST 2016
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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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
>>>> <mailto: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
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto: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/20160218/784bdcb7/attachment-0001.html
More information about the keycloak-user
mailing list