Password reset for admin?

[Mike Z]

Why is it that *any* user can, using the password reset or "Forgot
Your Password" can actually force "admin" to change the password?  Is
there a way to turn this off?

[BJ Freeman]

for production systems do not use "admin" as a lognin.
it is never created.

Mike sent the following on 7/30/2011 12:10 AM:
> Why is it that *any* user can, using the password reset or "Forgot
> Your Password" can actually force "admin" to change the password?  Is
> there a way to turn this off?
>

[Mike Z]

There must be something more.  Any organization would have generic
logins, like "sales", or it would be easy to guess employee logins
from the "about us" page.  It makes sense that the password reset
should be intended ONLY for customers, not (any) system-type login.

I would think that the password reset feature should be limited to
certain roles, like "Customer".

On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
> for production systems do not use "admin" as a lognin.
> it is never created.
>
> Mike sent the following on 7/30/2011 12:10 AM:
>> Why is it that *any* user can, using the password reset or "Forgot
>> Your Password" can actually force "admin" to change the password?  Is
>> there a way to turn this off?
>>
>

[BJ Freeman]

They may have a party Sales, at least in my systems, the login is email
addresses. it is harder for dictionary attracts to be effective.


Mike sent the following on 7/30/2011 7:41 AM:

> There must be something more.  Any organization would have generic
> logins, like "sales", or it would be easy to guess employee logins
> from the "about us" page.  It makes sense that the password reset
> should be intended ONLY for customers, not (any) system-type login.
>
> I would think that the password reset feature should be limited to
> certain roles, like "Customer".
>
> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>> for production systems do not use "admin" as a lognin.
>> it is never created.
>>
>> Mike sent the following on 7/30/2011 12:10 AM:
>>> Why is it that *any* user can, using the password reset or "Forgot
>>> Your Password" can actually force "admin" to change the password?  Is
>>> there a way to turn this off?
>>>
>>
>

[BJ Freeman]

put a flag on the login entity, canresetpassword.
it is only set true when the customer loging is first created.
This way others not normally able to canresetpassword can be manually set
can also add properties like canresetinternalorgpasswrod
so an scheduled service can verify nightly that the rules are complied with.

Mike sent the following on 7/30/2011 7:41 AM:

> There must be something more.  Any organization would have generic
> logins, like "sales", or it would be easy to guess employee logins
> from the "about us" page.  It makes sense that the password reset
> should be intended ONLY for customers, not (any) system-type login.
>
> I would think that the password reset feature should be limited to
> certain roles, like "Customer".
>
> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>> for production systems do not use "admin" as a lognin.
>> it is never created.
>>
>> Mike sent the following on 7/30/2011 12:10 AM:
>>> Why is it that *any* user can, using the password reset or "Forgot
>>> Your Password" can actually force "admin" to change the password?  Is
>>> there a way to turn this off?
>>>
>>
>

[BJ Freeman]

even if someone request a password for admin it will only go to the
email account specified, in the profile.

I do run a nightly service that is like my own dictionary service for
passwords that are common. Then the systems sends a password reset to
the email.

BJ Freeman sent the following on 7/30/2011 10:22 AM:

> They may have a party Sales, at least in my systems, the login is email
> addresses. it is harder for dictionary attracts to be effective.
>
>
> Mike sent the following on 7/30/2011 7:41 AM:
>> There must be something more.  Any organization would have generic
>> logins, like "sales", or it would be easy to guess employee logins
>> from the "about us" page.  It makes sense that the password reset
>> should be intended ONLY for customers, not (any) system-type login.
>>
>> I would think that the password reset feature should be limited to
>> certain roles, like "Customer".
>>
>> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>>> for production systems do not use "admin" as a lognin.
>>> it is never created.
>>>
>>> Mike sent the following on 7/30/2011 12:10 AM:
>>>> Why is it that *any* user can, using the password reset or "Forgot
>>>> Your Password" can actually force "admin" to change the password?  Is
>>>> there a way to turn this off?
>>>>
>>>
>>
>

[c.schinzer]

From a data security perspective your statement about 'Any organization
would have generic accounts' is dangerous, IMHO.

