2:03 a.m.
Hello list,
Via an admin portal of a customer I am working for, they provide a feature
where an admin can edit the user's data, including setting a new password.
For the sake of atomicity, all update steps first go through a series of
validations for all modified data before actually committing the changes
and (if needed) updating the keycloak password
At the moment, there is no way to pre-update do a validity check of the
updated password against keycloak's configured password policy(ies)
Therefor I would propose to have a validate-password endpoint in the Admin
API.
I've made a pull request already here:
* https://github.com/keycloak/keycloak/pull/4229
Any thoughts on this?
Kind regards,
Wim
3:43 a.m.
I think the flow of allowing admins to set the users passwords are a bit
broken in the first place. No-one should know a users password, but
themselves. A better flow would be to send a password-reset link to users
through email and let them set the initial password themselves.
However, I can see that might not work for everyone so I don't feel to
strongly about not accepting this change. Let's see what others think about
it.
On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute(a)gmail.com> wrote:
Hello list,
Via an admin portal of a customer I am working for, they provide a feature
where an admin can edit the user's data, including setting a new password.
For the sake of atomicity, all update steps first go through a series of
validations for all modified data before actually committing the changes
and (if needed) updating the keycloak password
At the moment, there is no way to pre-update do a validity check of the
updated password against keycloak's configured password policy(ies)
Therefor I would propose to have a validate-password endpoint in the Admin
API.
I've made a pull request already here:
* https://github.com/keycloak/keycloak/pull/4229
Any thoughts on this?
Kind regards,
Wim
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:10 a.m.
I'm 50/50 on this. And I fully agree that no one should know a users
password. On the other hand I understand that might not work for
everyone.
If we move forward with this, we might not just
be increasing the attack surface. But also would enabling people to
do creative things like, store user's password into their database in plain
text.
On 2017-06-27, Stian Thorgersen wrote:
I think the flow of allowing admins to set the users passwords are a
bit
broken in the first place. No-one should know a users password, but
themselves. A better flow would be to send a password-reset link to users
through email and let them set the initial password themselves.
However, I can see that might not work for everyone so I don't feel to
strongly about not accepting this change. Let's see what others think about
it.
On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute(a)gmail.com> wrote:
> Hello list,
>
> Via an admin portal of a customer I am working for, they provide a feature
> where an admin can edit the user's data, including setting a new password.
>
> For the sake of atomicity, all update steps first go through a series of
> validations for all modified data before actually committing the changes
> and (if needed) updating the keycloak password
>
> At the moment, there is no way to pre-update do a validity check of the
> updated password against keycloak's configured password policy(ies)
>
> Therefor I would propose to have a validate-password endpoint in the Admin
> API.
>
> I've made a pull request already here:
> * https://github.com/keycloak/keycloak/pull/4229
>
> Any thoughts on this?
>
> Kind regards,
> Wim
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
7:31 a.m.
All this does is allow checking if a password is accepted by the password
policies. That's it. I can't see how that increases any attack surface?
On 27 June 2017 at 14:10, Bruno Oliveira <bruno(a)abstractj.org> wrote:
I'm 50/50 on this. And I fully agree that no one should know a
users
password. On the other hand I understand that might not work for
everyone.
If we move forward with this, we might not just
be increasing the attack surface. But also would enabling people to
do creative things like, store user's password into their database in plain
text.
On 2017-06-27, Stian Thorgersen wrote:
> I think the flow of allowing admins to set the users passwords are a bit
> broken in the first place. No-one should know a users password, but
> themselves. A better flow would be to send a password-reset link to users
> through email and let them set the initial password themselves.
>
> However, I can see that might not work for everyone so I don't feel to
> strongly about not accepting this change. Let's see what others think
about
> it.
>
> On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute(a)gmail.com>
wrote:
>
> > Hello list,
> >
> > Via an admin portal of a customer I am working for, they provide a
feature
> > where an admin can edit the user's data, including setting a new
password.
> >
> > For the sake of atomicity, all update steps first go through a series
of
> > validations for all modified data before actually committing the
changes
> > and (if needed) updating the keycloak password
> >
> > At the moment, there is no way to pre-update do a validity check of the
> > updated password against keycloak's configured password policy(ies)
> >
> > Therefor I would propose to have a validate-password endpoint in the
Admin
> > API.
> >
> > I've made a pull request already here:
> > * https://github.com/keycloak/keycloak/pull/4229
> >
> > Any thoughts on this?
> >
> > Kind regards,
> > Wim
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
7:52 a.m.
If I understood correctly, the password could be provided here
https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f861...,
right? If yes. I could implement my own password validator web app to
validate passwords and interact with KC. Now, instead of worry with the
call between the client and KC server, I could have a third server to worry
about or a shell script. Because it's possible.
Instead of targeting Keycloak only (which is built with security in mind),
now people could target my password validation app (not so concerned with
security). This is just an example, and I'm not saying this is the end of
the world. What I'm saying that this opens a new door for people to be
creative.
On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute(a)gmail.com>
wrote:
Hello list,
Via an admin portal of a customer I am working for, they provide a feature
where an admin can edit the user's data, including setting a new password.
For the sake of atomicity, all update steps first go through a series of
validations for all modified data before actually committing the changes
and (if needed) updating the keycloak password
At the moment, there is no way to pre-update do a validity check of the
updated password against keycloak's configured password policy(ies)
Therefor I would propose to have a validate-password endpoint in the Admin
API.
I've made a pull request already here:
* https://github.com/keycloak/keycloak/pull/4229
Any thoughts on this?
Kind regards,
Wim
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:29 a.m.
This does not validate the password as in checking if it is the same as the
user's current one but only checks if a new password might violate the
realm's password policies or not so I do not really see an issue here to be
honest.
On Tue, Jun 27, 2017 at 2:52 PM Bruno Oliveira <bruno(a)abstractj.org> wrote:
If I understood correctly, the password could be provided here
https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f861...,
right? If yes. I could implement my own password validator web app to
validate passwords and interact with KC. Now, instead of worry with the
call between the client and KC server, I could have a third server to worry
about or a shell script. Because it's possible.
Instead of targeting Keycloak only (which is built with security in mind),
now people could target my password validation app (not so concerned with
security). This is just an example, and I'm not saying this is the end of
the world. What I'm saying that this opens a new door for people to be
creative.
On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute(a)gmail.com>
wrote:
> Hello list,
>
> Via an admin portal of a customer I am working for, they provide a feature
> where an admin can edit the user's data, including setting a new password.
>
> For the sake of atomicity, all update steps first go through a series of
> validations for all modified data before actually committing the changes
> and (if needed) updating the keycloak password
>
> At the moment, there is no way to pre-update do a validity check of the
> updated password against keycloak's configured password policy(ies)
>
> Therefor I would propose to have a validate-password endpoint in the Admin
> API.
>
> I've made a pull request already here:
> * https://github.com/keycloak/keycloak/pull/4229
>
> Any thoughts on this?
>
> Kind regards,
> Wim
>
_______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9 a.m.
I still don't see the door that is being opened. It's just validating if a
password supplied by the potential attacker is good enough to pass our
password policies. I.e. is it long enough and such. It doesn't give any
opportunity to check if it's a real password or update it or anything?
On 27 June 2017 at 14:52, Bruno Oliveira <bruno(a)abstractj.org> wrote:
If I understood correctly, the password could be provided here
https://github.com/keycloak/keycloak/pull/4229/files#diff-
2d5026806b9f86138813c99521f40597R782,
right? If yes. I could implement my own password validator web app to
validate passwords and interact with KC. Now, instead of worry with the
call between the client and KC server, I could have a third server to worry
about or a shell script. Because it's possible.
Instead of targeting Keycloak only (which is built with security in mind),
now people could target my password validation app (not so concerned with
security). This is just an example, and I'm not saying this is the end of
the world. What I'm saying that this opens a new door for people to be
creative.
On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute(a)gmail.com
>
wrote:
> Hello list,
>
> Via an admin portal of a customer I am working for, they provide a
feature
> where an admin can edit the user's data, including setting a new
password.
>
> For the sake of atomicity, all update steps first go through a series of
> validations for all modified data before actually committing the changes
> and (if needed) updating the keycloak password
>
> At the moment, there is no way to pre-update do a validity check of the
> updated password against keycloak's configured password policy(ies)
>
> Therefor I would propose to have a validate-password endpoint in the
Admin
> API.
>
> I've made a pull request already here:
> * https://github.com/keycloak/keycloak/pull/4229
>
> Any thoughts on this?
>
> Kind regards,
> Wim
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:30 p.m.
Yep, I understand everything that you said. My argument is based on the
idea that someone could potentially leave this server unprotected (let's
call password validation server), and an attacker intercept/collect these
password to construct a dictionary attack for example. This is pretty much
why I said it increases the attack surface.
Anyways, that's only my 2 cents. Whatever is the best for all, I'm aboard.
On Tue, Jun 27, 2017 at 11:00 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
I still don't see the door that is being opened. It's just
validating if a
password supplied by the potential attacker is good enough to pass our
password policies. I.e. is it long enough and such. It doesn't give any
opportunity to check if it's a real password or update it or anything?
On 27 June 2017 at 14:52, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> If I understood correctly, the password could be provided here
>
>
https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f861...
> ,
> right? If yes. I could implement my own password validator web app to
> validate passwords and interact with KC. Now, instead of worry with the
> call between the client and KC server, I could have a third server to
> worry
> about or a shell script. Because it's possible.
>
> Instead of targeting Keycloak only (which is built with security in mind),
> now people could target my password validation app (not so concerned with
> security). This is just an example, and I'm not saying this is the end of
> the world. What I'm saying that this opens a new door for people to be
> creative.
>
> On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <
> wim.vandenhaute(a)gmail.com>
> wrote:
>
> > Hello list,
> >
> > Via an admin portal of a customer I am working for, they provide a
> feature
> > where an admin can edit the user's data, including setting a new
> password.
> >
> > For the sake of atomicity, all update steps first go through a series of
> > validations for all modified data before actually committing the changes
> > and (if needed) updating the keycloak password
> >
> > At the moment, there is no way to pre-update do a validity check of the
> > updated password against keycloak's configured password policy(ies)
> >
> > Therefor I would propose to have a validate-password endpoint in the
> Admin
> > API.
> >
> > I've made a pull request already here:
> > * https://github.com/keycloak/keycloak/pull/4229
> >
> > Any thoughts on this?
> >
> > Kind regards,
> > Wim
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2758
days inactive
2758
days old
7 comments
3 participants
participants (3)
-
Bruno Oliveira -
Stian Thorgersen -
Wim Vandenhaute