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