If under stricter data security regulations, you would first of all want
traceability of who did what in the system, hence you want individual
accounts. And initiatives like the Payment Card Industry Data Security
Standards are addressing exactly those kind of issues and enforcing such
policies.

So beware when using 'group accounts' over individual logins. They may be
easy to use for everyone but then beware that it's also to hack them (who
would use a cryptic password on a group account .... ?) or be nasty with
enforced password resets.

I tend to use either email or even generic xAdmin01 or such which are
abstracted. On production OFBiz systems, I do not use any of the demo
accounts as well.

Then BJ's point perfectly kicks in that user names are no longer guessable
and thus your pain would go away.

Just my 0.02 EUR.
Greets


Carsten


Othrwise

2011/7/30 Mike <[hidden email]>

> There must be something more.  Any organization would have generic
> logins, like "sales", or it would be easy to guess employee logins
> from the "about us" page.  It makes sense that the password reset
> should be intended ONLY for customers, not (any) system-type login.
>
> I would think that the password reset feature should be limited to
> certain roles, like "Customer".
>
> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
> > for production systems do not use "admin" as a lognin.
> > it is never created.
> >
> > Mike sent the following on 7/30/2011 12:10 AM:
> >> Why is it that *any* user can, using the password reset or "Forgot
> >> Your Password" can actually force "admin" to change the password?  Is
> >> there a way to turn this off?
> >>
> >
>

--

Best

Carsten Schinzer

Waisenhausstr. 53a
80637 München
Germany

[Ruth Hoffman-2]

Hi Mike:
Not sure if there is a way to turn this off, but on my 9.04 production
system I changed the default code so that the admin user had to be
logged in as admin before the password is reset. I also changed the way
the forgot password works...basically my implementation ignores requests
to reset the password for the "admin" userLoginId unless they are logged in.

I found out pretty early on - during testing of the MyOFBiz/mylibrary
site - that this was a potential problem in production.

Regards,
Ruth

On 7/30/11 3:10 AM, Mike wrote:
> Why is it that *any* user can, using the password reset or "Forgot
> Your Password" can actually force "admin" to change the password?  Is
> there a way to turn this off?
>

[BJ Freeman]

looking at the current trunk the login, checks the party then looks in
contactmech for the Primary Email address.
The contact Primary Email address set in the party is used to put the
incoming emails into that party or party group.
so if you have a party group of Sales, you should associate the employee
party to the Sales so they can access the Sales Emails and Send Emails
with the [hidden email].
However each employee should have their own Party with the Primary Email
address being one that is External to mydomain.com and ofbiz.
Then the email Password would go to that party's external email address.

This part is a choice that I recommend.
That a backdoor login be assigned to the Admin party that is not common
and is not used except in Dire emergencies. the Primary Email should
only go to the owner of the business. The back door I used is not even
assigned to a party just has the permissions. so there is no way to get
the Admin password Emailed. it can only be reset through webtools.

Each employee that would have Admin access should have that in their
permissions for the login of their partyID. This way if an employee
moves on their access to admin can be terminated without a lot of
disruption to the company's process.

If someone has a different scheme please share.


BJ Freeman sent the following on 7/30/2011 10:53 AM:

> even if someone request a password for admin it will only go to the
> email account specified, in the profile.
>
> I do run a nightly service that is like my own dictionary service for
> passwords that are common. Then the systems sends a password reset to
> the email.
>
> BJ Freeman sent the following on 7/30/2011 10:22 AM:
>> They may have a party Sales, at least in my systems, the login is email
>> addresses. it is harder for dictionary attracts to be effective.
>>
>>
>> Mike sent the following on 7/30/2011 7:41 AM:
>>> There must be something more.  Any organization would have generic
>>> logins, like "sales", or it would be easy to guess employee logins
>>> from the "about us" page.  It makes sense that the password reset
>>> should be intended ONLY for customers, not (any) system-type login.
>>>
>>> I would think that the password reset feature should be limited to
>>> certain roles, like "Customer".
>>>
>>> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>>>> for production systems do not use "admin" as a lognin.
>>>> it is never created.
>>>>
>>>> Mike sent the following on 7/30/2011 12:10 AM:
>>>>> Why is it that *any* user can, using the password reset or "Forgot
>>>>> Your Password" can actually force "admin" to change the password?  Is
>>>>> there a way to turn this off?
>>>>>
>>>>
>>>
>>
>

