[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931124#comment-16931124
]
Jacques Le Roux edited comment on OFBIZ-4361 at 9/17/19 6:20 AM:
-
BTW, those are still there, maybe useful:
{code:xml}
{code}
Their use was removed in [^OFBIZ-4361_Token-Password-Registration.patch] . I
guess looking at OFBIZ-4983 and
http://svn.apache.org/viewvc?view=revision=1716915 should help
was (Author: jacques.le.roux):
BTW, those are still there, maybe useful:
{code:xml}
{code}
Their use was removed in [^OFBIZ-4361_Token-Password-Registration.patch]
> 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: Sub-task
> 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
> Fix For: Upcoming Branch
>
> 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
(v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930652#comment-16930652
]
Jacques Le Roux edited comment on OFBIZ-4361 at 9/16/19 3:40 PM:
-
Thanks Nicolas, sounds good to me.
Ah, wait. I know where you add/change the "password question": it's when you
change the password in partymngr, it's called "Password Hint". BUt I tried and
I got nothing when asking for hint ("Voir votre aide pour le mot de passe" en
français)
was (Author: jacques.le.roux):
Thanks Nicolas, sounds good to me.
Ah, wait. I know where you add/change the question: it's when you change the
password in partymngr.
> 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: Sub-task
> 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
> Fix For: Upcoming Branch
>
> 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
(v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924551#comment-16924551
]
Jacques Le Roux edited comment on OFBIZ-4361 at 9/8/19 8:21 AM:
While working on OFBIZ-10751 I re-read comments I made in OFBIZ-9833 &
OFBIZ-10307. I stumbled upon
https://github.com/auth0/java-jwt#using-a-keyprovider. though I did not yet
clarified all the points, now that we use {{com.auth0:java-jwt:3.8.2}}, I think
we should consider to do something like in the example demonstrated in this
page but as suggested there:
bq. "with a simple key rotation using JWKS, try the jwks-rsa-java library."
I created OFBIZ-11187 for that
was (Author: jacques.le.roux):
While working on OFBIZ-10751 I re-read comments I made in OFBIZ-9833 &
OFBIZ-10307. I stumbled upon
https://github.com/auth0/java-jwt#using-a-keyprovider. though I did not yet
clarified all the points, now that we use {{com.auth0:java-jwt:3.8.2}}, I think
we should consider to do something like in the example demonstrated in this
page but as suggested there:
bq. "with a simple key rotation using JWKS, try the jwks-rsa-java library."
> 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: Sub-task
> 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
> Fix For: Upcoming Branch
>
> 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
(v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924346#comment-16924346 ] Jacques Le Roux edited comment on OFBIZ-4361 at 9/6/19 3:42 PM: At revision: 1866518, I have slightly modified the security.properties filen also adding a reference to https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc Please review... was (Author: jacques.le.roux): At revision: 1866518, I have slightly modified the security.properties filen also adding a reference to Please review... > 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: Sub-task > 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 > Fix For: Upcoming Branch > > 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 (v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916792#comment-16916792 ] Jacques Le Roux edited comment on OFBIZ-4361 at 8/27/19 3:13 PM: - Concerns in comments: Tobias's comment - 22/Jun/17 12:45 bq. I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins. That could be a concern for users using their email address as username. But it happens that the process always return a success message (albeit not on error of config of course) even when using a non existing usernames. So it's not a concern. It's impossible to discern right to wrong usernames this way. Tobias later bq. the user provides their login, the email is sent to the primary contact email address of the corresponding user Michael's answered bq. I think this would be the safest way for a user who forgot his password but recalls his login/user name. This is what does the patch. Michael also proposed: bq. One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. Tobias then proposed a complete solution 22/Jun/17 15:18 This is not handled at the moment mz4wheeler's comment - 23/Jun/17 17:07 bq. adding a new role, like "allow_password_resets" To change their passwords ecommerce clients need to get access to partymngr. I think that's not secure enough and restriction of the possible actions (eg only allowed to reset password) would be a good idea... Pierre Smits's comment - 10/Sep/18 12:05 bq. This seems to be a CVE, and should be prioritised as such. I don't think so, nobody reported an effective proven way to compromise anything so far I wondered about JTI utilisation. Since the email link is only usable once (else you get a EntityCryptoException as reported above), Nicolas's proposed solution (JWT generation with key salt with userloginId + currentPassword and derived secret key saved in DB) is a kind of JTI. This reminds me about OFBIZ-10751, next task for me... was (Author: jacques.le.roux): Concerns in comments: Tobias's comment - 22/Jun/17 12:45 bq. I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins. That could be a concern for users using their email address as username. But it happens that the process always return a success message (albeit not on error of config of course) even when using a non existing usernames. So it's not a concern. It's impossible to discern right to wrong usernames this way. Tobias later bq. the user provides their login, the email is sent to the primary contact email address of the corresponding user Michael's answered bq. I think this would be the safest way for a user who forgot his password but recalls his login/user name. This is what does the patch. Michael also proposed: bq. One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. Tobias then proposed a complete solution 22/Jun/17 15:18 This is not handled at the moment mz4wheeler's comment - 23/Jun/17 17:07 bq. adding a new role, like "allow_password_resets" To change their passwords ecommerce clients need to get access to partymngr. I think that's not secure enough and restriction of the possible actions (eg only allowed to reset password) would be a good idea... Pierre Smits's comment - 10/Sep/18 12:05 bq. This seems to be a CVE, and should be prioritised as such. I don't think so, nobody reported an effective proven way to compromise anything so far I wondered about JTI utilisation. Since the email link is only usable once (else you get a EntityCryptoException as reported above), Nicolas's proposed solution (JWT generation with key salt with userloginId + currentPassword and derived secret key saved in DB) is strong enough. This reminds me about OFBIZ-10751, next task for 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:
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916577#comment-16916577 ] Jacques Le Roux edited comment on OFBIZ-4361 at 8/27/19 10:38 AM: -- OK, I think I got it: you can use the link in email only once :) We should say it in the email was (Author: jacques.le.roux): OK, I think I got it: you can use the link in email only once :) > 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: Sub-task > 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 (v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915641#comment-16915641
]
Jacques Le Roux edited comment on OFBIZ-4361 at 8/26/19 9:31 AM:
-
For those interested, of course using Gradle continous build can lead to
certain discrepancies if you don't run OFBiz again when needed (eg Java classes
to be reloaded). Only dynamic ressources are updated (ie not Java classes for
instance). Here is what happen when I apply the patch and try to get an
password by email:
{noformat}
2019-08-26 11:21:23,429 |jsse-nio-8443-exec-5 |JavaEventHandler
|E| Problems Processing Event
java.lang.NoSuchMethodError:
org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;
at
org.apache.ofbiz.security.SecurityUtil.generateJwtToAuthenticateUserLogin(SecurityUtil.java:133)
~[main/:?]
at
org.apache.ofbiz.securityext.login.LoginEvents.emailPasswordRequest(LoginEvents.java:269)
~[main/:?]
at
org.apache.ofbiz.securityext.login.LoginEvents.forgotPassword(LoginEvents.java:123)
~[main/:?]
{noformat}
Or do I miss something?
was (Author: jacques.le.roux):
For those interested, of course using Gradle continous build can lead to
certain discrepancies if you don't run OFBiz again when needed (eg Java classes
to be reloaded). Only dynamic ressources are updated (ie not Java classes for
instance). Here is what happen when I apply the patch and try to get an
password by email:
{noformat}
The Following Errors Occurred:
Error calling event: org.apache.ofbiz.webapp.event.EventHandlerException:
Problems processing event: java.lang.NoSuchMethodError:
org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;
(org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;)
{noformat}
Or do I miss something?
> 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: Sub-task
> 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
(v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915641#comment-16915641
]
Jacques Le Roux edited comment on OFBIZ-4361 at 8/26/19 9:29 AM:
-
For those interested, of course using Gradle continous build can lead to
certain discrepancies if you don't run OFBiz again when needed (eg Java classes
to be reloaded). Only dynamic ressources are updated (ie not Java classes for
instance). Here is what happen when I apply the patch and try to get an
password by email:
{noformat}
The Following Errors Occurred:
Error calling event: org.apache.ofbiz.webapp.event.EventHandlerException:
Problems processing event: java.lang.NoSuchMethodError:
org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;
(org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;)
{noformat}
Or do I miss something?
was (Author: jacques.le.roux):
For those interested, of course using Gradle continous build can lead to
certain discrepancies if you don't run OFBiz again when needed (eg Java classes
to rebuild). Only the non static ressources are updated (ie not Java classes
for instance). Here is what happen when I apply the patch and try to get an
password by email:
{noformat}
The Following Errors Occurred:
Error calling event: org.apache.ofbiz.webapp.event.EventHandlerException:
Problems processing event: java.lang.NoSuchMethodError:
org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;
(org.apache.ofbiz.webapp.control.JWTManager.createJwt(Lorg/apache/ofbiz/entity/Delegator;Ljava/util/Map;Ljava/lang/String;I)Ljava/lang/String;)
{noformat}
Or do I miss something?
> 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: Sub-task
> 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
(v8.3.2#803003)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733934#comment-16733934 ] Jacques Le Roux edited comment on OFBIZ-4361 at 1/4/19 5:36 PM: 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 invented 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 :) was (Author: jacques.le.roux): 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
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16730299#comment-16730299 ] Jacques Le Roux edited comment on OFBIZ-4361 at 12/28/18 2:44 PM: -- Hi Nicolas, You are maybe the only one to know all. Could you give us a summary or do we need to review both solutions (mine is only a sketch at this stage)? was (Author: jacques.le.roux): Hi Nicolas, You are maybe the only one to know all. Could you give us a summary or do we need to review both solutions (mine is only a scetch at this stage)? > 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)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724974#comment-16724974 ] Jacques Le Roux edited comment on OFBIZ-4361 at 12/19/18 12:58 PM: --- Hi Dennis, We could set the duration of the JWT associated to the URL to the needed span. There is still a risk of replay of the JWT, but by using a JTI this is not a problem: https://security.stackexchange.com/questions/124624/how-does-jti-prevent-a-jwt-from-being-replayed Also a JWT is independent of a session. was (Author: jacques.le.roux): Hi Dennis, We could set the duration of the JWT associated to the URL to the needed span. There is still a risk of replay of the JWT, but by using a JTI this is not a problem: https://security.stackexchange.com/questions/124624/how-does-jti-prevent-a-jwt-from-being-replayed > 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, > 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)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614620#comment-16614620 ] Jacques Le Roux edited comment on OFBIZ-4361 at 9/14/18 10:04 AM: -- I agree Pierre, this is a blocker to me. But I must say, after looking at the patch, that reviews may take some time... was (Author: jacques.le.roux): I agree Pierre, this is a blocker 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: Michael Brohl >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)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613482#comment-16613482 ] Dennis Balkir edited comment on OFBIZ-4361 at 9/13/18 1:44 PM: --- 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 some new labels to french. Feel free to take you time to review and comment on this patch, since it is quite big. Thanks! was (Author: dennis balkir): 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
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16430349#comment-16430349 ] Benjamin Jugl edited comment on OFBIZ-4361 at 4/9/18 10:29 AM: --- I just reviewed the patch and did some changes myself. I like the approach, but I think that we might consider using hashed tokens in place of the customerRequests, because the plain text URL might really be a security issue. (If you knew a username, you could generate a custRequest by sending the email and than have a script run through all custRequestIds...) I renamed the requests as I found it really hard to read all the different "steps" of the process. And I changed the Error Messages. The programm will no longer give hints about valid or invalid usernames, as it was discussed in this issue. was (Author: bjugl): I just reviewed the patch and did some changes myself. I like the approach, but I think that we might consider creating tokens in place of the customerRequests, because the plain text URL might really be a security issue. (If you knew a username, you could generate a custRequest by sending the email and than have a script run through all custRequestIds...) I renamed the requests as I found it really hard to read all the different "steps" of the process. And I changed the Error Messages. The programm will no longer give hints about valid or invalid usernames, as it was discussed in this issue. > 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, Trunk > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.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)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059335#comment-16059335
]
Tobias Laufkötter edited comment on OFBIZ-4361 at 6/22/17 1:19 PM:
---
{quote}One remaining case is when the user forgets his username/login. He will
(hopefully) always recall his email address so it would be cool if he could
provide his email address. If there is exactly one valid login associated with
this email address, the process can go on.
Else there should be some kind of message to call the administrator or
something.{quote}
Instead of prompting the user to contact an administrator a solution that would
not give away any information about the status of the given email address in
the system would be to send the request to contact an administrator per email.
This way a potential hacker would have no way of getting any information about
the data in the system.
Szenario 1:
The user has forgotten their password, but remembers the username.
# Klick "forgot password"
# provide username
# Message appears "An email with instructions to reclaim the account has been
send to the email adress provided by this account. If you didn't recieve any
email you may have used a different email address or mistyped your username"
# If the username is valid and has an email address an email is sent with a
link to choose a new password.
Szenario 2:
The user has forgotten their password and username but remembers the email
address.
# Klick "forgot password"
# provide email address
# Message appears "An email with instructions to reclaim the account has been
send to this email adress. If you didn't recieve any email you may have used a
different email address or mistyped it"
# If the email address is in the system and belongs
#* to only one userlogin an email is sent with a link to choose a new password.
#* to more than one userlogin an email is sent with instructions to contact an
administrator/customer service
was (Author: tlaufkoetter):
{quote}One remaining case is when the user forgets his username/login. He will
(hopefully) always recall his email address so it would be cool if he could
provide his email address. If there is exactly one valid login associated with
this email address, the process can go on.
Else there should be some kind of message to call the administrator or
something.{quote}
Instead of prompting the user to contact an administrator a solution that would
not give away any information about the status of the given email address in
the system would be to send the request to contact an administrator per email.
This way a potential hacker would have no way of getting any information about
the data in the system.
Szenario 1:
The user has forgotten their password, but remembers the username.
# Klick "forgot password"
# provide username
# Message appears "An email with instructions to reclaim the account has been
send to the email adress provided by this account. If you didn't recieve any
email you may have used a different email address or mistyped your username"
# If the username is valid and has an email address an email is sent with a
link to choose a new password.
Szenario 2:
The user has forgotten their password and username but remembers the email
address.
# Klick "forgot password"
# provide email address
# Message appears "An email with instructions to reclaim the account has been
send to this email adress. If you didn't recieve any email you may have used a
different email address or mistyped it"
# If the email address is in the system and belongs
* to only one userlogin an email is sent with a link to choose a new password.
* to more than one userlogin an email is sent with instructions to contact an
administrator/customer service
> 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, Trunk
> Environment: Ubuntu and others
>Reporter: mz4wheeler
>Assignee: Michael Brohl
> Labels: security
>
> 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
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059301#comment-16059301 ] Michael Brohl edited comment on OFBIZ-4361 at 6/22/17 12:59 PM: ??I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins.?? Yes, good point. We should at least check if a valid email was entered (if we want the email to be provided). ??Additionally, it is my understanding that an email address is not limited to one user login. In a szenario where the user login is not the email address and an association of the same email address to multiple accounts, the determination of the right user login would not be possible.?? That's correct. ??The options I see are:?? ??the user provides their login, the email is sent to the primary contact email address of the corresponding user?? I think this would be the safest way for a user who forgot his password but recalls his login/user name. ??the user provides their login and an email address that is associated with the user login?? better use the above One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. That should pretty much cover all the cases. was (Author: mbrohl): ??I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins.?? Yes, good point. We should at least check if a valid email was entered (if we want the email to be provided). ??Additionally, it is my understanding that an email address is not limited to one user login. In a szenario where the user login is not the email address and an association of the same email address to multiple accounts, the determination of the right user login would not be possible.?? That's correct. ??The options I see are: the user provides their login, the email is sent to the primary contact email address of the corresponding user?? I think this would be the safest way for a user who forgot his password but recalls his login/user name. ??the user provides their login and an email address that is associated with the user login?? better use the above One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. That should pretty much cover all the cases. > 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, Trunk > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl > Labels: security > > 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 (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059301#comment-16059301 ] Michael Brohl edited comment on OFBIZ-4361 at 6/22/17 12:58 PM: ??I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins.?? Yes, good point. We should at least check if a valid email was entered (if we want the email to be provided). ??Additionally, it is my understanding that an email address is not limited to one user login. In a szenario where the user login is not the email address and an association of the same email address to multiple accounts, the determination of the right user login would not be possible.?? That's correct. ??The options I see are: the user provides their login, the email is sent to the primary contact email address of the corresponding user?? I think this would be the safest way for a user who forgot his password but recalls his login/user name. ??the user provides their login and an email address that is associated with the user login?? better use the above One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. That should pretty much cover all the cases. was (Author: mbrohl): ??I believe the user shouldn't get any feedback regarding the success of the password reset. Otherwise one could use this service to check for exisiting email addresses or user logins.?? Yes, good point. We should at least check if a valid email was entered (if we want the email to be provided). ??Additionally, it is my understanding that an email address is not limited to one user login. In a szenario where the user login is not the email address and an association of the same email address to multiple accounts, the determination of the right user login would not be possible. ?? That's correct. ??The options I see are: the user provides their login, the email is sent to the primary contact email address of the corresponding user?? I think this would be the safest way for a user who forgot his password but recalls his login/user name. ??the user provides their login and an email address that is associated with the user login?? better use the above One remaining case is when the user forgets his username/login. He will (hopefully) always recall his email address so it would be cool if he could provide his email address. If there is exactly one valid login associated with this email address, the process can go on. Else there should be some kind of message to call the administrator or something. That should pretty much cover all the cases. > 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, Trunk > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl > Labels: security > > 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 (v6.4.14#64029)
