[ 
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916792#comment-16916792
 ] 

Jacques Le Roux edited comment on OFBIZ-4361 at 8/27/19 3:13 PM:
-----------------------------------------------------------------

Concerns in comments:
Tobias's  comment - 22/Jun/17 12:45
bq. I believe the user shouldn't get any feedback regarding the success of the 
password reset. Otherwise one could use this service to check for exisiting 
email addresses or user logins.
That could be a concern for users using their email address as username. But it 
happens that the process always return a success message (albeit not on error 
of config of course) even when using a non existing usernames. So it's not a 
concern. It's impossible to discern right to wrong usernames this way.

Tobias later
bq. the user provides their login, the email is sent to the primary contact 
email address of the corresponding user
Michael's answered
bq. I think this would be the safest way for a user who forgot his password but 
recalls his login/user name.
This is what does the patch.

Michael also proposed:
bq. One remaining case is when the user forgets his username/login. He will 
(hopefully) always recall his email address so it would be cool if he could 
provide his email address. If there is exactly one valid login associated with 
this email address, the process can go on. Else there should be some kind of 
message to call the administrator or something.
Tobias then proposed a complete solution 22/Jun/17 15:18
This is not handled at the moment

mz4wheeler's comment - 23/Jun/17 17:07
bq.  adding a new role, like "allow_password_resets"
To change their passwords ecommerce clients need to get access to partymngr. I 
think that's not secure enough and restriction of the possible actions (eg only 
allowed to reset password) would be a good idea...

Pierre Smits's comment - 10/Sep/18 12:05
bq. This seems to be a CVE, and should be prioritised as such.
I don't think so, nobody reported an effective proven way to compromise 
anything so far

I wondered about JTI utilisation. Since the email link is only usable once 
(else you get a EntityCryptoException as reported above), Nicolas's proposed 
solution (JWT generation with key salt with userloginId + currentPassword and 
derived secret key saved in DB) is a kind of JTI.

This reminds me about OFBIZ-10751, next task for me...



was (Author: jacques.le.roux):
Concerns in comments:
Tobias's  comment - 22/Jun/17 12:45
bq. I believe the user shouldn't get any feedback regarding the success of the 
password reset. Otherwise one could use this service to check for exisiting 
email addresses or user logins.
That could be a concern for users using their email address as username. But it 
happens that the process always return a success message (albeit not on error 
of config of course) even when using a non existing usernames. So it's not a 
concern. It's impossible to discern right to wrong usernames this way.

Tobias later
bq. the user provides their login, the email is sent to the primary contact 
email address of the corresponding user
Michael's answered
bq. I think this would be the safest way for a user who forgot his password but 
recalls his login/user name.
This is what does the patch.

Michael also proposed:
bq. One remaining case is when the user forgets his username/login. He will 
(hopefully) always recall his email address so it would be cool if he could 
provide his email address. If there is exactly one valid login associated with 
this email address, the process can go on. Else there should be some kind of 
message to call the administrator or something.
Tobias then proposed a complete solution 22/Jun/17 15:18
This is not handled at the moment

mz4wheeler's comment - 23/Jun/17 17:07
bq.  adding a new role, like "allow_password_resets"
To change their passwords ecommerce clients need to get access to partymngr. I 
think that's not secure enough and restriction of the possible actions (eg only 
allowed to reset password) would be a good idea...

Pierre Smits's comment - 10/Sep/18 12:05
bq. This seems to be a CVE, and should be prioritised as such.
I don't think so, nobody reported an effective proven way to compromise 
anything so far

I wondered about JTI utilisation. Since the email link is only usable once 
(else you get a EntityCryptoException as reported above), Nicolas's proposed 
solution (JWT generation with key salt with userloginId + currentPassword and 
derived secret key saved in DB) is strong enough.

This reminds me about OFBIZ-10751, next task for me...


> Any ecommerce user has the ability to reset anothers password (including 
> admin) via "Forget Your Password"
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-4361
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-4361
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework
>    Affects Versions: Release Branch 11.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release 
> Branch 17.12
>         Environment: Ubuntu and others
>            Reporter: mz4wheeler
>            Assignee: Jacques Le Roux
>            Priority: Major
>              Labels: security
>         Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, 
> OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, 
> OFBIZ-4361_Token-Password-Registration.patch
>
>
> Currently, any user (via ecommerce "Forget Your Password") has the ability to 
> reset another users password, including "admin" without permission.  By 
> simply entering "admin" and clicking "Email Password", the following is 
> displayed.
> The following occurred:
> A new password has been created and sent to you. Please check your Email.
> This now forces the user of the ERP to change their password.  It is also 
> possible to generate a dictionary attack against ofbiz because there is no 
> capta code required.  This is serious security risk.
> This feature could be reduced to a certain sub-set of users, whose login name 
> is optionally in the format of an email address, and maybe require a capta 
> code to prevent dictionary attacks.
> For example, limit the feature to role "Customer" of type "Person" which was 
> generated via an ecommerce transaction.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to