[Mike Z]

Sorry for the late response (vacation).  I understand what you saying
that it is not a good idea to use generic or group accounts as much as
possible.. However, it should not be so easy for users of an ERP to
shoot themselves in the foot. This sounds like a gaping security hole,
or at least a major security annoyance.

For instance.  You have a group of folks who answer phones and provide
customer support.  They read and reply to emails to multiple
customers.  When they email customers, they use their own accounts,
like [hidden email].  Let's disrupt sally (or admin!) by simply
going to the ecommerce page, enter sally and click forget password.
Does anyone think this is OK?  I don't think it should be necessary to
change the admin login, or even use unfriendly user names.


On Sat, Jul 30, 2011 at 11:39 AM, Carsten Schinzer
<[hidden email]> wrote:

> From a data security perspective your statement about 'Any organization
> would have generic accounts' is dangerous, IMHO.
>
> If under stricter data security regulations, you would first of all want
> traceability of who did what in the system, hence you want individual
> accounts. And initiatives like the Payment Card Industry Data Security
> Standards are addressing exactly those kind of issues and enforcing such
> policies.
>
> So beware when using 'group accounts' over individual logins. They may be
> easy to use for everyone but then beware that it's also to hack them (who
> would use a cryptic password on a group account .... ?) or be nasty with
> enforced password resets.
>
> I tend to use either email or even generic xAdmin01 or such which are
> abstracted. On production OFBiz systems, I do not use any of the demo
> accounts as well.
>
> Then BJ's point perfectly kicks in that user names are no longer guessable
> and thus your pain would go away.
>
> Just my 0.02 EUR.
> Greets
>
>
> Carsten
>
>
> Othrwise
>
> 2011/7/30 Mike <[hidden email]>
>
>> There must be something more.  Any organization would have generic
>> logins, like "sales", or it would be easy to guess employee logins
>> from the "about us" page.  It makes sense that the password reset
>> should be intended ONLY for customers, not (any) system-type login.
>>
>> I would think that the password reset feature should be limited to
>> certain roles, like "Customer".
>>
>> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>> > for production systems do not use "admin" as a lognin.
>> > it is never created.
>> >
>> > Mike sent the following on 7/30/2011 12:10 AM:
>> >> Why is it that *any* user can, using the password reset or "Forgot
>> >> Your Password" can actually force "admin" to change the password?  Is
>> >> there a way to turn this off?
>> >>
>> >
>>
>
>
>
> --
>
> Best
>
> Carsten Schinzer
>
> Waisenhausstr. 53a
> 80637 München
> Germany
>

[Mike Z]

Thanks Ruth.  Sounds like you tweaked the system to prevent this admin
reset issue.  I would think that the password reset should only apply
to ecommerce customers.  Sounds like a code change will be required.

On Sat, Jul 30, 2011 at 1:24 PM, Ruth Hoffman <[hidden email]> wrote:

> Hi Mike:
> Not sure if there is a way to turn this off, but on my 9.04 production
> system I changed the default code so that the admin user had to be logged in
> as admin before the password is reset. I also changed the way the forgot
> password works...basically my implementation ignores requests to reset the
> password for the "admin" userLoginId unless they are logged in.
>
> I found out pretty early on - during testing of the MyOFBiz/mylibrary site -
> that this was a potential problem in production.
>
> Regards,
> Ruth
>
> On 7/30/11 3:10 AM, Mike wrote:
>>
>> Why is it that *any* user can, using the password reset or "Forgot
>> Your Password" can actually force "admin" to change the password?  Is
>> there a way to turn this off?
>>
>

[BJ Freeman]

It sounds like you speaking of Ofbiz as a finished product, in which
case I agree with you first paragraph. However Ofbiz is not a finished
product and is meant for Consultants to setup for end users. The
consultant should know this information and make the application they
setup for their client fully secure.

