[keycloak-user] Securely setting admin passwords
Bruno Oliveira
bruno at abstractj.org
Thu Feb 18 10:53:49 EST 2016
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 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/20160218/2f334da4/attachment.html
More information about the keycloak-user
mailing list