[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613482#comment-16613482
]
Dennis Balkir commented on OFBIZ-4361:
--------------------------------------
Hi all.
Some words on the patch I provided:
*+Authentication-Token:+*
There is a new entity called AUTHENTICATION_TOKEN.
This is the core of this new logic. Its field are:
* authenticationTokenId
** This is the Primary Key of the entity
** It's a 36 symbol long randomly generated UUID
* userLoginId
** A userLoginId is set, to make a connection between the token and the user
* tokenUsageTypeId
** Can literally be anything. In the cases provided, this will be filled with
"PASSWORD_RESET" and "ACCOUNT_VERIFICATION"
* invalidationReason
** When the token becomes invalid, this will be empty. It's an easy way to
see, or check, if the token was used or just simply went invalid, because of
temporal reasons
** The service, which "uses" the token, will set "used for authentication" as
the value of this field
* thruDate
* fromDate
* lastUpdatedStamp
* lastUpdatedTxStamp
* createdStamp
* createdTxStamp
There are methods and services to find a single token by ID, by userLogin, by
userLogin and type, to delete a single token or multiple token, for example a
method which is called "deleteUsedTokensById", which will search for all used
token with a specific type, for example "PASSWORD_RESET" and deletes them.
There also is a worker class, which has more methods to, for example, find all
expired token by type and returns them in a list.
+*Other Methods and Services, which use the new entity:*+
There are some new classes and workers, which are aimed primarily into
front-end user registration.
When the user registers him-/herself, a service can be used, which is called
"createDeactivatedUserWithVerification". This will create a disabled user, with
"INITIALLY_DISABLED" set in the DISABLED_BY field and a randomly generated
password.
The service also creates a party, a person and contact data, if provided.
After this a token is generated and an activation-link is sent to the customers
mail.
After clicking on the link, a prompt will ask for the users password. The user
can now set his own password, which will activate the userLogin, and use the
token.
For this the token is valid for 24h. After this, the link is no longer valid,
and the user has to register again.
With this come methods for deleting all inactive, initially disabled user
logins with expired token. This can easily be crafted into jobs and will then
clean the database from dead user entries regularly.
There also is a service for resending the verification mail, using the same
token.
The validation period that remains, is told to the user in the mail.
Another use for the token is the forgot password function (*<<* *the original
reason for this issue*).
After clicking on the "email password" button, there now is something different
happening.
The user will get an email, with a link in it.
This link will include a tokenID, by which the user will be identified.
After clicking on the link, OFBiz checks, if this is still valid.
If not, the user will be asked to generate a new mail.
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.
A big thanks at this point to [~aarrach] for translating all new labels to
french.
Feel free to take you time to review and comment on this patch, since it is
quite big.
Thanks!
> 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: Michael Brohl
> Priority: Major
> Labels: security
> Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch,
> OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.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)
