<div dir="ltr">I think the best approach is to add keycloak-user.json. Even if we provide some sorta of public key encryption for protecting passwords, at some point would be mandatory for automation scripts to be prompted for the admin's password.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 23, 2016 at 3:19 AM Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you have suggestions to changes/additions we can do to make it more secure feel free to let us now</div><div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2016 at 16:32, Aikeaguinea <span dir="ltr"><<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We're essentially doing this. Since we need to secure the Wildfly admin<br>
password as well, we are basically running the add-user.sh scripts to<br>
generate the keycloak-user.json and mgmt-users.properties before running<br>
the Docker script, and then adding them to the image. This has the<br>
disadvantage of baking the passwords into the image, but at least<br>
they're encrypted and the image is stored in a secure repository, which<br>
is probably as good as we're going to get.<br>
<br>
<br>
<br>
From: <<a href="mailto:keycloak-user-bounces@lists.jboss.org" target="_blank">keycloak-user-bounces@lists.jboss.org</a>> on behalf of Bill Burke<br>
<<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br>
Date: Monday, February 22, 2016 at 10:21 AM<br>
To: "<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>" <<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
<div><div>Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
I'm too lazy to read this entire thread, sorry if somebody already<br>
suggested this, but can't you<br>
<br>
1) Create a minimal realm in your local environment and export the realm<br>
to json.<br>
2) Import this json in your Docker script?<br>
<br>
<br>
<br>
On 2/22/2016 10:10 AM, Aikeaguinea wrote:<br>
With regard to Docker, things get more complicated. I believe it's not<br>
just the bash history but the Docker history itself that stores the<br>
commands.<br>
<br>
Also, per one of the messages earlier on this chain, it is not advised<br>
to put secrets into Docker environment variables. These are accessible<br>
in many different ways.<br>
<br>
From: <<a href="mailto:keycloak-user-bounces@lists.jboss.org" target="_blank">keycloak-user-bounces@lists.jboss.org</a>> on behalf of Stan Silvert<br>
<<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>><br>
Date: Thursday, February 18, 2016 at 12:26 PM<br>
To: "<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>" <<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>><br>
Cc: Stian Thorgersen <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>>, keycloak-user<br>
<<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:<br>
It's security vs usability as usual. Allowing passing the password<br>
directly is convenient for developers, for Docker image, for<br>
provisioning tools, etc.. So we're not going to remove that it's<br>
required, but I do appreciate that if not used correctly it's a<br>
potential security risk. The worst case scenario here is really that<br>
someone gets an admins favorite password, as someone that has access to<br>
getting the bash history of that particular user will also be able to<br>
run the add-user script themselves. So if the admin wants to print his<br>
favorite password in clear text in the bash history we should not stop<br>
him.<br>
<br>
It's not our responsibility to clear the bash history, so we should not<br>
do that either.<br>
If there is a way to stop that one command from being saved in the bash<br>
history then we should do it.<br>
<br>
At the very least, we should print a warning message to let the<br>
administrator know he has done something that is potentially insecure.<br>
<br>
<br>
On 18 February 2016 at 16:53, Bruno Oliveira <<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>><br>
wrote:<br>
It's about balance. I'm not arguing here against it, I just don't see<br>
how it could strengthen security. Nothing will stop people to get their<br>
own gun and automate it with stdin :)<br>
<br>
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:<br>
I can be wrong, but this is not only our responsibility. For example, on<br>
Linux you are prompted for the password with passwd, but at the same<br>
time you could circumvent this using: echo 12345678 | sudo passwd admin<br>
--stdin.<br>
<br>
In this scenario security auditors won't blame the OS for this, but<br>
pretty much sysadmins and bad security practices. Anyways, whatever<br>
people think is the best, I'm fine.<br>
I agree with you there. In that case you are doing something extra to<br>
shoot yourself in the foot. We can't guard against that.<br>
<br>
We just shouldn't put the gun in your hand.<br>
<br>
<br>
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:<br>
I think the Jira created by Stian pretty much fixes the problem. Nope?<br>
Stian's JIRA says that if it is not specified on the command line then<br>
do the prompt. But if we still allow setting it from the command line<br>
then the password can still be saved to the log in plain text. Security<br>
auditors will always frown on that.<br>
<br>
So I'm saying we should either disallow setting on the command line or<br>
somehow disable saving to the log. We shouldn't rely on an<br>
administrator to do the right thing.<br>
<br>
<br>
<br>
Something like:<br>
<br>
./add-user-keycloak.sh -u user<br>
Password: ******<br>
<br>
Or<br>
<br>
./add-user-keycloak-sh<br>
Username: joe<br>
Password: ******<br>
<br>
If this can't fix the issue, is also possible to disable bash_history<br>
temporarily. But I wouldn't take this route, because this is pretty much<br>
system administration responsibility.<br>
<br>
<br>
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:<br>
<br>
<br>
On 17 February 2016 at 17:09, Aikeaguinea <<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>><br>
wrote:<br>
It seems the add-user.sh script for changing the admin password only<br>
accepts the password as a -p command-line parameter. This would expose<br>
the password in the command history, so I'd prefer not to use the<br>
command in its current form.<br>
<br>
That's a mistake we'll fix that. If not specified it should prompt for<br>
it. Added <a href="https://issues.jboss.org/browse/KEYCLOAK-2501" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2501</a><br>
After attending several security talks the last couple of days, I've<br>
become rather sensitized to this kind of issue. I feel quite strongly<br>
that we should never allow the password to be written to history in<br>
plain text. I'm also afraid it could cause us to flunk government<br>
certifications.<br>
<br>
On Windows, this really isn't a problem because command history is not<br>
saved. After a CMD session ends, the history is lost (unless you<br>
install some third-party tool).<br>
<br>
Perhaps there is a way to temporarily disable logging of command history<br>
in the add-user-keycloak.sh?<br>
<br>
<br>
<br>
<br>
Is there another way to do this?<br>
<br>
The situation is even more complicated with Docker, since running the<br>
script to change the Wildfly admin password requires restarting the<br>
server, which shuts down the container. If you have an autoscaling<br>
group, the container that gets brought up is not the container where you<br>
changed the password, but instead the original container. This seems to<br>
mean that the only way to have Keycloak run in Dockers in an autoscaling<br>
group is to bake the admin passwords into the Docker image beforehand.<br>
This isn't ideal; less so if the only way to add those passwords during<br>
build time is to run the shell script that exposes the password on the<br>
command line.<br>
<br>
You need to set the password once for your database. This can be done<br>
prior to accessing the admin console the first time. Take a look at<br>
<a href="https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md" rel="noreferrer" target="_blank">https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md</a>,<br>
you can use docker exec to do this.<br>
<br>
<br>
--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Access your email from home and the web<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
keycloak-user@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
<br>
--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Choose from over 50 domains or use your own<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
</div></div>keycloak-user@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<span><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
</span><span><font color="#888888">--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Or how I learned to stop worrying and<br>
love email again<br>
</font></span><div><div><br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></blockquote></div>