[keycloak-user] Securely setting admin passwords

Stan Silvert ssilvert at redhat.com
Thu Feb 18 09:45:02 EST 2016


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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/3df8df5c/attachment.html 


More information about the keycloak-user mailing list