[keycloak-user] Securely setting admin passwords

Tue Feb 23 13:51:55 EST 2016

On 23 February 2016 at 15:24, Aikeaguinea <aikeaguinea at xsmail.com> wrote:

> I'd be happy with KEYCLOAK-2501 (accepting the password on the command
> line). Then the docker exec approach wouldn't expose the password; this
> is essentially the approach I started with before I ran into the issue
> with the -p switch. (It would be equally desirable to have the same
> change for add-user --container for the Wildfly password; should I open
> a JIRA with Wildfly about this, or would the implementation of
> KEYCLOAK-2501 require the corresponding modification in Wildfly anyway?)
>

WildFly already supports prompting for the password

>
> Mounting the file via volume was something we looked into. We're setting
> things up in Amazon's Elastic Container Service, which uses autoscaling
> groups to bring up new instances automatically (though we don't think
> we'll really need that aspect of it all that much). My recollection is
> that the setup involved didn't seem worth the trouble because our Docker
> image is in a secure repository anyway. If we have to store the file
> someplace, might as well just copy it into the container and keep it in
> the image; at least that was the thinking. For people who put their
> images on a public registry this wouldn't be a good solution.
>
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Marek Posolda
> <mposolda at redhat.com>
> Date: Tuesday, February 23, 2016 at 4:37 AM
> To: "stian at redhat.com" <stian at redhat.com>, Aikeaguinea
> <aikeaguinea at xsmail.com>
> Cc: keycloak-user <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Securely setting admin passwords
>
> Another possibility is to share the file keycloak-user.json with docker
> via volume. Then it's not hardcoded into the Docker image. The
> entrypoint script can check if the file shared through volume exists and
> copy it to standalone/configuration in that case.
>
> Marek
>
> On 23/02/16 10:10, Stian Thorgersen wrote:
>
>
> 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 - Faster than the air-speed velocity of an
>                           unladen european swallow
>
> _______________________________________________
> 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/ed7e2608/attachment.html 