[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732074#comment-16732074
]
Dennis Balkir commented on OFBIZ-4361:
--------------------------------------
Hi [~jacques.le.roux], [~soledad],
first some things on Jacques comment.
{quote}
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}
I don't really know if it woud be much safer to store a secret key, which won't
be unique for one JWT but instead is used for many, inside of a text document.
In case of security this seems kind of counter intuitive to me. And I don't
even think it would be better than having multiple token stored inside of the
database.
The JWT would maybe be a great solution, but in our case, where we could not
save something in the session, since it should work independent of browser
sessions, the JWT might just not be the thing we are looking for, especially if
it includes saving one secret key in a document.
Furthermore, and maybe only in my opinion, the token provided by me is much
more versatile as it is fully customisable and can be stored over long periods
of time, if needed to.
For the fact that it is internally associated with the userLogin, that it will
be used for, it is using OFBiz internal logic and is very easy to verify for
the user, even with so little information given, as the Token-ID in an URL.
No additional information is given to someone who might be grabbing the mail or
whatever.
Maybe there are some advantages, that I missed, but I think that the JWT might
just not be the right solution in terms of overall security and usefullness for
this application. It seems like it would be good for inner-session
verification, but this is not always given for our problem and therefore this
problem might need another solution.
Now for Nicolas:
I did not yet had time to take a real review on your proposal, maybe I should
do this asap.
At first, the idea to combine the two solutions to make a better and maybe more
versatile and secure one, seems not like a bad idea to 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: 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)
