[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730148#comment-16730148
]
Jacques Le Roux commented on OFBIZ-4361:
----------------------------------------
Hi Michael,
The original problem of this issue is that
* we send a password (encrypted or not) in an email.
* There is no check about the userLogin asking for the password change.
* This allows a signed in person to ask a password for another user.
I did not look yet too much into the details of implementation, but here is my
take.
Dennis wrote
{quote}After clicking on the "email password" button...
The user will get an email, with a link in it.
This link will include a tokenID, by which the user will be identified.
{quote}
The token can be a JWT created with JWTManager::createJwt with claims =
[userLoginId: userLoginId, jti: secretJWTkey] and duration = 3600.
Here lies a little issue with the jti (Json Token Id). As the feature is
stateless, we can't rely on a session to store an unique value to check (as in
most cases with JWT use).
An alternative is to store this temporary value in the DB, but we want to
avoid storing things in DB for JWT.
Another better alternative is to use the JWT secret key. It would not be
unique by JWT as the specifications require. But we always know it, and an
attacker should not, else anyway the JWT is useless. This get us back to how
store the secret key. We agreed about keeping it as a property OOTB; and giving
a link from the security properties file to suggest how to better do it in
production. It's not blocking us, but is something we still have to do, I
created OFBIZ-10751 for that.
{quote}After clicking on the link, OFBiz checks, if this is still valid.
If not, the user will be asked to generate a new mail.
{quote}
This can be done with JWTManager::validateToken.
The JWT way fits with all the rest:
{quote}If active, a new form will show up, where the user has to enter his user
name, a new password and the verification of that new password.
After clicking submit, the given user login will be compared to the one which
is set in the token under userLoginId. If not identical, the user will be told,
that his/her user login did not match the one, that requested this password
reset.
If correct, and the passwords are matching too, the user password is changed
with the service "updatePassword".
For this the token is valid for 1h.
If the link in the mail is not clicked, and the password gets changed manually
by the user, the password will remain the same.
It is not possible to reset random passwords of random users anymore, since the
reset is happening at the moment, where the user provides the new password.
{quote}
For the other feature (user registering), Dennis's solution is maybe great but
is more than asked in this issue and should be another Jira.
> 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, 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
(v7.6.3#76005)
