[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059301#comment-16059301
]
Michael Brohl edited comment on OFBIZ-4361 at 6/22/17 12:58 PM:
----------------------------------------------------------------
??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.??
Yes, good point. We should at least check if a valid email was entered (if we
want the email to be provided).
??Additionally, it is my understanding that an email address is not limited to
one user login. In a szenario where the user login is not the email address and
an association of the same email address to multiple accounts, the
determination of the right user login would not be possible.??
That's correct.
??The options I see are:
the user provides their login, the email is sent to the primary contact email
address of the corresponding user??
I think this would be the safest way for a user who forgot his password but
recalls his login/user name.
??the user provides their login and an email address that is associated with
the user login??
better use the above
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.
That should pretty much cover all the cases.
was (Author: mbrohl):
??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.??
Yes, good point. We should at least check if a valid email was entered (if we
want the email to be provided).
??Additionally, it is my understanding that an email address is not limited to
one user login. In a szenario where the user login is not the email address and
an association of the same email address to multiple accounts, the
determination of the right user login would not be possible. ??
That's correct.
??The options I see are:
the user provides their login, the email is sent to the primary contact email
address of the corresponding user??
I think this would be the safest way for a user who forgot his password but
recalls his login/user name.
??the user provides their login and an email address that is associated with
the user login??
better use the above
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.
That should pretty much cover all the cases.
> 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
> 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
(v6.4.14#64029)
