[keycloak-user] Securely setting admin passwords

Bruno Oliveira bruno at abstractj.org
Thu Feb 18 09:10:38 EST 2016


I think the Jira created by Stian pretty much fixes the problem. Nope?

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/39257221/attachment-0001.html 


More information about the keycloak-user mailing list