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

Gaudin Pierre commented on OFBIZ-4361:
--------------------------------------

In fact I think that it does not need to use a token if we use a custRequest to 
manage the demands of password loss.

If one custRequest is created for the password loss request, it is associated 
with the user (Party).
So, into the form of the email, it is enough to add the custrequestId and the 
user login. On the server side we just have to verify that the user party is 
associated with the custRequest.

With custRquest it is also possible to set a life cycle for the request by 
using the date of creation of the custRequest.

For a project we developed such a mechanism. I can postpone it on a trunk and 
make a patch

> 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: Bug
>          Components: framework
>    Affects Versions: Release Branch 11.04, Trunk
>         Environment: Ubuntu and others
>            Reporter: mz4wheeler
>            Assignee: Michael Brohl
>            Priority: Major
>              Labels: security
>
> 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
(v7.6.3#76005)

Reply via email to