Improving OFBiz security

[Ted Byers <r....@gmail.com>]

I need to add use of PKI, with document signing, to OFBiz

What would I need to do to configure OFBiz to require client side
certificates, and where would I modify the forms sent to the client's
browser so that it includes a JavaScript file that will support use of
the client's private key to sign and encrypt the document/data
submitted when the form's submit button is clicked?  I guess this is
two questions, the first being use/requirement for the client to
supply a client side certificate, and the second involves modification
of the interface so that data can be encrypted and signed.

In due course, I may even need to alter the content displayed to the
client depending on whether or not there is a client side certificate.

Thanks

Ted

FIND Orders: Issue while searching with inventory id

[Varun Kothari <va...@tcs.com>]

Dear Ofbiz Community members,

I am seeing some unusual behavior in Ofbiz app. (11.04.02), related to 
FIND ORDERS functionality.

1) Go to order manager app
2) Go to FIND orders
3) Input some valid value of invenotry ID for which the order exists
4) Click on FIND button
5) The orders with inventory id on order, should have been shown 
regardless of status

but :
1) Only "Completed" status orders are shown for that particular inventory 
id. Other orders with different statuses could not be found.

While analyzing ofbiz code, we could see that the system is designed to 
behave like this. It is by mistake or any specific reason for this 
behavior.

Though if we search by soft identifier / serial no. on inventory, we could 
see the orders regardless of status but in certain cases we might not have 
serial no. as well as soft identifier. In such scenarios, i could not see 
the orders with specific inventory.

Please share your views on this. Shall we go ahead and change this search 
behavior in ofbiz ?



regards
Varun Kothari
____________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: Improving OFBiz security

[Ted Byers <r....@gmail.com>]

Thanks Paul,