Confusing about [hidden email]. If she is sending emails with this
email address, through ofbiz then it is gotten from the Primary email
address of the contactmech not the login. and ofbiz recieved those
emails and puts them in her party communications.
the login should not be [hidden email] since the email would be sent
to her account in ofbiz and she could not access it. it should be
[hidden email] like yahoo or qmail.com. This would reduce someone
from knowing her login.

There are some condition that allow not sensing or resetting the
password. They are in the Security.properties. look at the code in
LoginEvents.emailPassword()

Mike sent the following on 8/3/2011 11:07 PM:

> Sorry for the late response (vacation).  I understand what you saying
> that it is not a good idea to use generic or group accounts as much as
> possible.. However, it should not be so easy for users of an ERP to
> shoot themselves in the foot. This sounds like a gaping security hole,
> or at least a major security annoyance.
>
> For instance.  You have a group of folks who answer phones and provide
> customer support.  They read and reply to emails to multiple
> customers.  When they email customers, they use their own accounts,
> like [hidden email].  Let's disrupt sally (or admin!) by simply
> going to the ecommerce page, enter sally and click forget password.
> Does anyone think this is OK?  I don't think it should be necessary to
> change the admin login, or even use unfriendly user names.
>
>
> On Sat, Jul 30, 2011 at 11:39 AM, Carsten Schinzer
> <[hidden email]> wrote:
>> From a data security perspective your statement about 'Any organization
>> would have generic accounts' is dangerous, IMHO.
>>
>> If under stricter data security regulations, you would first of all want
>> traceability of who did what in the system, hence you want individual
>> accounts. And initiatives like the Payment Card Industry Data Security
>> Standards are addressing exactly those kind of issues and enforcing such
>> policies.
>>
>> So beware when using 'group accounts' over individual logins. They may be
>> easy to use for everyone but then beware that it's also to hack them (who
>> would use a cryptic password on a group account .... ?) or be nasty with
>> enforced password resets.
>>
>> I tend to use either email or even generic xAdmin01 or such which are
>> abstracted. On production OFBiz systems, I do not use any of the demo
>> accounts as well.
>>
>> Then BJ's point perfectly kicks in that user names are no longer guessable
>> and thus your pain would go away.
>>
>> Just my 0.02 EUR.
>> Greets
>>
>>
>> Carsten
>>
>>
>> Othrwise
>>
>> 2011/7/30 Mike <[hidden email]>
>>
>>> There must be something more.  Any organization would have generic
>>> logins, like "sales", or it would be easy to guess employee logins
>>> from the "about us" page.  It makes sense that the password reset
>>> should be intended ONLY for customers, not (any) system-type login.
>>>
>>> I would think that the password reset feature should be limited to
>>> certain roles, like "Customer".
>>>
>>> On Sat, Jul 30, 2011 at 4:00 AM, BJ Freeman <[hidden email]> wrote:
>>>> for production systems do not use "admin" as a lognin.
>>>> it is never created.
>>>>
>>>> Mike sent the following on 7/30/2011 12:10 AM:
>>>>> Why is it that *any* user can, using the password reset or "Forgot
>>>>> Your Password" can actually force "admin" to change the password?  Is
>>>>> there a way to turn this off?
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>> Best
>>
>> Carsten Schinzer
>>
>> Waisenhausstr. 53a
>> 80637 München
>> Germany
>>
>

[David E. Jones-2]

On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:

> It sounds like you speaking of Ofbiz as a finished product, in which
> case I agree with you first paragraph. However Ofbiz is not a finished
> product and is meant for Consultants to setup for end users. The
> consultant should know this information and make the application they
> setup for their client fully secure.

Sorry BJ, this simply isn't true. If there is something bad in the project it should be changed.

By your line of reasoning everyone doing consulting based on OFBiz should keep a big list of issues to address every time they do anything for a client… wouldn't it be better to just fix those things and be done with it?

-David

[BJ Freeman]

Yes david if it is a bug, but by your definition many times this is a
fearture.
My point of the second paragraph that you did not include
1)part of the solution providing a way to circomvent security isssues
not part of ofbiz but how one sets up ofbiz
2)the issues are addressed if one reads the code.

David E Jones sent the following on 8/4/2011 8:38 AM:

