[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"

[Nicolas Malin (Jira)]

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

Jacques Le Roux commented on OFBIZ-4361:
----------------------------------------

Hi Dennis,

bq. 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.

Actually the idea is to not store the secret key (which is unique) in the DB but with one of the safe ways recommended by security experts. As I said I have not yet compiled the ideas we already exchanged about that. I'll then document it, for our users to pick the one which fits most for them.

bq. 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.

The JWT is independent of session. The secret key must be unique and stored in a safe way. It is used to encrypt the JWT. The idea here is to also encrypt it in the JWT as a JTI. This to prevent any possibility for a wo/man in the middle attack. When we get back the JWT we can check the JTI and are then sure it's one of our JWTs.

bq. 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.

The JWT technology is very versatile, widely used. It was invited to secure exchanges, like the ones you want to provide. A JWT has a life span, which can be as long as needed (as ever the shorter the better), and is not stored anywhere. The idea behind JWT is to store the secret key in a place which can't be compromised. The DB is not a such place, for any data.

bq. 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.
Same for the JWT as I proposed, it's the only claim sent with the JTI.

bq. No additional information is given to someone who might be grabbing the mail or whatever.
With my JWT proposition only the userLoginId is an information, all the rest is only payload for security. As a JWT is secure there is no way for a wo/man in the middle attack as long as the secret key is not compromised (hence the need of a really safe place).

bq. Maybe there are some advantages, that I missed,
Security is not guaranteed when storing in a DB, apart if you totally encrypt it which is costly. When using a JWT to secure exchanges you don't face this problem.

bq. but I think that the JWT might just not be the right solution in terms of overall security and usefullness for this application.
I believe it's one of the best solutions for securing mails or other type of exchanges. Your solution is also good, but the fact that you have to store tokens in the DB is not secure.

bq. 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.
The links I gave (14/Dec/18 11:11) show that it's not only good for "inner-session verification". BTW I have used it in  OFBIZ-10307 which is about navigating from a domain to another with automated signed in authentication. So you see it's no only for "inner-session verification". Also it's used by [Auth2|https://oauth.net/2/]  which is about doing SSO with a central server and is also widely used

This said, your solution seems good to me. We "just have" to replace the tokens stored in DB by JWTs in URLs. I have no time at the moment to consider the implementation. But ASAP I'll do; this should not be in months...

I hope I convinced you, else we can continue this conversation :)

> 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)