Actually, there are two other aspcts of this that may alter your
assessment,  First, I am looking to set up a prior arrangement with a
processing bank (a potential ally in any dispute with an issuing bank
- establishing a trust relationship between me and the bank, and this
would be the bank that processes the transaction for the merchant - it
only works for those merchants who can get an account with a bank with
which I have established such a relationship), and second, I am not
the merchant, but rather, providing services to merchants (including
use of OFBiz's back office functionality), so the data actually never
touches a machine in the merchant's hands.  I would provide an
interface to my RA (so they never touch the machines either, just an
interface, suitably hardened (using my Perl talents), that lets them
enter the data they need to provide), as well as a web interface to
the customers (again the only interaction I have with them).  I would
agree that this is not the sort of thing a merchant could effectively
do on his own; but it becomes feasible if a third party, like myself,
makes it happen with the aide of a prior relationship with one or more
processing banks (it would be even more effective, though, if the
issuing banks themselves became registration authorities (assuming
they do the due diligence to verify the identities of the people to
whom they issue credit cards ;-)     ).

And note, this only deals with one of the many kinds of fraud, but the
most frequent cause of ecommerce merchant bankruptcies I have seen.

Cheers

Ted

On Tue, May 28, 2013 at 2:16 AM, Paul Foxworthy <pa...@cohsoft.com.au> wrote:
> Hi Ted,
>
> OK, I understand your goals better now.
>
> For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and
> search for the clientAuth setting.
>
> Are you envisaging that the registration authority you mention will be your
> own server or a third party? If the RA receives valid authentication
> information and issues the customer with a certificate containing a private
> key, you should be able to demonstrate that you don't know the key, and
> therefore you are not in a position to forge an order from the customer.
>
> I doubt that a bank, faced with a chargeback request from a customer, will
> set any store on a document that you claim has been signed with a private
> key known only to the customer. Their choices are:
>
> 1. Audit your application to verify your claim that the customer must have
> signed and approved the contract. Verify the encrypted document is
> tamper-proof. Verify that the customer is indeed the owner of the relevant
> client certificate, and nobody else could possible know the key. Evaluate
> the veracity of the customer's claim that the key "must have been pinched by
> somebody else". Cost: weeks of time and thousands of dollars
> 2. Just repay the customer and claw the money back from the merchant's bank
> account. Cost: almost zero.
>
> If you haven't ahead of time negotiated with every bank that any customer
> might use, they would, I think,   be on the customer's side and not yours in
> the case of any dispute.
>
> Have you considered one of the e-signature services like Echosign
> (www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign
> (www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an
> API so you can integrate their service into applications. I presume others
> do a similar thing. The bank may have heard of them before, and you have an
> audit trail provided by an independent third party. You could receive an
> order via a shopping cart in the usual way, and say to the customer the
> contract will be sent via one of these services, and the order will be
> filled once they sign the contract.
>
> If part of the point is that a customer or the bank can independently verify
> that the transaction was done and hasn't been altered by you, why should
> they believe anything that comes from your web site? While you could deliver
> a document with a signature created with your private key, the software that
> verifies that signature would need to be from a third party and not you to
> give the customer any confidence no tampering was done.
>
> And one more thing I'd consider: bricks and mortar retailers need to factor
> "shrinkage" like pilfering and shoplifting into their pricing. If you think
> that a minority of customers might repudiate a transaction, would you be
> better off self-insuring for the risk? You could set your prices to cover
> the risk, make provision for it as part of every sale's proceeds, and live
> with it when the bad thing happens. That might be more cost-effective than
> investing in an elaborate non-repudiation scheme.
>
> One of our clients had a situation where the goods were delivered and the
> courier had a record of the deliveree's name and a signature which appeared
> to be the right name. The customer said it wasn't them, somebody else was
> pretending to be them, don't know who. Short of suing, our client could only
> refund their credit card and refuse to do business with them again. So a
> customer can conceivably repudiate a sale even when the sales contract is
> agreed by everyone.
>
> I haven't done it, but I agree it should be possible to map from a client
> certificate to a user's identity. Similar things are discussed here
> http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user
> and here (for Spring)
> http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html
>
> Cheers
>
> Paul Foxworthy
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641563.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.



-- 
R.E.(Ted) Byers, Ph.D.,Ed.D.
TED@MERCHANTSERVICECORP.COM
CTO
Merchant Services Corp.
17665 Leslie st., unit 30
Newmarket , Ontario
L3Y 3E3

Re: Improving OFBiz security

[Paul Foxworthy <pa...@cohsoft.com.au>]

Hi Ted,

OK, I understand your goals better now.

For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and
search for the clientAuth setting.

Are you envisaging that the registration authority you mention will be your
own server or a third party? If the RA receives valid authentication
information and issues the customer with a certificate containing a private
key, you should be able to demonstrate that you don't know the key, and
therefore you are not in a position to forge an order from the customer.

I doubt that a bank, faced with a chargeback request from a customer, will
set any store on a document that you claim has been signed with a private
key known only to the customer. Their choices are:

1. Audit your application to verify your claim that the customer must have
signed and approved the contract. Verify the encrypted document is
tamper-proof. Verify that the customer is indeed the owner of the relevant
client certificate, and nobody else could possible know the key. Evaluate
the veracity of the customer's claim that the key "must have been pinched by
somebody else". Cost: weeks of time and thousands of dollars
2. Just repay the customer and claw the money back from the merchant's bank
account. Cost: almost zero.

If you haven't ahead of time negotiated with every bank that any customer
might use, they would, I think,   be on the customer's side and not yours in
the case of any dispute.

Have you considered one of the e-signature services like Echosign
(www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign
(www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an
API so you can integrate their service into applications. I presume others
do a similar thing. The bank may have heard of them before, and you have an
audit trail provided by an independent third party. You could receive an
order via a shopping cart in the usual way, and say to the customer the
contract will be sent via one of these services, and the order will be
filled once they sign the contract.

If part of the point is that a customer or the bank can independently verify
that the transaction was done and hasn't been altered by you, why should
they believe anything that comes from your web site? While you could deliver
a document with a signature created with your private key, the software that
verifies that signature would need to be from a third party and not you to
give the customer any confidence no tampering was done.

And one more thing I'd consider: bricks and mortar retailers need to factor
"shrinkage" like pilfering and shoplifting into their pricing. If you think
that a minority of customers might repudiate a transaction, would you be
better off self-insuring for the risk? You could set your prices to cover
the risk, make provision for it as part of every sale's proceeds, and live
with it when the bad thing happens. That might be more cost-effective than
investing in an elaborate non-repudiation scheme.

One of our clients had a situation where the goods were delivered and the
courier had a record of the deliveree's name and a signature which appeared
to be the right name. The customer said it wasn't them, somebody else was
pretending to be them, don't know who. Short of suing, our client could only
refund their credit card and refuse to do business with them again. So a
customer can conceivably repudiate a sale even when the sales contract is
agreed by everyone.

I haven't done it, but I agree it should be possible to map from a client
certificate to a user's identity. Similar things are discussed here
http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user
and here (for Spring)
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html

Cheers

Paul Foxworthy




-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

--
View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641563.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Improving OFBiz security

[Ted Byers <r....@gmail.com>]

Hi Paul,

Thanks.

On Thu, May 23, 2013 at 2:25 AM, Paul Foxworthy <pa...@cohsoft.com.au> wrote:
> Hi Ted,
>
> You could use standard SSL support for client certificate authentication.
> You can configure the web server to require a client certificate. Here's how
> to to it in Apache:
> http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#allclients
>
Yes, I am aware of this, as well as how to do it using Apache's httpd
server.  But I was under the impression that OFBiz used a customized
version of Apache Tomcat, and I do not know how to handle SSL in
Tomcat in general nor how to configure it to use or better require use
of client side certificates.  I do not even know where OFBiz puts its
container when it is installed (in my case on Suse Linux).

> You need to find a secure way to send a client certificate to your users,
> and they need to import the client certificate into the browser. This would
> be external to OFBiz. The entire web application, not just form submission,
> would be encrypted, tamper-proof and authenticated, and that would be
> transparent to the OFBiz application.
>
I am aware of this too.  I have a handle on that, involving contact
between a registration authority and the users, and issuance of single
use credentials to the users, for access (over HTTPS) to a specific
website (written in Perl),  The RA would establish, also, a set of
challenge and response questions and answers with the users, so that
the identity of the user can be verified by the combinatin of single
use credentials and challenege/response questions.  This part of the
process, along with documentation the shows the RA's processes indeed
verify the users' identities, is entirely external to OFBiz, which is
why I didn't mention it before in this context.

> Web browsers and operating systems already have certificate stores, and you
> could just use them without needing to do anything special. Certificate
> deployment would be an annoyance, but a one-off annoyance.
>
Yes, I was planning on using this.

> If you want to do it internal to the application with Javascript, you are in
> effect rewriting the SSL infrastructure in your own Javascript code. Your
> code doesn't have a secure key store and is subject to risks of code
> injection and so on. See the rant on this subject at
>
> http://www.matasano.com/articles/javascript-cryptography/
>
OOPS, we have a misunderstanding here.  The objective is NOT to
rewrite the SSL infrastructure, although it will be used extensively.
Rather, the objective is to provide support for non-repudiation, hence
relating the client side certificate provided by the client machine to
the identity of the user.  Further, as an example, consider the nature
of ecommerce: this is essentially a sales contract, and while one
dimension of the security need for the integrity of such a contract
involves assuring the identities of the parties to the contract, the
contract itself needs to be handled in a way in which the details of
it can readily be verified and assured against subsequent modification
without the express consent of both parties.  Thus, in ecommerce, at
the checkout page, we need all the data in the shopping cart to be
included on the checkout page, and we want that, along with the amount
of the transaction, timestamp, &c., to be put into a single document
and signed and encrypted.  The resulting binary data would be stored
with the transaction data, and made easily retrievable/viewable by
both both parties to the sales contract and the banks used by the
merchant and customer (in case the custmer takes a dispute to the
issuing bank and demands a chargeback - such a document would be
priceless for the bans to determine whether or not there was a valid
sales contract between a merchant and client and is presently
generally unavailable in card not present transactions).  While
ecommerce is an obvious application for what I have in mind, I can see
other parts of OFBiz which may involve some sort of contract between
parties and which may benefit from having this sort of capability
(relations between different departments within a company?
accountability of staff to their supervisor? others, to be requested
by parties using ofbiz?).

The thing is that if the application server asks for a client side
certificate, the client's browser will offer one from the browser's or
OS' store (I am not sure if, when the store contains more than one
client side certificate if the browser asks the user which one to
send, but I'll examine this complication in due course).  But then, I
would expect that one can get at the client's ID from that certificate
using code written in Java just as one can using Perl (I dont recall
the details, or whether I'd need to use openssl installed on the
server and invoked from Perl, but I recall seeing it can be done
without too too much pain), so that what the certificate says about
the client's identity can be stored with the signed and encrypted
document (which, of course, the client's public key can be used to
decrypt the document and verify the signature).  At this stage, I am
not entirely certain whether or not this document really needs to be
encrypted or if it can simply be signed (what is critical is that any
alteration of the document be readily detected, that the signature
reliably identifies the client, and that both parties have a copy).
These are considerations that use of SSL or TLS do not address (as far
as I can tell, anyway).

> If you must build something like this in Javascript, these are some
> libraries that might help:
>
> http://ats.oka.nu/titaniumcore/js/crypto/readme.txt
> http://crypto.stanford.edu/sjcl/ (symmetric AES only)
> http://www-cs-students.stanford.edu/~tjw/jsbn/
>
> Hope that helps.
>

Thanks, I will take a look at these resources.

> Cheers
>
> Paul Foxworthy
>

Cheers

Ted

>
> Ted Byers wrote
>> I need to add use of PKI, with document signing, to OFBiz
>>
>> What would I need to do to configure OFBiz to require client side
>> certificates, and where would I modify the forms sent to the client's
>> browser so that it includes a JavaScript file that will support use of
>> the client's private key to sign and encrypt the document/data
>> submitted when the form's submit button is clicked?  I guess this is
>> two questions, the first being use/requirement for the client to
>> supply a client side certificate, and the second involves modification
>> of the interface so that data can be encrypted and signed.
>>
>> In due course, I may even need to alter the content displayed to the
>> client depending on whether or not there is a client side certificate.
>>
>> Thanks
>>
>> Ted
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641485.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Improving OFBiz security

[Paul Foxworthy <pa...@cohsoft.com.au>]

Hi Ted,

You could use standard SSL support for client certificate authentication.
You can configure the web server to require a client certificate. Here's how
to to it in Apache:
http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#allclients

You need to find a secure way to send a client certificate to your users,
and they need to import the client certificate into the browser. This would
be external to OFBiz. The entire web application, not just form submission,
would be encrypted, tamper-proof and authenticated, and that would be
transparent to the OFBiz application.

Web browsers and operating systems already have certificate stores, and you
could just use them without needing to do anything special. Certificate
deployment would be an annoyance, but a one-off annoyance.

If you want to do it internal to the application with Javascript, you are in
effect rewriting the SSL infrastructure in your own Javascript code. Your
code doesn't have a secure key store and is subject to risks of code
injection and so on. See the rant on this subject at

http://www.matasano.com/articles/javascript-cryptography/

If you must build something like this in Javascript, these are some
libraries that might help:

http://ats.oka.nu/titaniumcore/js/crypto/readme.txt
http://crypto.stanford.edu/sjcl/ (symmetric AES only)
http://www-cs-students.stanford.edu/~tjw/jsbn/

Hope that helps.

Cheers

Paul Foxworthy


Ted Byers wrote
> I need to add use of PKI, with document signing, to OFBiz
> 
> What would I need to do to configure OFBiz to require client side
> certificates, and where would I modify the forms sent to the client's
> browser so that it includes a JavaScript file that will support use of
> the client's private key to sign and encrypt the document/data
> submitted when the form's submit button is clicked?  I guess this is
> two questions, the first being use/requirement for the client to
> supply a client side certificate, and the second involves modification
> of the interface so that data can be encrypted and signed.
> 
> In due course, I may even need to alter the content displayed to the
> client depending on whether or not there is a client side certificate.
> 
> Thanks
> 
> Ted





-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

--
View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641485.html
Sent from the OFBiz - User mailing list archive at Nabble.com.