>
> On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
>
>> It sounds like you speaking of Ofbiz as a finished product, in which
>> case I agree with you first paragraph. However Ofbiz is not a finished
>> product and is meant for Consultants to setup for end users. The
>> consultant should know this information and make the application they
>> setup for their client fully secure.
>
> Sorry BJ, this simply isn't true. If there is something bad in the project it should be changed.
>
> By your line of reasoning everyone doing consulting based on OFBiz should keep a big list of issues to address every time they do anything for a client… wouldn't it be better to just fix those things and be done with it?
>
> -David
>
>

[Mike Z]

BJ, I fail to see how this could possibly be a feature.  Right now,
I'm at the level where I fiddle around with the code.  As a new user,
should I be expected to have to review the code to see if it stands up
to security standards?  I don't know much, but I do know when
something isn't right, and this happens to be one of those.  In the
real world, people use friendly names to send/receive email and
conduct business.  They shouldn't be expected to remember a user name
like mikej49q because an application needs obfuscation to protect
itself.

I would hope that maybe 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.

On Thu, Aug 4, 2011 at 10:56 AM, BJ Freeman <[hidden email]> wrote:

> Yes david if it is a bug, but by your definition many times this is a
> fearture.
> My point of the second paragraph that you did not include
> 1)part of the solution providing a way to circomvent security isssues
> not part of ofbiz but how one sets up ofbiz
> 2)the issues are addressed if one reads the code.
>
> David E Jones sent the following on 8/4/2011 8:38 AM:
>>
>> On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
>>
>>> It sounds like you speaking of Ofbiz as a finished product, in which
>>> case I agree with you first paragraph. However Ofbiz is not a finished
>>> product and is meant for Consultants to setup for end users. The
>>> consultant should know this information and make the application they
>>> setup for their client fully secure.
>>
>> Sorry BJ, this simply isn't true. If there is something bad in the project it should be changed.
>>
>> By your line of reasoning everyone doing consulting based on OFBiz should keep a big list of issues to address every time they do anything for a client… wouldn't it be better to just fix those things and be done with it?
>>
>> -David
>>
>>
>

[rajsaini]

I agree with you Mike. Every week I get couple of mails from Gmail and
FB telling me that I had requested to rest my password and click on a
link to confirm the request and I simply ignore such mails as I know I
never asked to change my password. Imagine, if Gmail changes my password
every time someone go to Gmail login page enter my id and hit "Forgot
Password", I will be changing my password many times a week.

Thanks,

Raj

On Friday 05 August 2011 04:55 AM, Mike wrote:

> BJ, I fail to see how this could possibly be a feature.  Right now,
> I'm at the level where I fiddle around with the code.  As a new user,
> should I be expected to have to review the code to see if it stands up
> to security standards?  I don't know much, but I do know when
> something isn't right, and this happens to be one of those.  In the
> real world, people use friendly names to send/receive email and
> conduct business.  They shouldn't be expected to remember a user name
> like mikej49q because an application needs obfuscation to protect
> itself.
>
> I would hope that maybe 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.
>
> On Thu, Aug 4, 2011 at 10:56 AM, BJ Freeman<[hidden email]>  wrote:
>> Yes david if it is a bug, but by your definition many times this is a
>> fearture.
>> My point of the second paragraph that you did not include
>> 1)part of the solution providing a way to circomvent security isssues
>> not part of ofbiz but how one sets up ofbiz
>> 2)the issues are addressed if one reads the code.
>>
>> David E Jones sent the following on 8/4/2011 8:38 AM:
>>> On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
>>>
>>>> It sounds like you speaking of Ofbiz as a finished product, in which
>>>> case I agree with you first paragraph. However Ofbiz is not a finished
>>>> product and is meant for Consultants to setup for end users. The
>>>> consultant should know this information and make the application they
>>>> setup for their client fully secure.
>>> Sorry BJ, this simply isn't true. If there is something bad in the project it should be changed.
>>>
>>> By your line of reasoning everyone doing consulting based on OFBiz should keep a big list of issues to address every time they do anything for a client… wouldn't it be better to just fix those things and be done with it?
>>>
>>> -David
>>>
>>>

[BJ Freeman]

Ok like the see the jira you create.

Mike sent the following on 8/4/2011 4:25 PM:

> BJ, I fail to see how this could possibly be a feature.  Right now,
> I'm at the level where I fiddle around with the code.  As a new user,
> should I be expected to have to review the code to see if it stands up
> to security standards?  I don't know much, but I do know when
> something isn't right, and this happens to be one of those.  In the
> real world, people use friendly names to send/receive email and
> conduct business.  They shouldn't be expected to remember a user name
> like mikej49q because an application needs obfuscation to protect
> itself.
>
> I would hope that maybe 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.
>
> On Thu, Aug 4, 2011 at 10:56 AM, BJ Freeman <[hidden email]> wrote:
>> Yes david if it is a bug, but by your definition many times this is a
>> fearture.
>> My point of the second paragraph that you did not include
>> 1)part of the solution providing a way to circomvent security isssues
>> not part of ofbiz but how one sets up ofbiz
>> 2)the issues are addressed if one reads the code.
>>
>> David E Jones sent the following on 8/4/2011 8:38 AM:
>>>
>>> On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
>>>
>>>> It sounds like you speaking of Ofbiz as a finished product, in which
>>>> case I agree with you first paragraph. However Ofbiz is not a finished
>>>> product and is meant for Consultants to setup for end users. The
>>>> consultant should know this information and make the application they
>>>> setup for their client fully secure.
>>>
>>> Sorry BJ, this simply isn't true. If there is something bad in the project it should be changed.
>>>
>>> By your line of reasoning everyone doing consulting based on OFBiz should keep a big list of issues to address every time they do anything for a client… wouldn't it be better to just fix those things and be done with it?
>>>
>>> -David
>>>
>>>
>>
>

[BJ Freeman]

I guess if you tie you Gmail or Facebook into the login proecess of
ofbiz I can see a relevance.
How many such request do you get from your
[hidden email]. Yourdomain being the one you have.

Raj Saini sent the following on 8/4/2011 6:24 PM:

> I agree with you Mike. Every week I get couple of mails from Gmail and
> FB telling me that I had requested to rest my password and click on a
> link to confirm the request and I simply ignore such mails as I know I
> never asked to change my password. Imagine, if Gmail changes my password
> every time someone go to Gmail login page enter my id and hit "Forgot
> Password", I will be changing my password many times a week.
>
> Thanks,
>
> Raj
>
> On Friday 05 August 2011 04:55 AM, Mike wrote:
>> BJ, I fail to see how this could possibly be a feature.  Right now,
>> I'm at the level where I fiddle around with the code.  As a new user,
>> should I be expected to have to review the code to see if it stands up
>> to security standards?  I don't know much, but I do know when
>> something isn't right, and this happens to be one of those.  In the
>> real world, people use friendly names to send/receive email and
>> conduct business.  They shouldn't be expected to remember a user name
>> like mikej49q because an application needs obfuscation to protect
>> itself.
>>
>> I would hope that maybe 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.
>>
>> On Thu, Aug 4, 2011 at 10:56 AM, BJ Freeman<[hidden email]>  wrote:
>>> Yes david if it is a bug, but by your definition many times this is a
>>> fearture.
>>> My point of the second paragraph that you did not include
>>> 1)part of the solution providing a way to circomvent security isssues
>>> not part of ofbiz but how one sets up ofbiz
>>> 2)the issues are addressed if one reads the code.
>>>
>>> David E Jones sent the following on 8/4/2011 8:38 AM:
>>>> On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
>>>>
>>>>> It sounds like you speaking of Ofbiz as a finished product, in which
>>>>> case I agree with you first paragraph. However Ofbiz is not a finished
>>>>> product and is meant for Consultants to setup for end users. The
>>>>> consultant should know this information and make the application they
>>>>> setup for their client fully secure.
>>>> Sorry BJ, this simply isn't true. If there is something bad in the
>>>> project it should be changed.
>>>>
>>>> By your line of reasoning everyone doing consulting based on OFBiz
>>>> should keep a big list of issues to address every time they do
>>>> anything for a client… wouldn't it be better to just fix those
>>>> things and be done with it?
>>>>
>>>> -David
>>>>
>>>>
>
>